1
00:00:00,830 --> 00:00:05,000
In this video we're going to start working on hashing the user's password before we send it off to our

2
00:00:05,000 --> 00:00:06,440
database to be saved.

3
00:00:06,530 --> 00:00:11,480
In this video I want to give you a quick reminder on why we hash passwords in general and how the entire

4
00:00:11,480 --> 00:00:12,600
process works.

5
00:00:12,740 --> 00:00:16,850
If you are already familiar with password hashing go ahead and skip this video and take a look at the

6
00:00:16,850 --> 00:00:18,560
implementation in the next one.

7
00:00:18,560 --> 00:00:21,180
Otherwise stick around and let's get to it.

8
00:00:21,210 --> 00:00:21,480
All right.

9
00:00:21,510 --> 00:00:24,180
So in this diagram right here I'm showing you a bad approach.

10
00:00:24,180 --> 00:00:28,290
This is something that we are currently doing inside of our app but it's something we do not want to

11
00:00:28,290 --> 00:00:28,850
do.

12
00:00:28,920 --> 00:00:32,000
So we need to replace our current implementation.

13
00:00:32,220 --> 00:00:37,350
So at present our ReACT application or right now technically postman we're making a request to sign

14
00:00:37,350 --> 00:00:41,070
up to our app and we are including an email and a password.

15
00:00:41,070 --> 00:00:46,980
At present we are creating a new user document out of that using the email of test at test dot com and

16
00:00:46,980 --> 00:00:49,140
a password of whatever gets sent.

17
00:00:49,140 --> 00:00:54,580
In this case we're saying it's wordpress so we create a new user document and persist that to Mongo

18
00:00:54,580 --> 00:00:55,060
DB.

19
00:00:55,810 --> 00:01:00,580
So our password is sitting inside of this user's collection in plain text.

20
00:01:00,580 --> 00:01:06,280
This is a very bad approach because if anyone ever got access to our Mongo DB database they would see

21
00:01:06,280 --> 00:01:10,050
all the emails and passwords of our users.

22
00:01:10,050 --> 00:01:14,070
Now we don't really care about someone necessarily logging into our application.

23
00:01:14,070 --> 00:01:19,290
It's more that if a user or if some malicious person gets access to all these email and passwords our

24
00:01:19,290 --> 00:01:24,870
users might use the same email and password combination to log onto many other services.

25
00:01:24,870 --> 00:01:30,270
And so a malicious user could take test at test dot com inward word pass and then go and try to log

26
00:01:30,270 --> 00:01:34,820
on to my banking Web site and they might possibly successfully log in.

27
00:01:35,010 --> 00:01:40,890
So again Under no scenario under no circumstance do we ever store our passwords in plain text as we're

28
00:01:40,920 --> 00:01:42,220
currently doing.

29
00:01:42,240 --> 00:01:43,200
So how are we going to fix this.

30
00:01:43,500 --> 00:01:49,020
Well we're going to introduce password hashing this is a two step process that spans over these sign

31
00:01:49,050 --> 00:01:51,650
up and sign in Lowes.

32
00:01:51,720 --> 00:01:54,080
Let's first focus on what occurs during sign up.

33
00:01:54,090 --> 00:01:55,990
This is what we are about to implement right now.

34
00:01:56,880 --> 00:02:01,660
So once again our ReACT app is going to make requests to sign up and maybe once again it's an email

35
00:02:01,660 --> 00:02:06,370
of test at test dot com and a password of WordPress.

36
00:02:06,440 --> 00:02:09,030
We are going to take that password and hash it.

37
00:02:09,110 --> 00:02:15,440
We're going to hash the password word pass when we have to string is going to produce a unique series

38
00:02:15,440 --> 00:02:20,620
of characters that are unique just for that word right there at that very particular string.

39
00:02:20,870 --> 00:02:26,660
So the word or the string of word pass might produce this hash during right here if you want to get

40
00:02:26,660 --> 00:02:28,490
more information about the hashing process.

