In this video we're going to get a better idea of how to safely secure our passwords inside of Mongo
DB.
So once again right now our password is stored inside plain text.
This is very bad because if a malicious user ever got access to our database they could pull the full
emails and plain text passwords of all of our different users.
It's entirely possible that one of our users might have the same email and password combination inside
of our app as they used for maybe their bank account.
So if a malicious user got access to that information they could log into someone else's bank account
and take a lot of money or something similar to that.
So let's figure out how we can securely store our passwords to do so.
We're going to be using something called a hashing algorithm a hashing algorithm is a function that
takes in some string.
So in our case we're gonna take some password that we want to save into our database.
We're then going to provide it as an input to this hashing algorithm function the hashing algorithm
is then going to give us back a string and the string is very unique for just that password right there.
This string is going to look like a collection of jumbled characters and it's safe to store inside of
our database.
Now why is it safe to store.
Well let's take a look at a couple of diagrams and understand what's really going on behind the scenes
with this hashing algorithm.
The first thing I want you to understand is that if we take the same string of characters as an input
to our hashing algorithm and we feed it into the same algorithm multiple times we're always going to
get the exact same output.
Let's take a look at this in action.
I'm going to pull up a quick tool very quickly.
So here's the address of the tool.
Now this is a tool that uses the Indy five hashing algorithm.
We're not using the Indy five algorithm we're using a different one called B crit but understanding
what's going on with Indy 5 is a little bit easier because it runs a good bit faster than B script does
OK.
So on this page we can enter in a string right here that we want to hash.
So I'll put in something like my password and I get back a result of 3 4 1 8 9 and blah blah blah.
So it no matter how many times I attempt to hash my password I'm always going to get back 3 4 8 1 9.
So if I cut that text out and then put it back in I get 3 4 1 8 9 I can take it out put it back in.
Same thing and every single time I put in my password just the string my password I always get the same
result but as soon as I change that input of my password by even one character the hash is going to
change very significantly.
So if I add on the number one I now get a completely different hash.
But the point is as long as I put in the same inputs I'm always going to get the same output.
A very important property around these hashing algorithms is that they are one directional.
In other words if I have a input string of say my password and put it into my hashing algorithm and
I get that output I can't somehow take that output and use it to figure out what the original input
was.
So for example if I put in my password right here I get back this output I cannot not then take this
output and somehow stick it back in as an input and get my password out.
So once we've hashed our password and we've got the output we can't somehow divine or figure out what
the input was.
So these are all very special properties that allow us to securely store our password.
Let me show you another diagram to help you understand why OK.
So here's the general idea of what we're going to do when a user first signs up to our application.
We're going to take their password run it through our hashing algorithm and then we're going to store
the results inside of our database.
Then whenever a user tries to log in at some point in time in the future they're going to give us our
password.
Once again we're then going to take the password they just provided and run it through the exact same
hashing algorithm.
We're then going to take the results.
We're then going to compare the result from whatever we just got versus whatever is stored inside of
our database.
If those two outputs are equal then we know with great certainty that these same input of my password
must have been provided.
So this is a comparison that we're going to do anytime a user attempts to log into our application.
We're going to take whatever hashed output we have stored inside of our database and compare it against
the new hashed password that we have from whatever they just provided now just using this password and
storing it inside the database actually opens us up to a kind of interesting exploit.
Let me very quickly tell you what this exploit is and then I explain one little addition that we're
going to add into this step all right.
So this is a attack that a malicious user could do called a rainbow table attack.
Let's imagine for a second that there's some malicious user out there and they take the list of like
the top five thousand most used passwords in the world.
So it's statistically likely that maybe a user inside of our application has used one of these very
common passwords.
So a malicious user could take all these different passwords and run it through the same hashing algorithm
we are using once again in our case we're using a hashing algorithm called secret so they would then
have essentially a table that says OK here's all these very common passwords.
And if we feed these through that hashing algorithm here's the output we would get if a malicious user
then somehow got access to our database they could then look at all the different passwords that are
stored inside there.
And remember we now have hashed passwords inside so this malicious user could then take a look at this
password that we stored inside of our database and they can say OK clearly I can't really interpret
what that stored password is but they can't take a look at that hashed password and compare it against
a list of existing hash passwords that they already have.
So they could look at that string right there of ADR blah blah blah and compared against that one.
OK not the same not the same not the same.
Oh look at that that output right there is identical to this password right here.
That means that this user's password must have been one two three four five six seven eight.
So again we refer to this as a rainbow table attack to secure ourselves against this we add in one additional
step to this hashing process.
So this is what we referred to as generating a salt.
So when we take that user's initial password when they first sign up to our application we're going
to simultaneously generate a random string of characters called a salt.
We're then going to join the user's password together with that random string so we can imagine we just
kind of take those two strings and concatenate them together like so we're then going to take that can
net caffeinated output and feed it through our hashing algorithm and then very critically we're going
to take that salt and we're going to copy it independent onto the very end of our hashed output so notice
how there's the dot right there and then on the right hand side is the salt that we have generated.
So now we are storing both the hash and salted password along with just the salt.
So you might be kind of curious.
OK.
How does that actually solve anything here.
We'll think about what a malicious user would now have to do to kind of do that back tracing attack.
They would have to have a super comprehensive list where essentially they take a look at every single
password you know all 5000 of the most different common passwords.
And if they wanted to somehow interpret this over here the hash password plus the salt they would have
to have some entry of our hash password dot and then whatever the salt is.
Now in this case I listed out salt as like just the word salt and salt two salt Three salt four.
But in reality the salt that gets generated is a string of random characters.
So there could be a huge set of different possible outcomes for trying to have like some established
password right there or some established hash password plus some salt in other words.
This list right here would go down for a very very very long time and a malicious user would have to
generate that entire comprehensive list for every different one of these different common passwords.
And so this completely solves the issue of this rainbow table attack OK.
That's kind of a quick overview of what's going on with this password hashing and salting and whatnot.
So now that we've got a quick overview done let's take a quick pause right here.
When we come back the next video we're going to add in some salting and hashing to our application.
Anytime we try to store a password or compare a password to log user in in the future.