We're at Stripe

Sessions this week!

Fresh off being awarded Stripe's Services Implementation Specialization, we're in San Francisco to spend time with everyone. Make sure to say hi👋

Back

Becoming More Proficient on the Back-End (Part 3)

Joe Previte
Joe PreviteFriday, August 16, 2019
Graph with pen, pencil, and silver ruler

In case you missed it, check out Part 1 and Part 2 where I talk about my Q3 goals and explain how this series works.

Now, here’s Part 3!

Progress Update

During the week of July 29th, my goal was to complete the following:

  • Modern TS Course
  • Authentication — Setting up JWT/Passport — 1.5 hours
  • Authorization — Task Ownership — 30 mins

Completed Weekly Goal

Unfortunately, I did not put in the time to complete these sections in my course. I failed to hit my target because I only dedicated three hours that week towards these goals due to other obligations.

I was also on PTO the week of August 5th meaning I did not have time to make up for it.

Thus, I should be able to finish these sections this week. This means I will be a week behind on my schedule, but I plan to put in extra hours this weekend to make up for it.

🤔 What did I do?

The material I completed touches the surface on Authentication. We set up a module to handle signing up and logging in.

Milestone Achieved

If you remember from Part 1, my original Result Goal for the quarter was

Become more proficient in Back-End Development, measured by:: shipping 3 features on the API/Back-End side

In this update, I made progress towards that by shipping a feature on the API/Back-End.

This means I’ve completed 1/3 — woohoo!🥳.

Fortunately, the current project has back-end work where I can practice what I’m learning. My teammates Matt and Jeff have provided guidance along the way. After multiple rounds of helpful PR feedback, my PR with a new Entity, new GraphQL types and resolvers, tests, and a Factory for creating the Entity in testing was merged in.

I’m celebrating this milestone because:

  1. It’s progress towards my original Result Goal for Q3
  2. It’s the first time I’ve shipped code to production related to API/back-end work

💡 Key Learnings

Some of these things were new and others were review but here’s what stuck out:

  • hashing passwords

Hashing a password is when you encrypt a password using an algorithm. For example, let’s say my password is superSecure1234. We can take this password and pass it to a sha256 algorithm to encrypt it. In return, we receive the encrypted value.

Sha256(superSecure1234) = dbc78b60341efd7484630bdaa9cde2fc9ae5d782ee59b550e98b19f11aeafd86

As you can imagine, storing a user’s password as a hash is more secure than storing the original plaintext value.

  • salting passwords

Salting is a password means you prefix the password with a hash value. Usually this is done after you hash the password. By doing this, we make the stored hash less vulnerable to attacks because it’s no longer only the hashed password.

An example might look like this:

// Our password for logging in const password = "superSecure1234" // The hashedPassword after we use an algorithm like sha256 const hashedPassword = "dbc78b60341efd7484630bdaa9cde2fc9ae5d782ee59b550e98b19f11aeafd86" // The salt we use to prefix the password before storing in the database const salt = "$2b$57$//DXiKSFJG9p7G5k/3Jlx/t" // What we store in the database // storedPassword = salt + hashedPassword const storedPassword = "$2b$57$//DXiKSFJG9p7G5k/3Jlx/tdbc78b60341efd7484630bdaa9cde2fc9ae5d782ee59b550e98b19f11aeafd86"

Now there are two ways you can salt passwords.

  1. Fixed salt
  2. Dynamic salt

A fixed salt is one you generate and then use with every password. If a hacker were to look at your database, they would be able to guess the salt because it would be in every row. This is less secure.

A dynamic salt is one you generate with each new user. Every time a user/password is created, you generate a new salt. This way, each salt is unique and your database is more secure. And every time the user changes their password, you generate a new salt.

Using a dynamic salt is also more secure because in the event that a hacker did figure out the salt and had access to the database, they would only be able to decrypt that single user’s password. Fortunately, since every salt is dynamic, they wouldn’t be able to decrypt any other passwords.

⁉️ Challenges

Since I haven’t dived too deep into these lessons, there weren’t many challenges. I assume there may be as I progress through the Authentication and Authorization sections as those topics can get complicated.

That’s all for my update! Thanks for reading and catch ya next week! 👋

Share this post

twitterfacebooklinkedin

Related Posts:

Interested in working with us?

Give us some details about your project, and our team will be in touch with how we can help.

Get in Touch