41
00:02:28,490 --> 00:02:33,080
I encourage you to look it up online right now I'm just giving you a very quick overview on what we're

42
00:02:33,080 --> 00:02:34,950
going to be doing.

43
00:02:35,050 --> 00:02:39,620
We then take this hash password and stored inside of our database instead of the original plaintext

44
00:02:39,680 --> 00:02:40,750
one.

45
00:02:40,750 --> 00:02:48,500
So now we only have the email and the hash password not the original one so then we go ahead and create

46
00:02:48,500 --> 00:02:49,230
the new user.

47
00:02:49,310 --> 00:02:49,850
Really.

48
00:02:49,910 --> 00:02:52,640
Let's say this diagram should be a little bit closer to that right there.

49
00:02:53,930 --> 00:02:58,310
So now inside of our database we've only got the hash password with the hash passwords.

50
00:02:58,310 --> 00:03:03,200
There is no way or no easy way we should say to somehow figure out what the original password was.

51
00:03:03,710 --> 00:03:07,920
So some malicious user somehow got access to this email password combination.

52
00:03:08,000 --> 00:03:11,430
In theory hopefully there would not be much damage done.

53
00:03:11,450 --> 00:03:15,630
Now again there are scenarios where even a hash password can have some negative consequences.

54
00:03:15,680 --> 00:03:19,280
And in general we don't want anyone getting access to our data at all.

55
00:03:19,280 --> 00:03:27,190
But if it's some malicious user does get access to this hash password it's not as big a problem but

56
00:03:27,190 --> 00:03:28,640
that's just the sign up process.

57
00:03:28,660 --> 00:03:32,350
How do we actually make use of the hash password at some point time in the future.

58
00:03:32,350 --> 00:03:36,850
Well let's imagine the sign in flow that we're going to be implementing very shortly.

59
00:03:36,880 --> 00:03:42,360
So once again maybe our ReACT application sends a request to sign into our app when user signs in there

60
00:03:42,370 --> 00:03:47,870
are going to send us their email and password so as soon as we get that we are going to hash the password

61
00:03:47,930 --> 00:03:54,290
in the exact same way that we did when users signed up initially will hash the password and we once

62
00:03:54,290 --> 00:04:00,170
again that's get that same identical string we're then going to take a look and try to find a user saved

63
00:04:00,170 --> 00:04:05,420
inside of our database with the same email as the one that was just submitted test at test dot com.

64
00:04:06,230 --> 00:04:08,300
So we'll find that record right there.

65
00:04:08,300 --> 00:04:14,480
Now at this point time we've got these stored hashed password and we've got the hash version version

66
00:04:14,570 --> 00:04:17,720
of the password to the user just applied to us.

67
00:04:17,720 --> 00:04:24,050
We are going to check and see if the hashed passwords are equal to each other if they are equal to each

68
00:04:24,050 --> 00:04:24,320
other.

69
00:04:24,320 --> 00:04:29,700
That means that the user must have supplied the correct password and then at that point time are going

70
00:04:29,700 --> 00:04:35,490
to say OK you are or you have supplied some valid log in credentials we now consider you to be signed

71
00:04:35,490 --> 00:04:37,940
into our application so that's it.

72
00:04:37,970 --> 00:04:39,200
That's the flow.

73
00:04:39,320 --> 00:04:40,700
Now I went through this really quickly.

74
00:04:40,700 --> 00:04:44,850
So if any of this is still kind of confusing I would encourage you to do a little bit of research.

75
00:04:44,870 --> 00:04:48,230
Again I'm just giving you a quick reminder on how this stuff is working.

76
00:04:48,230 --> 00:04:52,720
Hopefully you have seen password hashing at least once in the past before.

77
00:04:52,720 --> 00:04:55,550
Well let's take a pause right here now that we got this review in place.

78
00:04:55,570 --> 00:04:58,570
We're going to start implementing the password hashing flow in the next video.