1 00:00:00,690 --> 00:00:06,900 All right, so now that we've seen what some of the vulnerabilities might be for hashed passwords, 2 00:00:06,900 --> 00:00:15,360 it's time to level up and learn about a way that we can prevent these types of dictionary attacks or 3 00:00:15,360 --> 00:00:16,590 hash table cracks. 4 00:00:16,800 --> 00:00:20,260 And in order to do that, we have to learn about salting. 5 00:00:21,150 --> 00:00:23,130 Now, what exactly is salting? 6 00:00:23,370 --> 00:00:26,670 Well, we already know what hashing is. It's 7 00:00:26,670 --> 00:00:33,450 when we take a password, we run it through a hash function and we end up with a hash that we store 8 00:00:33,450 --> 00:00:34,350 on our database. 9 00:00:34,890 --> 00:00:41,220 And as we saw in the last lesson, passwords that are generated by humans are extremely insecure. 10 00:00:41,370 --> 00:00:47,190 They tend to be very short and they tend to be dictionary words that are extremely easy to look up and 11 00:00:47,190 --> 00:00:48,540 create a hash table 12 00:00:48,540 --> 00:00:52,680 for. Now, salting takes hashing a little bit further. 13 00:00:52,890 --> 00:01:01,290 In addition to the password, we also generate a random set of characters, and those characters along 14 00:01:01,290 --> 00:01:06,560 with the user's password gets combined and then put through the hash function. 15 00:01:06,630 --> 00:01:13,470 So the resulting hash is created from both the password as well as that random unique salt. 16 00:01:13,650 --> 00:01:20,400 So that means no matter how simple the password of the user is, adding that salt increases its complexity, 17 00:01:20,400 --> 00:01:26,170 increases the number of characters, and we make our user database a lot more secure. 18 00:01:26,340 --> 00:01:30,360 So consider the previous problem that we saw in the last lesson when 19 00:01:30,600 --> 00:01:32,350 we covered hacking 101. 20 00:01:32,370 --> 00:01:37,860 Now we know that three of our users have the same password and we figured that out because they all 21 00:01:37,860 --> 00:01:38,970 had the same hash. 22 00:01:39,150 --> 00:01:47,790 Now, on the other hand, if we had generated a random set of characters, which is the salt, and combined 23 00:01:47,790 --> 00:01:53,820 the password with the salt in order to generate the hash, then they won't have the same hash in our 24 00:01:53,820 --> 00:01:54,800 user database. 25 00:01:55,020 --> 00:02:01,380 So let's try and generate Emily's hash from her password. So we know that her password is qwerty and 26 00:02:01,380 --> 00:02:02,970 we generate a random salt. 27 00:02:03,150 --> 00:02:06,540 So then let's go ahead and put in her password, 28 00:02:07,020 --> 00:02:14,670 qwerty, and then we append at the end that random salt that we generated and we end up with a hash. 29 00:02:15,510 --> 00:02:24,990 Now this hash, however, is not the same as Tony's hash or Angela's hash because the salt is different 30 00:02:24,990 --> 00:02:25,830 each time. 31 00:02:26,040 --> 00:02:32,760 Now the salt is something that the user doesn't have to remember and instead, it's stored in the database 32 00:02:33,030 --> 00:02:34,410 along with the hash. 33 00:02:34,800 --> 00:02:40,740 So that means when the user types in their password, when they try to log in, you combine their password 34 00:02:40,740 --> 00:02:46,170 with the salt and if you generate the same hash, then they must have had the same password. 35 00:02:46,470 --> 00:02:47,640 It's kind of clever, isn't it? 36 00:02:48,060 --> 00:02:53,670 And on our database, of course, we wouldn't be storing their passwords, but only the salt and the 37 00:02:53,670 --> 00:02:54,190 hash. 38 00:02:54,210 --> 00:02:56,460 Now consider our previous statistics. 39 00:02:56,610 --> 00:03:01,950 You can generate about 20 billion MD5 hashes per second. 40 00:03:02,040 --> 00:03:10,210 So even if we added a salt and we made it harder to generate a hash table, with some of the latest GPUs 41 00:03:10,230 --> 00:03:16,260 you can still probably generate a hash table with all salt combinations relatively quickly. 42 00:03:16,770 --> 00:03:20,040 So what else can we do to increase the security? 43 00:03:20,490 --> 00:03:24,270 Well, we can use something other than MD5, right? 44 00:03:24,510 --> 00:03:30,230 Another hashing algorithm that's valued because it's incredibly slow. 45 00:03:30,780 --> 00:03:32,760 And this is where bscript comes in. 46 00:03:33,210 --> 00:03:40,800 This is one of the industry-standard hashing algorithms that developers use to keep their users' passwords 47 00:03:40,800 --> 00:03:48,720 safe, because while you can calculate 20 billion MD5 hashes per second, even the latest and 48 00:03:48,720 --> 00:03:57,330 the greatest GPUs in 2019 can still calculate only about 17000 bcrypt hashes per second, which makes 49 00:03:57,330 --> 00:04:05,700 it dramatically harder for a hacker to generate those pre-compiled hash tables. And a salted hash table 50 00:04:05,730 --> 00:04:08,220 instead of taking something like three seconds 51 00:04:08,430 --> 00:04:10,230 If it was hashed with MD5, 52 00:04:10,410 --> 00:04:15,780 if it was hash using bcrypt, it would take you something like eight months, which is not really worth 53 00:04:15,780 --> 00:04:16,600 the hacker's while. 54 00:04:16,740 --> 00:04:22,890 They'll probably go and search out a company that has less security enabled. And to make our passwords 55 00:04:22,920 --> 00:04:24,480 even more secure 56 00:04:24,480 --> 00:04:31,170 when we're using bcrypt, it has a concept of what's called salt rounds, how many rounds you're going 57 00:04:31,170 --> 00:04:33,000 to salt your password with. 58 00:04:33,240 --> 00:04:39,090 And obviously the more rounds you do, the saltier your password and also the more secure it is from 59 00:04:39,090 --> 00:04:39,510 hackers. 60 00:04:39,690 --> 00:04:42,110 So, what exactly are salt rounds? 61 00:04:42,420 --> 00:04:50,520 Well, let's say that our original user password was qwerty, and we generate a random set of characters 62 00:04:50,520 --> 00:04:51,450 as the salt. 63 00:04:52,500 --> 00:04:55,350 So now we have qwerty and a random set of salt. 64 00:04:55,800 --> 00:04:59,790 We pass it through our hash function, bcrypt, and we end up with a 65 00:04:59,990 --> 00:05:07,820 hash. Now that one round of salting, if we wanted to have two rounds of salting, then we take the hash 66 00:05:07,820 --> 00:05:13,100 that was generated in round one and we add the same salt from before. 67 00:05:13,580 --> 00:05:19,400 And now we run it through, bcrypt, the hash function again, and we end up with a different hash. 68 00:05:19,970 --> 00:05:24,650 And the number of times you do this is the number of salt rounds. 69 00:05:25,160 --> 00:05:30,630 Now, the reason why this is genius is because as computers get faster... 70 00:05:30,890 --> 00:05:37,730 remember that Moore's Law says that every year the number of transistors in a computer chip almost doubles 71 00:05:37,880 --> 00:05:41,030 and the cost of that faster computer halves. 72 00:05:41,270 --> 00:05:45,200 So every year you can get more computing power for less money. 73 00:05:45,320 --> 00:05:47,330 And this is where salt rounds comes in. 74 00:05:47,480 --> 00:05:54,410 When you're hashing your passwords using bcrypt, you can set the number of rounds you want to salt 75 00:05:54,410 --> 00:05:55,240 your password. 76 00:05:55,340 --> 00:06:02,990 So that means maybe this year in 2019, you salted ten rounds, but maybe next year you can increase that 77 00:06:02,990 --> 00:06:04,270 number to 12. 78 00:06:04,790 --> 00:06:12,080 And for every increase in that number, the amount of time that it takes to hash your password doubles. 79 00:06:12,350 --> 00:06:19,640 And so that means you don't have to change your hashing algorithm or update your code other than simply 80 00:06:19,640 --> 00:06:22,460 changing one number to keep up with the times. 81 00:06:22,700 --> 00:06:30,410 So just to review, coming back to that user database, we'll have each user's username stored, we'll have 82 00:06:30,410 --> 00:06:38,210 their randomly generated salt stored, and then we'll store their hash after a set number of salting 83 00:06:38,210 --> 00:06:38,660 rounds. 84 00:06:40,160 --> 00:06:45,200 And when it comes to checking their password when they login, we'ill take the password that they put 85 00:06:45,200 --> 00:06:51,710 in, combine it with the salt that's stored in the database, and run it through the same number of salting 86 00:06:51,710 --> 00:06:57,980 rounds until we end up with the final hash and we compare the hash against the one that's stored in 87 00:06:57,980 --> 00:07:02,280 the database to see if they've entered the correct password. 88 00:07:02,570 --> 00:07:09,920 So let's give that a go in real life and implement salting rounds into our website's authentication.