1 00:00:01,220 --> 00:00:05,840 In this video we're going to get a better idea of how to safely secure our passwords inside of Mongo 2 00:00:05,840 --> 00:00:06,300 DB. 3 00:00:06,740 --> 00:00:10,270 So once again right now our password is stored inside plain text. 4 00:00:10,280 --> 00:00:15,440 This is very bad because if a malicious user ever got access to our database they could pull the full 5 00:00:15,440 --> 00:00:19,100 emails and plain text passwords of all of our different users. 6 00:00:19,100 --> 00:00:24,140 It's entirely possible that one of our users might have the same email and password combination inside 7 00:00:24,140 --> 00:00:27,230 of our app as they used for maybe their bank account. 8 00:00:27,230 --> 00:00:31,580 So if a malicious user got access to that information they could log into someone else's bank account 9 00:00:31,610 --> 00:00:34,460 and take a lot of money or something similar to that. 10 00:00:34,490 --> 00:00:38,730 So let's figure out how we can securely store our passwords to do so. 11 00:00:38,810 --> 00:00:44,390 We're going to be using something called a hashing algorithm a hashing algorithm is a function that 12 00:00:44,390 --> 00:00:45,750 takes in some string. 13 00:00:45,770 --> 00:00:49,770 So in our case we're gonna take some password that we want to save into our database. 14 00:00:49,880 --> 00:00:55,460 We're then going to provide it as an input to this hashing algorithm function the hashing algorithm 15 00:00:55,550 --> 00:01:02,850 is then going to give us back a string and the string is very unique for just that password right there. 16 00:01:02,930 --> 00:01:07,430 This string is going to look like a collection of jumbled characters and it's safe to store inside of 17 00:01:07,430 --> 00:01:08,590 our database. 18 00:01:08,600 --> 00:01:10,160 Now why is it safe to store. 19 00:01:10,160 --> 00:01:14,120 Well let's take a look at a couple of diagrams and understand what's really going on behind the scenes 20 00:01:14,120 --> 00:01:16,100 with this hashing algorithm. 21 00:01:16,100 --> 00:01:21,140 The first thing I want you to understand is that if we take the same string of characters as an input 22 00:01:21,140 --> 00:01:26,570 to our hashing algorithm and we feed it into the same algorithm multiple times we're always going to 23 00:01:26,570 --> 00:01:29,200 get the exact same output. 24 00:01:29,210 --> 00:01:31,340 Let's take a look at this in action. 25 00:01:31,460 --> 00:01:33,440 I'm going to pull up a quick tool very quickly. 26 00:01:33,440 --> 00:01:35,330 So here's the address of the tool. 27 00:01:35,330 --> 00:01:38,640 Now this is a tool that uses the Indy five hashing algorithm. 28 00:01:38,690 --> 00:01:43,580 We're not using the Indy five algorithm we're using a different one called B crit but understanding 29 00:01:43,580 --> 00:01:48,950 what's going on with Indy 5 is a little bit easier because it runs a good bit faster than B script does 30 00:01:50,920 --> 00:01:51,220 OK. 31 00:01:51,250 --> 00:01:55,210 So on this page we can enter in a string right here that we want to hash. 32 00:01:55,240 --> 00:02:01,930 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. 33 00:02:02,620 --> 00:02:09,190 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. 34 00:02:09,190 --> 00:02:15,920 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. 35 00:02:16,000 --> 00:02:21,160 Same thing and every single time I put in my password just the string my password I always get the same 36 00:02:21,160 --> 00:02:27,160 result but as soon as I change that input of my password by even one character the hash is going to 37 00:02:27,160 --> 00:02:28,920 change very significantly. 38 00:02:28,990 --> 00:02:33,230 So if I add on the number one I now get a completely different hash. 39 00:02:33,340 --> 00:02:38,850 But the point is as long as I put in the same inputs I'm always going to get the same output. 40 00:02:38,850 --> 00:02:43,630 A very important property around these hashing algorithms is that they are one directional. 41 00:02:43,660 --> 00:02:49,540 In other words if I have a input string of say my password and put it into my hashing algorithm and 42 00:02:49,540 --> 00:02:54,880 I get that output I can't somehow take that output and use it to figure out what the original input 43 00:02:54,880 --> 00:02:56,540 was. 44 00:02:56,540 --> 00:03:02,870 So for example if I put in my password right here I get back this output I cannot not then take this 45 00:03:02,870 --> 00:03:07,360 output and somehow stick it back in as an input and get my password out. 46 00:03:07,370 --> 00:03:14,180 So once we've hashed our password and we've got the output we can't somehow divine or figure out what 47 00:03:14,180 --> 00:03:16,030 the input was. 48 00:03:16,040 --> 00:03:20,060 So these are all very special properties that allow us to securely store our password. 49 00:03:20,060 --> 00:03:23,390 Let me show you another diagram to help you understand why OK. 50 00:03:23,420 --> 00:03:27,710 So here's the general idea of what we're going to do when a user first signs up to our application. 51 00:03:27,710 --> 00:03:31,970 We're going to take their password run it through our hashing algorithm and then we're going to store 52 00:03:31,970 --> 00:03:34,270 the results inside of our database. 53 00:03:34,430 --> 00:03:38,600 Then whenever a user tries to log in at some point in time in the future they're going to give us our 54 00:03:38,600 --> 00:03:39,260 password. 55 00:03:39,260 --> 00:03:44,660 Once again we're then going to take the password they just provided and run it through the exact same 56 00:03:44,660 --> 00:03:46,400 hashing algorithm. 57 00:03:46,400 --> 00:03:48,150 We're then going to take the results. 58 00:03:48,380 --> 00:03:52,940 We're then going to compare the result from whatever we just got versus whatever is stored inside of 59 00:03:52,940 --> 00:03:54,150 our database. 60 00:03:54,290 --> 00:04:01,190 If those two outputs are equal then we know with great certainty that these same input of my password 61 00:04:01,460 --> 00:04:04,300 must have been provided. 62 00:04:04,300 --> 00:04:08,860 So this is a comparison that we're going to do anytime a user attempts to log into our application. 63 00:04:08,860 --> 00:04:13,150 We're going to take whatever hashed output we have stored inside of our database and compare it against 64 00:04:13,150 --> 00:04:19,780 the new hashed password that we have from whatever they just provided now just using this password and 65 00:04:19,780 --> 00:04:24,670 storing it inside the database actually opens us up to a kind of interesting exploit. 66 00:04:24,670 --> 00:04:29,400 Let me very quickly tell you what this exploit is and then I explain one little addition that we're 67 00:04:29,400 --> 00:04:31,880 going to add into this step all right. 68 00:04:31,990 --> 00:04:37,480 So this is a attack that a malicious user could do called a rainbow table attack. 69 00:04:37,570 --> 00:04:41,710 Let's imagine for a second that there's some malicious user out there and they take the list of like 70 00:04:41,710 --> 00:04:45,440 the top five thousand most used passwords in the world. 71 00:04:45,550 --> 00:04:51,370 So it's statistically likely that maybe a user inside of our application has used one of these very 72 00:04:51,370 --> 00:04:52,780 common passwords. 73 00:04:53,050 --> 00:04:57,430 So a malicious user could take all these different passwords and run it through the same hashing algorithm 74 00:04:57,430 --> 00:05:03,670 we are using once again in our case we're using a hashing algorithm called secret so they would then 75 00:05:03,670 --> 00:05:08,360 have essentially a table that says OK here's all these very common passwords. 76 00:05:08,470 --> 00:05:14,030 And if we feed these through that hashing algorithm here's the output we would get if a malicious user 77 00:05:14,030 --> 00:05:18,920 then somehow got access to our database they could then look at all the different passwords that are 78 00:05:18,920 --> 00:05:19,640 stored inside there. 79 00:05:19,640 --> 00:05:25,470 And remember we now have hashed passwords inside so this malicious user could then take a look at this 80 00:05:25,470 --> 00:05:30,060 password that we stored inside of our database and they can say OK clearly I can't really interpret 81 00:05:30,300 --> 00:05:36,450 what that stored password is but they can't take a look at that hashed password and compare it against 82 00:05:36,510 --> 00:05:39,530 a list of existing hash passwords that they already have. 83 00:05:40,380 --> 00:05:45,120 So they could look at that string right there of ADR blah blah blah and compared against that one. 84 00:05:45,130 --> 00:05:48,220 OK not the same not the same not the same. 85 00:05:48,240 --> 00:05:52,760 Oh look at that that output right there is identical to this password right here. 86 00:05:52,770 --> 00:05:58,070 That means that this user's password must have been one two three four five six seven eight. 87 00:05:58,080 --> 00:06:05,770 So again we refer to this as a rainbow table attack to secure ourselves against this we add in one additional 88 00:06:05,770 --> 00:06:07,720 step to this hashing process. 89 00:06:07,750 --> 00:06:11,050 So this is what we referred to as generating a salt. 90 00:06:11,050 --> 00:06:15,820 So when we take that user's initial password when they first sign up to our application we're going 91 00:06:15,820 --> 00:06:20,350 to simultaneously generate a random string of characters called a salt. 92 00:06:20,350 --> 00:06:25,360 We're then going to join the user's password together with that random string so we can imagine we just 93 00:06:25,360 --> 00:06:31,090 kind of take those two strings and concatenate them together like so we're then going to take that can 94 00:06:31,100 --> 00:06:36,760 net caffeinated output and feed it through our hashing algorithm and then very critically we're going 95 00:06:36,760 --> 00:06:43,030 to take that salt and we're going to copy it independent onto the very end of our hashed output so notice 96 00:06:43,030 --> 00:06:47,980 how there's the dot right there and then on the right hand side is the salt that we have generated. 97 00:06:47,980 --> 00:06:53,710 So now we are storing both the hash and salted password along with just the salt. 98 00:06:53,710 --> 00:06:54,580 So you might be kind of curious. 99 00:06:54,610 --> 00:06:54,810 OK. 100 00:06:54,820 --> 00:06:56,920 How does that actually solve anything here. 101 00:06:56,920 --> 00:07:02,920 We'll think about what a malicious user would now have to do to kind of do that back tracing attack. 102 00:07:02,920 --> 00:07:08,110 They would have to have a super comprehensive list where essentially they take a look at every single 103 00:07:08,110 --> 00:07:11,480 password you know all 5000 of the most different common passwords. 104 00:07:11,730 --> 00:07:17,050 And if they wanted to somehow interpret this over here the hash password plus the salt they would have 105 00:07:17,050 --> 00:07:22,240 to have some entry of our hash password dot and then whatever the salt is. 106 00:07:22,240 --> 00:07:27,210 Now in this case I listed out salt as like just the word salt and salt two salt Three salt four. 107 00:07:27,280 --> 00:07:32,090 But in reality the salt that gets generated is a string of random characters. 108 00:07:32,140 --> 00:07:38,260 So there could be a huge set of different possible outcomes for trying to have like some established 109 00:07:38,260 --> 00:07:42,380 password right there or some established hash password plus some salt in other words. 110 00:07:42,400 --> 00:07:47,830 This list right here would go down for a very very very long time and a malicious user would have to 111 00:07:47,860 --> 00:07:53,680 generate that entire comprehensive list for every different one of these different common passwords. 112 00:07:53,770 --> 00:07:58,860 And so this completely solves the issue of this rainbow table attack OK. 113 00:07:58,910 --> 00:08:04,370 That's kind of a quick overview of what's going on with this password hashing and salting and whatnot. 114 00:08:04,400 --> 00:08:07,540 So now that we've got a quick overview done let's take a quick pause right here. 115 00:08:07,550 --> 00:08:12,110 When we come back the next video we're going to add in some salting and hashing to our application. 116 00:08:12,110 --> 00:08:16,970 Anytime we try to store a password or compare a password to log user in in the future.