1
00:00:00,180 --> 00:00:05,850
In this video we're going to kick off our section on authentication and security by starting with one

2
00:00:05,850 --> 00:00:13,190
of the most basic things every application should do which is securely storing users passwords.

3
00:00:13,200 --> 00:00:19,860
So right now we take the password in from the user and we store it in the database exactly as they typed

4
00:00:19,860 --> 00:00:20,380
it.

5
00:00:20,400 --> 00:00:26,520
So if I had over two robo three teeth and go to my users collection I can view the password for each

6
00:00:26,520 --> 00:00:28,760
and every user over in the database.

7
00:00:28,800 --> 00:00:33,430
Right here I have the three passwords exactly as they were provided.

8
00:00:33,600 --> 00:00:39,060
This is known as storing the password in plain text and for passwords.

9
00:00:39,060 --> 00:00:41,130
This is a terrible idea.

10
00:00:41,130 --> 00:00:47,790
Now the problem with storing plain text passwords is that most users use these same password for multiple

11
00:00:47,790 --> 00:00:48,740
accounts.

12
00:00:48,780 --> 00:00:51,270
So let's say our database did get hacked.

13
00:00:51,270 --> 00:00:55,370
Sure someone would be able to access the task data for all of the users.

14
00:00:55,380 --> 00:00:57,640
And that's definitely not ideal.

15
00:00:57,690 --> 00:01:04,470
But what's worse is we've exposed the user to further hacks because now all of their credentials are

16
00:01:04,470 --> 00:01:05,530
out in the open.

17
00:01:05,550 --> 00:01:12,240
Someone could try to use these same credentials for online banking and email a PayPal account or something

18
00:01:12,480 --> 00:01:16,620
where there's way more sensitive information than their to do list.

19
00:01:16,680 --> 00:01:23,880
So we don't want to store the password in plain text because we are leaving users exposed to further

20
00:01:23,880 --> 00:01:24,680
problems.

21
00:01:24,690 --> 00:01:26,760
Should this information get out.

22
00:01:26,760 --> 00:01:33,150
Now yes in an ideal world people would stop using these same password for all of their accounts.

23
00:01:33,270 --> 00:01:36,400
And most people are definitely catching on to that.

24
00:01:36,510 --> 00:01:43,470
But the vast majority of people who use the Internet for very basic things they're not as savvy as others.

25
00:01:43,470 --> 00:01:50,490
They're not using something like last pass to auto generate unique secure passwords for all their accounts.

26
00:01:50,490 --> 00:01:54,570
They have their birthday followed by their favorite hobby as their password.

27
00:01:54,780 --> 00:02:01,500
And it's our job as developers to do our best to keep things secure in a world where we don't have complete

28
00:02:01,500 --> 00:02:05,050
control over the password the user picked.

29
00:02:05,070 --> 00:02:13,620
So the solution is to store not a plain text a password but a hashed password the hashed value is going

30
00:02:13,620 --> 00:02:16,260
to look nothing like the plain text password.

31
00:02:16,280 --> 00:02:22,800
And if someone was to hack the database and get a hold of all of the users hashed passwords they would

32
00:02:22,800 --> 00:02:28,680
be useless because the algorithm we're going to use to generate it is not reversible.

33
00:02:28,680 --> 00:02:34,020
So we'll learn more about all of this as we actually play around with the hashing algorithm that will

34
00:02:34,020 --> 00:02:38,730
be using the algorithm that we're going to use is known as B correct.

35
00:02:38,760 --> 00:02:43,190
It is a very secure widely used hashing algorithm.

36
00:02:43,200 --> 00:02:49,950
It's great for all sorts of crypto graphical use cases including this one securely storing a user's

37
00:02:49,950 --> 00:02:57,360
password we can get access to an implementation of the B script algorithm in our node j s code by installing

38
00:02:57,360 --> 00:02:59,670
and using an NPM module.

39
00:02:59,670 --> 00:03:02,790
So let's head over to the browser to check this out.

40
00:03:02,850 --> 00:03:11,760
We can find it by googling NPM B crypt J S and we're looking for the B crypt J S NPM package which is

41
00:03:11,760 --> 00:03:13,970
the first result right here.

42
00:03:13,980 --> 00:03:17,920
Now if we head over to this we can learn a bit more about exactly what it is.

43
00:03:17,970 --> 00:03:24,430
Right here it is a super popular library with about two hundred thousand weekly downloads and it's going

44
00:03:24,430 --> 00:03:30,120
to give us a few functions we can use to securely store and work with passwords.

45
00:03:30,150 --> 00:03:36,270
So let's go ahead and get this installed and then mess around with it inside of our code over in Visual

46
00:03:36,270 --> 00:03:37,510
Studio code.

47
00:03:37,530 --> 00:03:46,140
I'm going to use control C to shut down the dev server and I'll use NPM I to install B crypt J S at

48
00:03:46,140 --> 00:03:50,130
the latest version two point four point three.

49
00:03:50,130 --> 00:03:55,620
Now if I go ahead and run this installation command it's going to install it as a dependency in the

