User Sign-In Workflow

[00:00:00]
>> Speaker 1: We left off on signing users up with the controller that we created for the register route and validation tested that everything looked good Now we need to sign folks in, which is very similar to signing up, just slightly different For signing in, the strategy is basically a user gives us their email and password, and you could do username too if that's something you want to do

[00:00:00]
We will then try to locate a user in the database by that email If we do, we will retrieve their hashed password from the database and then compare the hashed password to the password they sent upon sign-in to see if those values are the same If they are, we will generate a JSON Web Token and sign them in and send that back

[00:00:00]
And that's sign-in—it's pretty simple There are several places where this can short circuit The first place is we look in the database to see if this email exists If this email doesn't exist, then you are not a user in our database and you can't sign in, so we'll just redirect you to sign up If there is a user in the database with that email, but the passwords don't match when we compare the hash versions, then maybe this is you, but we don't know

[00:00:00]
There's for sure an email in the database with this email, but the passwords don't match Either you forgot your password or someone else is trying to log in as you by guessing the password Either way, we're not letting you in Before we do that, let's take a quick trip into password verification We know what hashing is from what I told you

[00:00:00]
Comparing is a bit different, but basically, it's a way we can hash a password without really knowing the original value During sign-up, we would take a password, hash it, add some rounds or salt, and get back this hash value If I look at this user, I can see they have this hash value What we want to do for comparison during login is take the plain text password they send and compare it to the hashed password of the user whose email matches the email they signed in with

[00:00:00]
It'll return true if they match Let's dive a bit more into the anatomy of the Bcrypt hash I talked about this before, but if we break this down—and you do not need to understand this unless you're working in security I promise you'll never have a job where you need to know this, unless you're in a very specialized role

[00:00:00]
I just learned this a year ago, so it's not that useful It's just something you can put in Slack to sound smart, but you don't really need to know it If we break it down, the first two parts with dollar signs are called parameters The first one is the algorithm version, and the next is the cost factor, which determines how computationally expensive the process will be

[00:00:00]
You want a high enough number to be hard against brute-force attacks, but not so high that it becomes slow The next part is the salt—the next 22 characters The reason we have a salt is that if two people have the same password, we don't want their hashed passwords in the database to be exactly the same

[00:00:00]
If an attacker sees identical hash passwords, they only need to figure out one password to access multiple accounts To prevent this, we introduced salt—a unique value generated for every hash added to the password Salt ensures that even if you and I have the same password, our stored hashes will be completely different

[00:00:00]
The salt is essentially a randomness factor in the hashing process Hashing is deterministic, but you can introduce entropy or randomness to add a bit of unpredictability There's something called a timing attack, where an attacker could measure how long the comparison function takes to work, potentially helping them guess the salt

[00:00:00]
To prevent this, Bcrypt's compare function is constant time—it takes the same amount of time no matter what, so no one can time it to figure out the details The comparison is always going to take the same amount of time, unlike hashing, where more rounds can increase processing time.