In this video we're going to start working on hashing the user's password before we send it off to our
database to be saved.
In this video I want to give you a quick reminder on why we hash passwords in general and how the entire
process works.
If you are already familiar with password hashing go ahead and skip this video and take a look at the
implementation in the next one.
Otherwise stick around and let's get to it.
All right.
So in this diagram right here I'm showing you a bad approach.
This is something that we are currently doing inside of our app but it's something we do not want to
do.
So we need to replace our current implementation.
So at present our ReACT application or right now technically postman we're making a request to sign
up to our app and we are including an email and a password.
At present we are creating a new user document out of that using the email of test at test dot com and
a password of whatever gets sent.
In this case we're saying it's wordpress so we create a new user document and persist that to Mongo
DB.
So our password is sitting inside of this user's collection in plain text.
This is a very bad approach because if anyone ever got access to our Mongo DB database they would see
all the emails and passwords of our users.
Now we don't really care about someone necessarily logging into our application.
It's more that if a user or if some malicious person gets access to all these email and passwords our
users might use the same email and password combination to log onto many other services.
And so a malicious user could take test at test dot com inward word pass and then go and try to log
on to my banking Web site and they might possibly successfully log in.
So again Under no scenario under no circumstance do we ever store our passwords in plain text as we're
currently doing.
So how are we going to fix this.
Well we're going to introduce password hashing this is a two step process that spans over these sign
up and sign in Lowes.
Let's first focus on what occurs during sign up.
This is what we are about to implement right now.
So once again our ReACT app is going to make requests to sign up and maybe once again it's an email
of test at test dot com and a password of WordPress.
We are going to take that password and hash it.
We're going to hash the password word pass when we have to string is going to produce a unique series
of characters that are unique just for that word right there at that very particular string.
So the word or the string of word pass might produce this hash during right here if you want to get
more information about the hashing process.
I encourage you to look it up online right now I'm just giving you a very quick overview on what we're
going to be doing.
We then take this hash password and stored inside of our database instead of the original plaintext
one.
So now we only have the email and the hash password not the original one so then we go ahead and create
the new user.
Really.
Let's say this diagram should be a little bit closer to that right there.
So now inside of our database we've only got the hash password with the hash passwords.
There is no way or no easy way we should say to somehow figure out what the original password was.
So some malicious user somehow got access to this email password combination.
In theory hopefully there would not be much damage done.
Now again there are scenarios where even a hash password can have some negative consequences.
And in general we don't want anyone getting access to our data at all.
But if it's some malicious user does get access to this hash password it's not as big a problem but
that's just the sign up process.
How do we actually make use of the hash password at some point time in the future.
Well let's imagine the sign in flow that we're going to be implementing very shortly.
So once again maybe our ReACT application sends a request to sign into our app when user signs in there
are going to send us their email and password so as soon as we get that we are going to hash the password
in the exact same way that we did when users signed up initially will hash the password and we once
again that's get that same identical string we're then going to take a look and try to find a user saved
inside of our database with the same email as the one that was just submitted test at test dot com.
So we'll find that record right there.
Now at this point time we've got these stored hashed password and we've got the hash version version
of the password to the user just applied to us.
We are going to check and see if the hashed passwords are equal to each other if they are equal to each
other.
That means that the user must have supplied the correct password and then at that point time are going
to say OK you are or you have supplied some valid log in credentials we now consider you to be signed
into our application so that's it.
That's the flow.
Now I went through this really quickly.
So if any of this is still kind of confusing I would encourage you to do a little bit of research.
Again I'm just giving you a quick reminder on how this stuff is working.
Hopefully you have seen password hashing at least once in the past before.
Well let's take a pause right here now that we got this review in place.
We're going to start implementing the password hashing flow in the next video.