50
00:03:55,620 --> 00:04:01,740
task manager app and once it's installed we're going to start by messing around with it right here and

51
00:04:01,770 --> 00:04:06,720
index that J S then we'll actually integrate it into the application.

52
00:04:06,720 --> 00:04:09,700
Once we understand how hashing works.

53
00:04:09,780 --> 00:04:17,050
So right here what I'm going to do is create an async function we can use to mess around with this concept.

54
00:04:17,100 --> 00:04:22,580
My function equals a new async aero function.

55
00:04:22,710 --> 00:04:26,160
Then down below I'm just going to call my function.

56
00:04:26,160 --> 00:04:32,130
And the reason I'm doing this is so we can use async await since what we're about to work with B crypt

57
00:04:32,160 --> 00:04:34,950
J S does indeed use promises.

58
00:04:34,950 --> 00:04:38,820
So we'll use a wait in order to manage those promises.

59
00:04:38,820 --> 00:04:42,470
And right here we're also going to require the library.

60
00:04:42,510 --> 00:04:48,270
Now I'm putting that right here just temporarily as we know we typically require things up at the top

61
00:04:48,270 --> 00:04:51,990
of the file that for this a little example which we'll delete in a moment.

62
00:04:51,990 --> 00:04:54,690
This is perfectly fine right here.

63
00:04:54,690 --> 00:05:01,240
We're going to create a constant called B crypt and we're going to get its value as the return value

64
00:05:01,240 --> 00:05:06,120
from calling require and we're gonna load in the B crypt J S library.

65
00:05:06,130 --> 00:05:10,270
Now let's go ahead and start with a plain text password to get started.

66
00:05:10,270 --> 00:05:14,890
We need a plain text password so let's create a variable to store that.

67
00:05:14,890 --> 00:05:21,880
I'll create a password variable and we'll pick a password like Red One two three four five exclamation

68
00:05:21,880 --> 00:05:22,750
mark.

69
00:05:22,750 --> 00:05:26,760
Now down below that we're going to create the hashed password.

70
00:05:26,890 --> 00:05:32,830
So the plaintext password is what the user provides us the hash to password is what will actually end

71
00:05:32,830 --> 00:05:33,930
up story.

72
00:05:33,970 --> 00:05:41,290
So right here another concept for hashed password and we're going to set this equal to and this is where

73
00:05:41,290 --> 00:05:44,470
we use a method from the B script library.

74
00:05:44,640 --> 00:05:48,550
It is the hash method and it returns a promise.

75
00:05:48,550 --> 00:05:55,570
So right here we can go ahead and use a weight with that promise to get the result the hashed password.

76
00:05:55,570 --> 00:05:56,640
So what am I going to do.

77
00:05:56,650 --> 00:06:02,980
I'm going to call B crypt dot hash and we are going to provide it to arguments.

78
00:06:02,980 --> 00:06:09,310
The first is the plain text password which I have access to via the password variable.

79
00:06:09,310 --> 00:06:12,890
And the second is the number of rounds we want to perform.

80
00:06:12,910 --> 00:06:17,810
Now the number of rounds determines how many times the hashing algorithm is executed.

81
00:06:17,890 --> 00:06:20,520
And I find that a really good number is eight.

82
00:06:20,530 --> 00:06:24,080
It strikes a nice balance between security and speed.

83
00:06:24,250 --> 00:06:28,860
If we use too few rounds the algorithm is a bit easier to crack.

84
00:06:28,960 --> 00:06:34,610
If we use too many rounds it takes so long to run that our application becomes useless.

85
00:06:34,720 --> 00:06:38,140
Eight seems to strike a nice bounce between the two.

86
00:06:38,200 --> 00:06:43,060
And this was the value recommended by the original creator of the algorithm.

87
00:06:43,150 --> 00:06:49,450
Now down below let's go ahead and log out both password and hash password to see what we get right here

88
00:06:49,890 --> 00:06:52,180
console dot log password.

89
00:06:52,390 --> 00:07:00,730
Then down below console log hashed password and once we have both logged I'm going to save the file

90
00:07:00,910 --> 00:07:05,580
and run the dev server from the terminal so NPM run Dev.

91
00:07:05,740 --> 00:07:11,110
This is going to start up the Express application but it's also going to run our little example and

92
00:07:11,110 --> 00:07:13,060
write down below what do we get.

93
00:07:13,060 --> 00:07:20,230
I have my plain text password read one two three four five then I have my hashed password showing up

94
00:07:20,530 --> 00:07:24,940
and this is the value that will end up storing in the database.

95
00:07:24,970 --> 00:07:31,330
Now there's an important distinction between hashing algorithms and encryption algorithms with encryption

96
00:07:31,360 --> 00:07:33,740
we can get the original value back.

97
00:07:33,850 --> 00:07:36,180
So let's say I'm trying to encrypt these string.

98
00:07:36,190 --> 00:07:42,910
Andrew the output the encrypted value would look like some random series of characters but using the

