WEBVTT 0 00:00.690 --> 00:06.900 All right, so now that we've seen what some of the vulnerabilities might be for hashed passwords, 1 00:06.900 --> 00:15.360 it's time to level up and learn about a way that we can prevent these types of dictionary attacks or 2 00:15.360 --> 00:16.590 hash table cracks. 3 00:16.800 --> 00:20.260 And in order to do that, we have to learn about salting. 4 00:21.150 --> 00:23.130 Now, what exactly is salting? 5 00:23.370 --> 00:26.670 Well, we already know what hashing is. It's 6 00:26.670 --> 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 7 00:33.450 --> 00:34.350 on our database. 8 00:34.890 --> 00:41.220 And as we saw in the last lesson, passwords that are generated by humans are extremely insecure. 9 00:41.370 --> 00:47.190 They tend to be very short and they tend to be dictionary words that are extremely easy to look up and 10 00:47.190 --> 00:48.540 create a hash table 11 00:48.540 --> 00:52.680 for. Now, salting takes hashing a little bit further. 12 00:52.890 --> 01:01.290 In addition to the password, we also generate a random set of characters, and those characters along 13 01:01.290 --> 01:06.560 with the user's password gets combined and then put through the hash function. 14 01:06.630 --> 01:13.470 So the resulting hash is created from both the password as well as that random unique salt. 15 01:13.650 --> 01:20.400 So that means no matter how simple the password of the user is, adding that salt increases its complexity, 16 01:20.400 --> 01:26.170 increases the number of characters, and we make our user database a lot more secure. 17 01:26.340 --> 01:30.360 So consider the previous problem that we saw in the last lesson when 18 01:30.600 --> 01:32.350 we covered hacking 101. 19 01:32.370 --> 01:37.860 Now we know that three of our users have the same password and we figured that out because they all 20 01:37.860 --> 01:38.970 had the same hash. 21 01:39.150 --> 01:47.790 Now, on the other hand, if we had generated a random set of characters, which is the salt, and combined 22 01:47.790 --> 01:53.820 the password with the salt in order to generate the hash, then they won't have the same hash in our 23 01:53.820 --> 01:54.800 user database. 24 01:55.020 --> 02:01.380 So let's try and generate Emily's hash from her password. So we know that her password is qwerty and 25 02:01.380 --> 02:02.970 we generate a random salt. 26 02:03.150 --> 02:06.540 So then let's go ahead and put in her password, 27 02:07.020 --> 02:14.670 qwerty, and then we append at the end that random salt that we generated and we end up with a hash. 28 02:15.510 --> 02:24.990 Now this hash, however, is not the same as Tony's hash or Angela's hash because the salt is different 29 02:24.990 --> 02:25.830 each time. 30 02:26.040 --> 02:32.760 Now the salt is something that the user doesn't have to remember and instead, it's stored in the database 31 02:33.030 --> 02:34.410 along with the hash. 32 02:34.800 --> 02:40.740 So that means when the user types in their password, when they try to log in, you combine their password 33 02:40.740 --> 02:46.170 with the salt and if you generate the same hash, then they must have had the same password. 34 02:46.470 --> 02:47.640 It's kind of clever, isn't it? 35 02:48.060 --> 02:53.670 And on our database, of course, we wouldn't be storing their passwords, but only the salt and the 36 02:53.670 --> 02:54.190 hash. 37 02:54.210 --> 02:56.460 Now consider our previous statistics. 38 02:56.610 --> 03:01.950 You can generate about 20 billion MD5 hashes per second. 39 03:02.040 --> 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 40 03:10.230 --> 03:16.260 you can still probably generate a hash table with all salt combinations relatively quickly. 41 03:16.770 --> 03:20.040 So what else can we do to increase the security? 42 03:20.490 --> 03:24.270 Well, we can use something other than MD5, right? 43 03:24.510 --> 03:30.230 Another hashing algorithm that's valued because it's incredibly slow. 44 03:30.780 --> 03:32.760 And this is where bscript comes in. 45 03:33.210 --> 03:40.800 This is one of the industry-standard hashing algorithms that developers use to keep their users' passwords 46 03:40.800 --> 03:48.720 safe, because while you can calculate 20 billion MD5 hashes per second, even the latest and 47 03:48.720 --> 03:57.330 the greatest GPUs in 2019 can still calculate only about 17000 bcrypt hashes per second, which makes 48 03:57.330 --> 04:05.700 it dramatically harder for a hacker to generate those pre-compiled hash tables. And a salted hash table 49 04:05.730 --> 04:08.220 instead of taking something like three seconds 50 04:08.430 --> 04:10.230 If it was hashed with MD5, 51 04:10.410 --> 04:15.780 if it was hash using bcrypt, it would take you something like eight months, which is not really worth 52 04:15.780 --> 04:16.600 the hacker's while. 53 04:16.740 --> 04:22.890 They'll probably go and search out a company that has less security enabled. And to make our passwords 54 04:22.920 --> 04:24.480 even more secure 55 04:24.480 --> 04:31.170 when we're using bcrypt, it has a concept of what's called salt rounds, how many rounds you're going 56 04:31.170 --> 04:33.000 to salt your password with. 57 04:33.240 --> 04:39.090 And obviously the more rounds you do, the saltier your password and also the more secure it is from 58 04:39.090 --> 04:39.510 hackers. 59 04:39.690 --> 04:42.110 So, what exactly are salt rounds? 60 04:42.420 --> 04:50.520 Well, let's say that our original user password was qwerty, and we generate a random set of characters 61 04:50.520 --> 04:51.450 as the salt. 62 04:52.500 --> 04:55.350 So now we have qwerty and a random set of salt. 63 04:55.800 --> 04:59.790 We pass it through our hash function, bcrypt, and we end up with a 64 04:59.990 --> 05:07.820 hash. Now that one round of salting, if we wanted to have two rounds of salting, then we take the hash 65 05:07.820 --> 05:13.100 that was generated in round one and we add the same salt from before. 66 05:13.580 --> 05:19.400 And now we run it through, bcrypt, the hash function again, and we end up with a different hash. 67 05:19.970 --> 05:24.650 And the number of times you do this is the number of salt rounds. 68 05:25.160 --> 05:30.630 Now, the reason why this is genius is because as computers get faster... 69 05:30.890 --> 05:37.730 remember that Moore's Law says that every year the number of transistors in a computer chip almost doubles 70 05:37.880 --> 05:41.030 and the cost of that faster computer halves. 71 05:41.270 --> 05:45.200 So every year you can get more computing power for less money. 72 05:45.320 --> 05:47.330 And this is where salt rounds comes in. 73 05:47.480 --> 05:54.410 When you're hashing your passwords using bcrypt, you can set the number of rounds you want to salt 74 05:54.410 --> 05:55.240 your password. 75 05:55.340 --> 06:02.990 So that means maybe this year in 2019, you salted ten rounds, but maybe next year you can increase that 76 06:02.990 --> 06:04.270 number to 12. 77 06:04.790 --> 06:12.080 And for every increase in that number, the amount of time that it takes to hash your password doubles. 78 06:12.350 --> 06:19.640 And so that means you don't have to change your hashing algorithm or update your code other than simply 79 06:19.640 --> 06:22.460 changing one number to keep up with the times. 80 06:22.700 --> 06:30.410 So just to review, coming back to that user database, we'll have each user's username stored, we'll have 81 06:30.410 --> 06:38.210 their randomly generated salt stored, and then we'll store their hash after a set number of salting 82 06:38.210 --> 06:38.660 rounds. 83 06:40.160 --> 06:45.200 And when it comes to checking their password when they login, we'ill take the password that they put 84 06:45.200 --> 06:51.710 in, combine it with the salt that's stored in the database, and run it through the same number of salting 85 06:51.710 --> 06:57.980 rounds until we end up with the final hash and we compare the hash against the one that's stored in 86 06:57.980 --> 07:02.280 the database to see if they've entered the correct password. 87 07:02.570 --> 07:09.920 So let's give that a go in real life and implement salting rounds into our website's authentication.