Now, here’s Part 3!
During the week of July 29th, my goal was to complete the following:
❌ 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:
Some of these things were new and others were review but here’s what stuck out:
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 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.
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.
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! 👋