99
00:07:42,910 --> 00:07:50,140
encryption algorithm I could always turn that random series of characters back in to the original value.

100
00:07:50,140 --> 00:07:57,190
Andrew hashing algorithms don't work like this hashing algorithms are one way algorithms which means

101
00:07:57,190 --> 00:07:59,180
we can't reverse the process.

102
00:07:59,230 --> 00:08:05,400
I take a password like my pass I put it in to the end hashing algorithm and the output.

103
00:08:05,410 --> 00:08:12,370
Is that really long hash this is something that we can not reverse hashing algorithms by design are

104
00:08:12,370 --> 00:08:13,500
not reversible.

105
00:08:13,510 --> 00:08:17,200
So there's no way to get the plain text version back out.

106
00:08:17,230 --> 00:08:23,710
Now this is by design so you're probably wondering how do you do something like log in where I want

107
00:08:23,710 --> 00:08:30,070
to take the password that someone provided and see if it actually matches the hash we've stored in the

108
00:08:30,070 --> 00:08:31,150
database.

109
00:08:31,300 --> 00:08:36,290
Well hashing algorithms like a B crypt give us a very easy way to do that.

110
00:08:36,340 --> 00:08:43,090
All we do is we hash the plaintext password that they provided when logging in and we can pair that

111
00:08:43,090 --> 00:08:46,690
hash with the hash stored in the database.

112
00:08:46,750 --> 00:08:49,700
Now be crypt gives us a method to get that done.

113
00:08:49,720 --> 00:08:52,990
This is the other method we're gonna need from the library.

114
00:08:52,990 --> 00:08:59,290
So let's take a moment to explore that before worrying about implementing anything into our API right

115
00:08:59,290 --> 00:08:59,850
here.

116
00:08:59,860 --> 00:09:06,310
The goal is to figure out if a given password matches the hashed password that we'll say is stored in

117
00:09:06,310 --> 00:09:07,750
the database.

118
00:09:07,750 --> 00:09:14,190
I'm going to create a new constant for that and I'll call it something like Is match is match we'll

119
00:09:14,200 --> 00:09:21,400
be true if we do have a match and the log in operation is successful and is match will be false if the

120
00:09:21,400 --> 00:09:26,170
password does not match the original one used when signing up.

121
00:09:26,170 --> 00:09:28,500
Now this method also returns a promise.

122
00:09:28,540 --> 00:09:30,700
So I'll use a wait again.

123
00:09:30,700 --> 00:09:34,780
And right here it is B crypt dot compare.

124
00:09:34,780 --> 00:09:37,420
Now compare takes in two arguments.

125
00:09:37,450 --> 00:09:40,130
The first is the plaintext password.

126
00:09:40,240 --> 00:09:45,820
So let's say I'm logging in with red one two three four five exclamation mark.

127
00:09:45,820 --> 00:09:50,200
And the second is the hash which for us would be stored in the database.

128
00:09:50,260 --> 00:09:55,330
Right here though I have it accessible via that hashed password variable.

129
00:09:55,330 --> 00:10:04,640
Now down below we'll go ahead and log that to see what the value of the bullion is console log is match

130
00:10:05,000 --> 00:10:06,200
with that in place.

131
00:10:06,200 --> 00:10:12,200
I'm going to save the program and down below we do get a boolean the Boolean true.

132
00:10:12,200 --> 00:10:19,820
So right here I can see that this password is considered a match when compared to the following hash.

133
00:10:19,820 --> 00:10:25,760
So behind the scenes the B script algorithm rehashed the plain text password and then it compared it

134
00:10:25,760 --> 00:10:28,570
with the hash we already had in place.

135
00:10:28,610 --> 00:10:31,860
Now that the passwords don't match we're gonna get false back.

136
00:10:31,940 --> 00:10:36,920
So let's say I'm trying to log into someone else's account and I don't know their password.

137
00:10:36,920 --> 00:10:42,930
I'll go ahead and switch it from an upper case R to a lower case r i save the program.

138
00:10:43,040 --> 00:10:50,030
And now we can see that the password we provided is not a match when compared with the hash we created

139
00:10:50,060 --> 00:10:51,030
earlier.

140
00:10:51,050 --> 00:10:56,750
That's because the hash we created earlier was created with a different password where we had a capital

141
00:10:56,750 --> 00:11:03,470
R instead of a lower case r so using B script and the hash and compare methods.

142
00:11:03,470 --> 00:11:10,100
We're gonna be able to securely store passwords while still being able to figure out if someone is logging

143
00:11:10,100 --> 00:11:12,530
in with the correct credentials.

144
00:11:12,530 --> 00:11:18,140
Now that we've seen the basics of working with a hashing algorithm like B crypt let's go ahead and jump

145
00:11:18,140 --> 00:11:25,190
into the next video and actually hash users passwords before storing them in the database.

146
00:11:25,190 --> 00:11:26,740
I am excited to get to that.

147
00:11:26,810 --> 00:11:29,060
So let's jump right in to the next one.