
Lesson Description
The "User Sign-In Workflow" Lesson is part of the full, API Design in Node.js, v5 course featured in this preview video. Here's what you'd learn in this lesson:
Scott explains the process of signing users in by comparing hashed passwords in the database to the password provided during sign-in. Scott also discusses the significance of salt in preventing identical hashed passwords for users with the same password, ensuring security.
Transcript from the "User Sign-In Workflow" Lesson
[00:00:00]
>> Scott Moss: We left off on signing users up, with the controller that we created for the register route and the validation tested that everything looked good and now we need to sign folks in, which is very similar to signing up just slightly different. So, for signing in the strategy is basically a user gives us their email and their password, and you could do username too if that's something you wanna do. We will then try to locate a user in the database by that email. If we do, we will then retrieve their hashed password from the database and then we will compare the hash password to the password they sent upon Sign In to see if those values are the same and if they are, we will generate them a JSON Web token and sign them in and send that back.
[00:00:20]
If we do, we will then retrieve their hashed password from the database and then we will compare the hash password to the password they sent upon Sign In to see if those values are the same and if they are, we will generate them a JSON Web token and sign them in and send that back. And that's Sign In, it's pretty simple. So a lot of places in which that 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.
[00:00:36]
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 database with that email, but the passwords don't match, that when we compare the hash versions, then Maybe this is you, we don't know, but at least there's for sure is an email in the database with this email, but the passwords don't match Either you just forgot your password or this is someone else trying to log in as you and guessing the password. Either way, we're not letting you in. And then Yeah, those would be the only two short circuits here in this example, so.
[00:00:57]
And then Yeah, those would be the only two short circuits here in this example, so. But before we do that, let's take a little quick trip of password verification. So I talked a little bit about it. We know what hashing is from what I told you.
[00:01:13]
We know what hashing is from what I told you. Comparing is just a little different, but basically, It's a way that we can hash a password without really knowing what the original value of the password is. So what we did like during sign up was right, we would. Take a password we would hash it we add some rounds or Salt here and we get back this hash thing, right?
[00:01:26]
Take a password we would hash it we add some rounds or Salt here and we get back this hash thing, right? So if I go look at. This user here, I can see. They have this hash value right here, OK?
[00:01:43]
They have this hash value right here, OK? What we want to do for the compare during login is we wanna take the plain text password that they send up when they log in. And we wanna compare that to the hashed password to the users whose email matches the email that they sent when they signed in and it's gonna return true if they were so diving a little more into the anatomy of that Bcrypt hash, I talked a little bit about this, but if we were to break this down and you do not need to, I promise you will never have a job where you need to understand this unless you are working security. So if you think you need to know this, what I'm about to say you don't.
[00:02:05]
So if you think you need to know this, what I'm about to say you don't. I just learned this like a year ago, so it's not that useful. It's just like. Something you can put in Slack to make yourself sound smart, but you're never gonna, you don't need, you don't need to know this.
[00:02:19]
Something you can put in Slack to make yourself sound smart, but you're never gonna, you don't need, you don't need to know this. I just thought it was cool, so I like to share things. So if we break this down. The first, these first two parts here, with the dollar signs, those are called parameters, right?
[00:02:41]
The first, these first two parts here, with the dollar signs, those are called parameters, right? And the first one is the, algorithm version, that's the first part so this dollar sign, to the dollar sign. And then the Next one is the cost factor, so which basically determines. How expensive this process is going to be, so like you wanna find a high enough number to be hard against brute force attacks, but like not too hard, to where it's slow.
[00:02:54]
How expensive this process is going to be, so like you wanna find a high enough number to be hard against brute force attacks, but like not too hard, to where it's slow. So it depends on what computer you're doing, you're running on and things like that. The Next one. Is the Salt, so the Next 22 characters, this is basically like.
[00:03:08]
Is the Salt, so the Next 22 characters, this is basically like. The reason we have a salt is because if two people have the same password which is fine, we don't have any restriction in our database from two people having the same password, but we don't want their hashed passwords in the database to be exactly the same because. That's giving that's telling me as an attacker that like OK maybe I don't know these passwords but I know all 10 of these people have the same password because their hash passwords are exactly the same. So if their hash passwords are exactly the same, all I gotta do is figure out what that one password is and I have access to 10 accounts.
[00:03:21]
So if their hash passwords are exactly the same, all I gotta do is figure out what that one password is and I have access to 10 accounts. Right, so to prevent people from having the same hash value even though their passwords are the same we introduced something called a salt A salt is just a unique thing that gets generated for every hash that gets added to your hash password no matter what your password is. So that way, even if you and I have the same password, our hash password in the database won't be the same because our salts are different. Does that make sense?
[00:03:37]
Does that make sense? OK. So, basically, yeah, the Salt just ensures that two users have the same password, their stored hashes will be completely different. And then and then and then the last part, the remaining characters is the actual result of hash of the user's password with the Salt, because if we don't use the Salt to make this hash, the Salt is.
[00:03:55]
And then and then and then the last part, the remaining characters is the actual result of hash of the user's password with the Salt, because if we don't use the Salt to make this hash, the Salt is. Kind of useless because then as an attacker I'll just look at the characters after the Next 22 characters like oh cool you got different Salt but all your characters after those other 22 characters are the same so you still have the same password. So the Salt actually is like you could think about it as like a randomness factor that goes into hashing your password. So hashing in and it's in its sense is deterministic, but you can introduce entropy or randomness or RNG.
[00:04:12]
So hashing in and it's in its sense is deterministic, but you can introduce entropy or randomness or RNG. Random number generator into that factor to get some bit of randomness from it and that's what the Salt is, and then that Salt itself is randomized. Yeah, that's the best way I can describe it. Yeah, there's something like called a timing attack.
[00:04:24]
Yeah, there's something like called a timing attack. It's basically when, I can tell how long I can measure how long it takes, you know, the comparison function to work and then that would tell me like how many rounds it might have which helps me guess the Salt So to get around that bcrypts compare function is constant time. It's the same time no matter what, so it doesn't matter how many characters match, it's gonna take the same amount of time it's a constant time so nobody can time that and try to figure out what that is. It's always gonna be the same amount of time during the compare.
[00:04:39]
It's always gonna be the same amount of time during the compare. Now that's different than the hashing where if you have a higher Salt there's many rounds it could take longer the compare is always gonna be the same time.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops