1
00:00:00.05 --> 00:00:03.05
- [Instructor] Properly
hashing passwords is a skill

2
00:00:03.05 --> 00:00:06.04
that every developer that
writes a public-facing

3
00:00:06.04 --> 00:00:09.09
web application needs to fully understand,

4
00:00:09.09 --> 00:00:12.01
unless they're using OAuth for everything

5
00:00:12.01 --> 00:00:16.04
and very few of us are using
OAuth for all of our use cases.

6
00:00:16.04 --> 00:00:18.07
So as such, even though
we are going to step away

7
00:00:18.07 --> 00:00:21.03
from the JCA just a little bit here,

8
00:00:21.03 --> 00:00:24.07
this really is very
critical so the developers

9
00:00:24.07 --> 00:00:29.00
understand the proper
way to hash passwords.

10
00:00:29.00 --> 00:00:31.00
I want to baseline a little bit here

11
00:00:31.00 --> 00:00:32.08
about what is the proper way to handle

12
00:00:32.08 --> 00:00:37.00
the passwords in a modern
internet connected system.

13
00:00:37.00 --> 00:00:41.05
First and foremost, never
ever ever ever store

14
00:00:41.05 --> 00:00:43.04
encrypted passwords.

15
00:00:43.04 --> 00:00:45.09
There is no legitimate reason why you need

16
00:00:45.09 --> 00:00:49.00
to keep a password of your customer

17
00:00:49.00 --> 00:00:51.08
in the encrypted fashion, ever.

18
00:00:51.08 --> 00:00:54.02
If you need to use their
username and password

19
00:00:54.02 --> 00:00:58.00
to authenticate to another
system, you should be using Oauth

20
00:00:58.00 --> 00:01:01.01
because you shouldn't have
their username and password

21
00:01:01.01 --> 00:01:03.05
freely available to use.

22
00:01:03.05 --> 00:01:07.02
Likewise, if you need to have
a reset password functionality

23
00:01:07.02 --> 00:01:10.00
or a forgot password functionality,

24
00:01:10.00 --> 00:01:11.09
the proper way to do that is to send them

25
00:01:11.09 --> 00:01:15.01
one-time tokens or use
some sort of a two factor

26
00:01:15.01 --> 00:01:17.08
strategy in order to reset their password.

27
00:01:17.08 --> 00:01:20.03
You don't ever need to send them an email

28
00:01:20.03 --> 00:01:22.00
where you've decrypted their password

29
00:01:22.00 --> 00:01:23.06
and put it in plain text.

30
00:01:23.06 --> 00:01:27.00
That's just a sign of a bad site.

31
00:01:27.00 --> 00:01:30.07
You should also never use
broken hash algorithms.

32
00:01:30.07 --> 00:01:33.03
If you have a site that's public facing

33
00:01:33.03 --> 00:01:37.08
or really even private as
well, that is using an MD5 hash

34
00:01:37.08 --> 00:01:42.04
for your passwords, stop
now and fix your problem.

35
00:01:42.04 --> 00:01:46.02
If you get hacked and your
password data gets dumped,

36
00:01:46.02 --> 00:01:49.06
not only will people know the
passwords of your customers,

37
00:01:49.06 --> 00:01:53.00
because like I said, MD5 is
broken, but also it's going

38
00:01:53.00 --> 00:01:56.01
to make you a little bit
embarrassed when you name

39
00:01:56.01 --> 00:01:58.06
kinda gets dragged through
the mud there because of the

40
00:01:58.06 --> 00:02:03.00
password hashing algorithm you're using.

41
00:02:03.00 --> 00:02:08.06
And finally, never ever ever
ever ever store your passwords

42
00:02:08.06 --> 00:02:10.01
in plain text.

43
00:02:10.01 --> 00:02:12.09
I can't say that enough times.

44
00:02:12.09 --> 00:02:16.09
You should never ever keep
a password in plain text,

45
00:02:16.09 --> 00:02:21.05
period, end of story, never
in logs, never in databases,

46
00:02:21.05 --> 00:02:25.02
no where; that's actually
worse than encrypted passwords

47
00:02:25.02 --> 00:02:27.04
and those are pretty
bad on their own right.

48
00:02:27.04 --> 00:02:31.06
So do not store passwords in plain text.

49
00:02:31.06 --> 00:02:33.01
Now let's talk about what makes a

50
00:02:33.01 --> 00:02:35.08
good password hashing algorithm.

51
00:02:35.08 --> 00:02:38.08
First and foremost, it is not cracked.

52
00:02:38.08 --> 00:02:41.02
There is no indication
that the password algorithm

53
00:02:41.02 --> 00:02:45.08
you are using has been
cracked or has the possibility

54
00:02:45.08 --> 00:02:49.05
of being cracked, based
on theoretical knowledge.

55
00:02:49.05 --> 00:02:53.03
For instance, SHA1 is considered cracked.

56
00:02:53.03 --> 00:02:58.01
SHA2 theoretically is
not considered cracked.

57
00:02:58.01 --> 00:03:01.01
However, it suffers a different flaw

58
00:03:01.01 --> 00:03:04.05
and that is it susceptible to brute force

59
00:03:04.05 --> 00:03:07.09
and that goes hand in hand
with its inherent slowness.

60
00:03:07.09 --> 00:03:10.09
A hash algorithm, although
it is easy to compute,

61
00:03:10.09 --> 00:03:14.05
does not necessarily have to be fast.

62
00:03:14.05 --> 00:03:18.03
Some hash algorithms has built in slowness

