[Narrator] So we're now at a point where
we need to compare our passwords.
Is the password of our saved user
equal to the password that was supplied
by the request to sign in?
This goes back to the topic of bcrypt.
So I'm going to open up my user model over here.
If you recall, we were salting
and hashing our passwords before we saved them.
We were also looking at a diagram
that explained what was going on
with the salt and the plain password.
So if you recall,
I said that we were generating a salt,
we were using it to hash, or encrypt, our password,
and then the saved record in the database
was the salt plus the hashed password.
So we were saving both the salt and the encrypted password.
So this record right here,
this salt plus hashed password, when we want to sign in,
when we want to compare a password,
this record right here we are storing in our database.
We're going to retrieve it again.
So this little square right here represents
the saved record in the database.
So here's how we're gonna compare the passwords.
We're going to take the salt, right?
That's kind of like the encryption key of sorts.
We're going to encrypt the submitted password
that the user supplied in the request.
That's going to produce a new hashed password.
And then we compare the stored hashed password
with the new hashed password.
If they are the same, then if they are equal,
then they must be the same password.
We don't ever actually end up decrypting
this hashed password.
There's really no concept of decrypting it.
All we're ever doing is attempting to encrypt,
or hash, submitted passwords,
and then we see if they are identical
in their hashed state to our saved password.
So that's the full circle on bcrypt.
Let's go through it one more time.
Bcrypt. Using bcrypt, we created a salt,
which is like a key.
We then took our plain password, we encrypted the password,
turning it into a hashed password,
and we saved in our database
both the salt and the hashed password.
Then at some point in the future
when we want to compare passwords,
see if someone is entering the correct one,
we're going to pull off just the salt,
just the encryption key.
We're going to use it to encrypt
the submitted password from the request from our user.
That's gonna produce a hashed password
and then we just compare and see
if it's identical to the saved one in our database.
So that is full circle on bcrypt.
That's the key to everything here.
So we're never going to actually decrypt
our saved password.
All right, so let's give a shot at this logic here.
We're going to add a method to our user model
to do this password comparison for us.
So I'm in our user dot js file right now.
I'm gonna go beneath our pre-save hook,
where we generated the salt and the hash,
and I'm going to add another helper
in here on my user schema methods.
So this methods object right here.
It basically says, whenever we create a user object
it's going to have access to any functions
that we define on this methods property.
So we're gonna define a new function
called compare password.
It's gonna be a function.
It's going to take a candidate password
and a callback.
So we've got user schema.
We're adding a instance method called compare password.
It is a function that's gonna take a candidate password.
In other words, the password that some user is submitting,
attempting to sign in, and a callback.
So we're going to use the bcrypt library again.
We're gonna use bcrypt compare
our candidate password
with this dot password.
This, in this case,
is a reference to our user model.
So this dot password is our hashed and salted password.
We're then gonna toss another callback to this
of err and is match,
and we'll say if there was an err
during the comparison,
return, call back with the err.
Otherwise, call to callback
with null and is match.
So bcrpyt behind the scenes
is really doing that comparison for us.
It's taking the salt plus the hashed password.
It's going to internally do that hashing process
on the candidate password.
And then it's gonna decide, hey,
are these two things equal, yes or no?
If they are equal, is match is going to be true.
Otherwise, if they're not the same,
it's gonna be false.
All right, So this is good.
Let's stop here and continue
in the next section where we can now
put this to use inside of our local strategy.
I'll see you there.