1 00:00:00,000 --> 00:00:01,710 [Narrator] So we're now at a point where 2 00:00:01,710 --> 00:00:03,480 we need to compare our passwords. 3 00:00:03,480 --> 00:00:06,300 Is the password of our saved user 4 00:00:06,300 --> 00:00:08,460 equal to the password that was supplied 5 00:00:08,460 --> 00:00:10,713 by the request to sign in? 6 00:00:11,550 --> 00:00:14,640 This goes back to the topic of bcrypt. 7 00:00:14,640 --> 00:00:17,460 So I'm going to open up my user model over here. 8 00:00:17,460 --> 00:00:19,890 If you recall, we were salting 9 00:00:19,890 --> 00:00:22,683 and hashing our passwords before we saved them. 10 00:00:24,810 --> 00:00:26,220 We were also looking at a diagram 11 00:00:26,220 --> 00:00:27,750 that explained what was going on 12 00:00:27,750 --> 00:00:30,300 with the salt and the plain password. 13 00:00:30,300 --> 00:00:31,290 So if you recall, 14 00:00:31,290 --> 00:00:33,840 I said that we were generating a salt, 15 00:00:33,840 --> 00:00:37,560 we were using it to hash, or encrypt, our password, 16 00:00:37,560 --> 00:00:39,990 and then the saved record in the database 17 00:00:39,990 --> 00:00:43,740 was the salt plus the hashed password. 18 00:00:43,740 --> 00:00:47,163 So we were saving both the salt and the encrypted password. 19 00:00:48,870 --> 00:00:50,340 So this record right here, 20 00:00:50,340 --> 00:00:54,090 this salt plus hashed password, when we want to sign in, 21 00:00:54,090 --> 00:00:56,640 when we want to compare a password, 22 00:00:56,640 --> 00:01:00,060 this record right here we are storing in our database. 23 00:01:00,060 --> 00:01:01,830 We're going to retrieve it again. 24 00:01:01,830 --> 00:01:03,930 So this little square right here represents 25 00:01:03,930 --> 00:01:06,390 the saved record in the database. 26 00:01:06,390 --> 00:01:09,120 So here's how we're gonna compare the passwords. 27 00:01:09,120 --> 00:01:11,670 We're going to take the salt, right? 28 00:01:11,670 --> 00:01:14,490 That's kind of like the encryption key of sorts. 29 00:01:14,490 --> 00:01:18,510 We're going to encrypt the submitted password 30 00:01:18,510 --> 00:01:20,670 that the user supplied in the request. 31 00:01:20,670 --> 00:01:24,330 That's going to produce a new hashed password. 32 00:01:24,330 --> 00:01:27,990 And then we compare the stored hashed password 33 00:01:27,990 --> 00:01:29,640 with the new hashed password. 34 00:01:29,640 --> 00:01:32,220 If they are the same, then if they are equal, 35 00:01:32,220 --> 00:01:34,290 then they must be the same password. 36 00:01:34,290 --> 00:01:37,230 We don't ever actually end up decrypting 37 00:01:37,230 --> 00:01:38,190 this hashed password. 38 00:01:38,190 --> 00:01:40,500 There's really no concept of decrypting it. 39 00:01:40,500 --> 00:01:43,710 All we're ever doing is attempting to encrypt, 40 00:01:43,710 --> 00:01:45,960 or hash, submitted passwords, 41 00:01:45,960 --> 00:01:48,360 and then we see if they are identical 42 00:01:48,360 --> 00:01:51,840 in their hashed state to our saved password. 43 00:01:51,840 --> 00:01:54,960 So that's the full circle on bcrypt. 44 00:01:54,960 --> 00:01:57,090 Let's go through it one more time. 45 00:01:57,090 --> 00:01:59,520 Bcrypt. Using bcrypt, we created a salt, 46 00:01:59,520 --> 00:02:01,320 which is like a key. 47 00:02:01,320 --> 00:02:04,830 We then took our plain password, we encrypted the password, 48 00:02:04,830 --> 00:02:07,050 turning it into a hashed password, 49 00:02:07,050 --> 00:02:08,669 and we saved in our database 50 00:02:08,669 --> 00:02:11,940 both the salt and the hashed password. 51 00:02:11,940 --> 00:02:13,710 Then at some point in the future 52 00:02:13,710 --> 00:02:15,750 when we want to compare passwords, 53 00:02:15,750 --> 00:02:18,750 see if someone is entering the correct one, 54 00:02:18,750 --> 00:02:21,540 we're going to pull off just the salt, 55 00:02:21,540 --> 00:02:23,220 just the encryption key. 56 00:02:23,220 --> 00:02:24,990 We're going to use it to encrypt 57 00:02:24,990 --> 00:02:28,590 the submitted password from the request from our user. 58 00:02:28,590 --> 00:02:31,020 That's gonna produce a hashed password 59 00:02:31,020 --> 00:02:32,670 and then we just compare and see 60 00:02:32,670 --> 00:02:35,940 if it's identical to the saved one in our database. 61 00:02:35,940 --> 00:02:38,220 So that is full circle on bcrypt. 62 00:02:38,220 --> 00:02:40,740 That's the key to everything here. 63 00:02:40,740 --> 00:02:43,380 So we're never going to actually decrypt 64 00:02:43,380 --> 00:02:44,733 our saved password. 65 00:02:46,410 --> 00:02:49,532 All right, so let's give a shot at this logic here. 66 00:02:49,532 --> 00:02:53,550 We're going to add a method to our user model 67 00:02:53,550 --> 00:02:56,250 to do this password comparison for us. 68 00:02:56,250 --> 00:02:59,250 So I'm in our user dot js file right now. 69 00:02:59,250 --> 00:03:01,530 I'm gonna go beneath our pre-save hook, 70 00:03:01,530 --> 00:03:04,500 where we generated the salt and the hash, 71 00:03:04,500 --> 00:03:06,210 and I'm going to add another helper 72 00:03:06,210 --> 00:03:10,320 in here on my user schema methods. 73 00:03:10,320 --> 00:03:12,180 So this methods object right here. 74 00:03:12,180 --> 00:03:14,970 It basically says, whenever we create a user object 75 00:03:14,970 --> 00:03:17,520 it's going to have access to any functions 76 00:03:17,520 --> 00:03:20,010 that we define on this methods property. 77 00:03:20,010 --> 00:03:21,750 So we're gonna define a new function 78 00:03:21,750 --> 00:03:23,463 called compare password. 79 00:03:25,200 --> 00:03:26,970 It's gonna be a function. 80 00:03:26,970 --> 00:03:29,530 It's going to take a candidate password 81 00:03:30,510 --> 00:03:31,833 and a callback. 82 00:03:35,160 --> 00:03:37,620 So we've got user schema. 83 00:03:37,620 --> 00:03:42,060 We're adding a instance method called compare password. 84 00:03:42,060 --> 00:03:44,730 It is a function that's gonna take a candidate password. 85 00:03:44,730 --> 00:03:47,280 In other words, the password that some user is submitting, 86 00:03:47,280 --> 00:03:50,163 attempting to sign in, and a callback. 87 00:03:51,420 --> 00:03:54,120 So we're going to use the bcrypt library again. 88 00:03:54,120 --> 00:03:57,210 We're gonna use bcrypt compare 89 00:03:57,210 --> 00:03:58,780 our candidate password 90 00:04:00,960 --> 00:04:03,450 with this dot password. 91 00:04:03,450 --> 00:04:04,800 This, in this case, 92 00:04:04,800 --> 00:04:06,510 is a reference to our user model. 93 00:04:06,510 --> 00:04:11,133 So this dot password is our hashed and salted password. 94 00:04:12,810 --> 00:04:16,050 We're then gonna toss another callback to this 95 00:04:16,050 --> 00:04:18,903 of err and is match, 96 00:04:20,576 --> 00:04:22,590 and we'll say if there was an err 97 00:04:22,590 --> 00:04:24,363 during the comparison, 98 00:04:26,100 --> 00:04:28,773 return, call back with the err. 99 00:04:29,824 --> 00:04:32,230 Otherwise, call to callback 100 00:04:33,630 --> 00:04:35,793 with null and is match. 101 00:04:36,750 --> 00:04:38,730 So bcrpyt behind the scenes 102 00:04:38,730 --> 00:04:40,590 is really doing that comparison for us. 103 00:04:40,590 --> 00:04:44,220 It's taking the salt plus the hashed password. 104 00:04:44,220 --> 00:04:47,250 It's going to internally do that hashing process 105 00:04:47,250 --> 00:04:48,960 on the candidate password. 106 00:04:48,960 --> 00:04:50,040 And then it's gonna decide, hey, 107 00:04:50,040 --> 00:04:52,380 are these two things equal, yes or no? 108 00:04:52,380 --> 00:04:54,833 If they are equal, is match is going to be true. 109 00:04:54,833 --> 00:04:56,550 Otherwise, if they're not the same, 110 00:04:56,550 --> 00:04:57,783 it's gonna be false. 111 00:04:58,890 --> 00:05:00,030 All right, So this is good. 112 00:05:00,030 --> 00:05:02,130 Let's stop here and continue 113 00:05:02,130 --> 00:05:03,540 in the next section where we can now 114 00:05:03,540 --> 00:05:06,370 put this to use inside of our local strategy. 115 00:05:06,370 --> 00:05:07,713 I'll see you there.