63
00:03:18.03 --> 00:03:22.01
designed into the algorithm
and something that we want.

64
00:03:22.01 --> 00:03:25.09
If it takes your user one
second to authenticate

65
00:03:25.09 --> 00:03:29.01
to your system, they're going to be fine.

66
00:03:29.01 --> 00:03:33.01
If it takes one second
between hash attempts,

67
00:03:33.01 --> 00:03:37.00
you are going to dramatically
slow down a brute force attack

68
00:03:37.00 --> 00:03:40.03
and that actually is a
good thing because if I can

69
00:03:40.03 --> 00:03:44.04
cycle through one hash a
second, versus thousands

70
00:03:44.04 --> 00:03:47.05
of hashes a second,
you can guess which one

71
00:03:47.05 --> 00:03:49.08
I've got a better chance of attacking

72
00:03:49.08 --> 00:03:53.06
and that's where SHA256
has one of it's flaws

73
00:03:53.06 --> 00:03:57.06
because I can script so
many brute force attacks

74
00:03:57.06 --> 00:04:02.08
against the system because
there is no inherent slowness.

75
00:04:02.08 --> 00:04:06.05
So, as I've alluded to,
MD5 and SHA1 should both

76
00:04:06.05 --> 00:04:10.02
be considered cracked;
they're also very fast,

77
00:04:10.02 --> 00:04:12.08
which makes them bad
choices in both rights.

78
00:04:12.08 --> 00:04:18.04
SHA2 is fast, therefore, not good.

79
00:04:18.04 --> 00:04:21.04
SHA3 has not officially been standardized

80
00:04:21.04 --> 00:04:24.05
and it's also a fast hash algorithm,

81
00:04:24.05 --> 00:04:26.09
again not good for passwords,

82
00:04:26.09 --> 00:04:30.06
but good for other cryptographic needs.

83
00:04:30.06 --> 00:04:33.08
So where does that leave us
in the realm of possibilities?

84
00:04:33.08 --> 00:04:37.02
The first is PBKDF2.

85
00:04:37.02 --> 00:04:40.08
This is a valid algorithm
but it's not that popular

86
00:04:40.08 --> 00:04:43.03
in mainstream worlds today.

87
00:04:43.03 --> 00:04:45.04
The most popular and
the one that we're going

88
00:04:45.04 --> 00:04:48.04
to talk about is BCrypt.

89
00:04:48.04 --> 00:04:51.01
There's also a hash algorithm call SCrypt

90
00:04:51.01 --> 00:04:53.01
that is similar in its
own rights to BCrypt

91
00:04:53.01 --> 00:04:55.01
but it is inherently different

92
00:04:55.01 --> 00:04:57.05
in the way that it operates.

93
00:04:57.05 --> 00:05:01.03
We're not going to talk
about PBKDF2 or SCrypt,

94
00:05:01.03 --> 00:05:03.02
but we are going to focus on BCrypt

95
00:05:03.02 --> 00:05:06.03
and I highly encourage
you to learn to use this

96
00:05:06.03 --> 00:05:08.09
whenever you need to hash a password

97
00:05:08.09 --> 00:05:11.01
for one of your customers.

98
00:05:11.01 --> 00:05:15.03
I want to talk briefly about
the concept of entrophy.

99
00:05:15.03 --> 00:05:19.04
Now think about your
password generation strategy.

100
00:05:19.04 --> 00:05:22.01
Often we have some sort
of replacement scheme

101
00:05:22.01 --> 00:05:25.07
where we replace letters
with numbers or symbols

102
00:05:25.07 --> 00:05:29.08
and we add some numbers
because of relatively complex

103
00:05:29.08 --> 00:05:34.04
password algorithms that
many sites force upon us.

104
00:05:34.04 --> 00:05:38.01
Unfortunately, humans
struggle with random passwords

105
00:05:38.01 --> 00:05:42.03
and as such, those
patterns tend to take hold.

106
00:05:42.03 --> 00:05:46.01
For instance, people with
randomized birthday strings

107
00:05:46.01 --> 00:05:49.07
become a very common
password that they use.

108
00:05:49.07 --> 00:05:52.02
Now sure they do
replacements and upper cases

109
00:05:52.02 --> 00:05:54.08
and lower cases but you
will find that they use

110
00:05:54.08 --> 00:05:59.03
very similar patterns every
time they create a password.

111
00:05:59.03 --> 00:06:02.08
Real password complexity doesn't come from

112
00:06:02.08 --> 00:06:06.00
making us do upper case
and lower case and numbers,

113
00:06:06.00 --> 00:06:09.08
it comes from length and specifically,

114
00:06:09.08 --> 00:06:12.09
it comes from entrophy and entrophy

115
00:06:12.09 --> 00:06:18.00
is more impacted by length
than by character sets.

116
00:06:18.00 --> 00:06:22.04
Now longer phrases of real
words are actually easier

117
00:06:22.04 --> 00:06:26.06
for humans to remember, but they're harder

118
00:06:26.06 --> 00:06:31.06
for computers to brute force
because of the entrophy.

119
00:06:31.06 --> 00:06:35.05
So instead of forcing your
customers and your clients

120
00:06:35.05 --> 00:06:38.06
to use patterns that
don't make sense to them

121
00:06:38.06 --> 00:06:41.02
and are easy for systems to crack,

122
00:06:41.02 --> 00:06:45.04
consider allowing them to
have very long common phrases

123
00:06:45.04 --> 00:06:48.07
of words that make no
sense together but to them,

124
00:06:48.07 --> 00:06:50.07
are very easy to remember.

