1
00:00:01,690 --> 00:00:07,430
Hello, and welcome to Cracking Beyond 15 Characters for under $500.

2
00:00:07,750 --> 00:00:16,110
Some alternative titles for this talk were Greener Pastures Over the Computational Wall or Why XKCD Advice is Easy to Understand and Hard to Do.

3
00:00:16,210 --> 00:00:20,570
That last one was suggested by my management, and we'll talk more about that one later.

4
00:00:21,510 --> 00:00:23,010
Hi, I'm Travis Palmer.

5
00:00:23,010 --> 00:00:25,330
I'm also a nerd, so I go by the pseudonym tramco.

6
00:00:25,330 --> 00:00:29,390
I am an OSCP, OSCE, and GMOD, if those letters mean something to you.

7
00:00:29,390 --> 00:00:34,590
And as is traditional for speakers, a couple of my favorite hobbies outside of security are on the right.

8
00:00:34,810 --> 00:00:36,290
D&D, Arma 3, and BBC.

9
00:00:36,770 --> 00:00:38,430
Yes, again, I am a nerd.

10
00:00:38,670 --> 00:00:47,890
And these slides arguably have too much on them, so this is the point where I ditch my ugly mug so that we can happily reveal that picture from the Red Team Village last year.

11
00:00:48,290 --> 00:00:52,170
Yeah, let's just say that room was pretty tight.

12
00:00:52,170 --> 00:00:54,530
I'm glad we're not trying to do that again this year.

13
00:00:55,150 --> 00:00:58,350
Everybody would have COVID by now if we were trying to be doing this live.

14
00:00:59,530 --> 00:01:05,450
For this talk, we're going to start with a fair bit of background before we get into the meat of things.

15
00:01:05,450 --> 00:01:07,010
I should give a disclaimer.

16
00:01:07,190 --> 00:01:09,410
This isn't going to be an all-inclusive introductory talk.

17
00:01:09,410 --> 00:01:11,630
There is just too much to get through.

18
00:01:11,790 --> 00:01:15,670
And if you've never heard of HashGap before and are thinking, where can I adopt one?

19
00:01:15,690 --> 00:01:17,830
This talk is going to be a little rough to follow.

20
00:01:18,010 --> 00:01:19,030
Just stick around.

21
00:01:19,030 --> 00:01:22,750
You'll still learn something, and you'll definitely have some keywords to Google later.

22
00:01:22,750 --> 00:01:26,130
So, let's address what should always be the first question.

23
00:01:26,450 --> 00:01:27,210
Why?

24
00:01:27,510 --> 00:01:39,810
Well, large web corporations are still using character requirements that were determined in 1985 by the Department of Defense to be resistant only resistant to online brute force attacks over a 1,200-baud modem.

25
00:01:39,810 --> 00:01:43,670
And even then, they should have been rotated every couple months.

26
00:01:44,190 --> 00:01:59,250
They also have complexity requirements that should seem familiar because they have become pervasive and are largely responsive for a lot of people honestly believing that they can take almost any English word and add a number and an exclamation point to it.

27
00:01:59,350 --> 00:02:01,450
And it makes it an acceptable password.

28
00:02:01,450 --> 00:02:09,390
Spoiler, these policies in isolation have not magically become more secure since 1985 and are still guarding some very sensitive things.

29
00:02:09,850 --> 00:02:16,970
Thankfully, most of these websites and companies have some additional safety nets, like detecting questionable login origins or 2FA.

30
00:02:17,510 --> 00:02:20,730
Well, except Wikipedia, which, well, doesn't.

31
00:02:20,790 --> 00:02:24,910
And historically might have had one of the worst password policies on the internet.

32
00:02:24,910 --> 00:02:28,110
Thank you, Troy Hunt, for using a megaphone to broadcast the history here, which...

33
00:02:29,130 --> 00:02:31,090
I just... why?

34
00:02:31,470 --> 00:02:35,450
Your fix for zero-character passwords was a one-character requirement?

35
00:02:35,810 --> 00:02:43,170
There's also a large number of places where that eight-character standard, well, isn't, which frankly is a little baffling given some of the sensitivity here.

36
00:02:43,170 --> 00:02:51,130
PCI, the payment card industry, which only covers the systems where the payment card info is stored, this just seems lackluster.

37
00:02:51,310 --> 00:02:56,790
And on the other side of things, imagine what kind of information someone could collect for getting into your Facebook or Pornhub account.

38
00:02:56,790 --> 00:02:59,430
Imagine what they could do to your reputation by controlling it.

39
00:02:59,750 --> 00:03:06,150
And then there's eBay, which I should need to explain the level of financial ruin an auction site can bring if somebody else is bidding for you.

40
00:03:06,210 --> 00:03:10,550
Wells Fargo, a deserving punchbag perhaps, but they just haven't wisened up.

41
00:03:10,550 --> 00:03:12,370
That's a 14-character limit.

42
00:03:12,990 --> 00:03:18,370
And is there seriously a database with plain-text referentials limited to 14 characters in the background somewhere?

43
00:03:19,770 --> 00:03:21,010
Then there's Netflix.

44
00:03:21,870 --> 00:03:26,350
Does it make sense why hijacked Netflix accounts are so commonplace?

45
00:03:26,350 --> 00:03:30,410
I understand the want to make four-number pins usable, but really?

46
00:03:30,750 --> 00:03:45,130
Finally, we have a whole suite of devices in tech, and I'll pick on Cisco because I love them so much, that historically, by default, have no password, and the policy might get set by the people installing it, but, you know, eight characters suggest it.

47
00:03:45,310 --> 00:03:53,610
This seems like a deeply questionable recommendation when, again, those passwords were determined to only be resistant to attacks on networks in 1985.

48
00:03:54,090 --> 00:04:03,750
And while I'm on the trend of bashing trustworthy sources, it's only proper that I talk about NIST, or the National Institute of Science and Technology, and what they say, given that what they say often seeps into government regulation.

49
00:04:03,750 --> 00:04:19,030
The special publication 800-63B, released in 2017, said that the requirement should actually be 8-plus characters with no complexity, because someone did the statistical analysis and found out that people actually produce easier-to-reinforce passwords under complexity requirements.

50
00:04:19,030 --> 00:04:22,070
Like, adding a number and an exclamation point.

51
00:04:22,170 --> 00:04:26,530
They also say the maximum should at least be 64 characters.

52
00:04:26,690 --> 00:04:27,330
Hmm.

53
00:04:27,330 --> 00:04:29,310
I anted where things might be going.

54
00:04:29,310 --> 00:04:35,910
There's also a key section here that says increased password length is a key security control and to encourage passphrases.

55
00:04:36,270 --> 00:04:36,650
Hmm.

56
00:04:36,650 --> 00:04:37,490
You hear that?

57
00:04:37,490 --> 00:04:38,710
The future is coming.

58
00:04:38,850 --> 00:04:39,670
Slowly.

59
00:04:39,670 --> 00:04:42,150
And the 80s might finally end soon.

60
00:04:42,550 --> 00:04:50,450
The most recent guidance on February this year, mind you, this was not the first time it was published, from NIST and the FBI, is that, well, a lot more explict.

61
00:04:50,450 --> 00:04:54,350
15 characters without other complexity requirements is where we should be going.

62
00:04:54,350 --> 00:04:56,830
In fact, we should require it as soon as possible.

63
00:04:57,470 --> 00:05:04,930
And this is in line with what a bunch of other experts and sources that aren't the largest tech companies have been saying for much, much longer.

64
00:05:05,290 --> 00:05:15,070
In fact, a security consulting group that I greatly respect, Black Hills Information Security, makes this suggestion to their clients and uses a more paranoid standard of 20 characters internally.

65
00:05:15,270 --> 00:05:15,970
Neat.

66
00:05:16,170 --> 00:05:19,550
Though you might be asking, okay, why is Black Hills specifically on here?

67
00:05:19,550 --> 00:05:24,310
Well, it's because I'm picking on them and we're about to listen to some snippets of audio from a webcast last December.

68
00:05:24,310 --> 00:05:28,690
Mind you, this is a little cut up and out of context, but don't worry, most of the context is still there.

69
00:05:29,270 --> 00:05:32,910
7 characters is just easy to crack.

70
00:05:32,910 --> 00:05:33,910
How easy?

71
00:05:34,650 --> 00:05:38,950
If you go to the next slide, my son's computer, he's got a gaming computer.

72
00:05:38,950 --> 00:05:41,690
It takes 8 minutes to crack an LM hash.

73
00:05:42,130 --> 00:05:46,790
If you take the same 14 character password, it would take 4.3 billion years.

74
00:05:47,050 --> 00:05:48,430
Well, we got time.

75
00:05:48,710 --> 00:05:55,230
This is kind of what I'm talking about with regards to the password policy that they set in 1985.

76
00:05:55,230 --> 00:06:01,650
I mean, in 1985, an 8 character password policy was secure forever.

77
00:06:03,230 --> 00:06:04,410
90 days.

78
00:06:04,410 --> 00:06:05,870
90 days, okay.

79
00:06:05,870 --> 00:06:09,230
So it was secure for long enough for them to...

80
00:06:10,910 --> 00:06:12,990
we don't need to do anything.

81
00:06:13,730 --> 00:06:19,610
But, I mean, as technology changes, so do the password policies need to.

82
00:06:19,650 --> 00:06:21,850
Hey, this is warfare, right?

83
00:06:21,850 --> 00:06:24,090
Everything is move, counter, move.

84
00:06:24,090 --> 00:06:26,210
We have electronic countermeasures.

85
00:06:26,210 --> 00:06:28,530
You have electronic counter-countermeasures.

86
00:06:28,710 --> 00:06:31,610
And then it goes up above that and I lose track.

87
00:06:31,610 --> 00:06:39,530
So we're getting questions about have you run the Google common word attack against passphrases?

88
00:06:39,530 --> 00:06:46,030
So, like, if you just load words into a cracker, then doesn't that crack passphrases?

89
00:06:46,030 --> 00:06:46,790
Sure.

90
00:06:46,790 --> 00:06:48,130
Yes, it does.

91
00:06:48,290 --> 00:06:52,310
How many combinations of four-word passwords are there?

92
00:06:54,410 --> 00:06:56,490
So how long is that going to take you?

93
00:06:56,490 --> 00:06:59,490
What if you start using words from a foreign dictionary?

94
00:06:59,810 --> 00:07:02,510
What if you start putting salt into those words?

95
00:07:02,510 --> 00:07:14,370
Like, but I just, I think if four words, and if you start using special characters as a spacer between your words and things like this, the question is, are you more secure than you were with eight?

96
00:07:15,610 --> 00:07:18,250
But, yes, there are attacks against everything.

97
00:07:21,110 --> 00:07:26,950
So, Darren kind of summarized this up, this from-the-field kind of our results, but I just did want to talk about it.

98
00:07:26,950 --> 00:07:30,070
We have no success with people who have 15-character passwords.

99
00:07:30,170 --> 00:07:31,630
Approach is zero.

100
00:07:31,930 --> 00:07:33,130
And we have tried these things.

101
00:07:33,130 --> 00:07:35,250
Now, we're constrained in our time.

102
00:07:35,250 --> 00:07:44,290
Normally, we don't have more than a week or so to do our password guessing, whereas ATT&CK, according to a Verizon report, they've got, like, what, nine months, something like that?

103
00:07:44,890 --> 00:07:46,530
Okay, another question, Jason.

104
00:07:46,530 --> 00:07:49,530
Yes, so this question's come up a few times.

105
00:07:49,530 --> 00:07:51,450
Are spaces legal?

106
00:07:51,670 --> 00:07:55,790
Yes, they are a special character, and they are very good.

107
00:07:56,070 --> 00:07:57,910
And it depends on the...

108
00:07:58,910 --> 00:08:00,650
And I'm going to cut it there.

109
00:08:00,730 --> 00:08:13,830
So, they have some pretty solid reasons, a couple of pointed recommendations, but perhaps the most interesting thing mentioned is that they have been given hashes from a domain with a 15-character passphrase policy specifically to crack them.

110
00:08:13,830 --> 00:08:17,050
And the amount they can crack in a week approaches zero.

111
00:08:17,050 --> 00:08:18,630
Basically, no success.

112
00:08:19,130 --> 00:08:22,330
There's also that mention of spaces are a special character.

113
00:08:22,430 --> 00:08:24,650
We'll get back around to that one.

114
00:08:25,370 --> 00:08:27,370
They are a character, certainly.

115
00:08:27,930 --> 00:08:30,930
Any case, approaching zero success.

116
00:08:31,290 --> 00:08:32,410
Pack it in.

117
00:08:32,490 --> 00:08:33,550
Presentation over.

118
00:08:34,190 --> 00:08:35,690
That's all, folks.

119
00:08:37,610 --> 00:08:38,490
No?

120
00:08:38,490 --> 00:08:39,810
You're not buying that?

121
00:08:39,810 --> 00:08:48,290
Well, good, because neither am I, and I should address the final reason I'm here presenting on this topic in particular, which is the CISO of my company.

122
00:08:49,410 --> 00:08:55,210
So, getting on the password policy, so, taking that innovative kind of incubator mindset and looking at passwords.

123
00:08:55,310 --> 00:09:00,370
So, passwords are something that's highly audited, because it's very easy to do.

124
00:09:00,370 --> 00:09:06,830
If you're an auditor and you're trying to assess whether somebody's passing muster, you can have this rule set, and you can walk in and either they pass or they fail.

125
00:09:07,110 --> 00:09:11,470
And you'll see a lot of that, and a lot of the companies have this password policy that comes straight out of audits.

126
00:09:11,470 --> 00:09:15,230
Eight characters and three or four of uppercase, lowercase, special characters and numbers.

127
00:09:15,230 --> 00:09:16,110
There, I just rattled it off.

128
00:09:16,110 --> 00:09:17,870
It's been almost 20 years of that.

129
00:09:19,090 --> 00:09:33,210
So, we looked at that, though, and as we went through the red teaming, we found that one step in what we call the kill chain, if an attacker were successful, and we actually give them a leg up, we actually bring hackers on and bring them in as fake employees.

130
00:09:33,210 --> 00:09:35,670
We give them a laptop and a password and they start.

131
00:09:35,890 --> 00:09:40,070
And we found one step in the kill chain was taking all the passwords and cracking them.

132
00:09:40,070 --> 00:09:52,010
And they would run computers with graphic processing unit, augmentation, and they'd run for hours, and they'd be able to crack a few passwords and hopefully they'd find a privileged account, and then they were off to the races with that.

133
00:09:52,070 --> 00:09:57,150
So, while that was only one step in what I call the kill chain, we just said, you know, we want to win that battle.

134
00:09:57,150 --> 00:10:00,830
And here we are compliant, but it's just not getting it done.

135
00:10:00,830 --> 00:10:02,430
I'm just meeting compliance.

136
00:10:02,870 --> 00:10:10,070
So, we ran some math on the whiteboard and we said, well, what if we went out to a really long password, 15 characters, but got rid of all the complexity requirements?

137
00:10:10,710 --> 00:10:16,010
And, you know, I have a lot of people with high math SAT scores on my team.

138
00:10:16,010 --> 00:10:17,130
Let's put it that way.

139
00:10:17,510 --> 00:10:21,250
So, we had some great whiteboard battles and, you know, how much better would it be and that sort of thing.

140
00:10:22,390 --> 00:10:27,770
But what kept creeping in there because of kind of that tick box mentality was, well, we have to have complexity.

141
00:10:27,830 --> 00:10:28,690
Everybody's expecting that.

142
00:10:28,690 --> 00:10:30,810
We have to have uppercase and lowercase and on and on.

143
00:10:30,810 --> 00:10:32,430
But we said, well, let's just try it out.

144
00:10:32,950 --> 00:10:35,570
So, the math held and we felt pretty good about it.

145
00:10:35,570 --> 00:10:41,310
And then around that time, the National Institute of Standards and Technology, NIST, released an updated standard.

146
00:10:41,310 --> 00:10:42,870
And they said, well, length is king.

147
00:10:42,870 --> 00:10:49,030
And if you can get a longer password, you can get rid of some of that stuff as long as you look for commonly used passwords and block them out.

148
00:10:49,310 --> 00:10:51,230
So, long story short, we did it.

149
00:10:51,230 --> 00:10:53,730
And it took about 90 days to roll it in.

150
00:10:54,090 --> 00:10:56,990
And the impact has been substantial.

151
00:10:57,070 --> 00:11:06,010
And the only reason we were able to do that is because we innovated and created this thing that we called the Kraken that every single day tries to crack all the passwords in the company.

152
00:11:06,130 --> 00:11:09,930
And we see the success rate of that machine just dropping precipitously.

153
00:11:09,930 --> 00:11:10,790
We saw it.

154
00:11:11,050 --> 00:11:12,530
And I'm going to cut it there.

155
00:11:13,070 --> 00:11:16,970
So, yeah, that's out in the public domain.

156
00:11:18,290 --> 00:11:22,750
And we need to talk about that math Jerry mentioned.

157
00:11:23,270 --> 00:11:28,490
See, the math might hold up, but the equation isn't realistic.

158
00:11:28,490 --> 00:11:30,530
There's more than one way of approaching this problem.

159
00:11:30,530 --> 00:11:32,850
And I've heard the arguments spun multiple different ways.

160
00:11:32,850 --> 00:11:42,590
The first of which is it's inconceivable to crack a 15-character password because brute-forcing through all the possible numbers and lowercase letters is 1.6 sextillion combinations.

161
00:11:42,930 --> 00:11:49,050
Another argument I have heard that comes from a better standpoint is assuming the passphrase is made up of words.

162
00:11:49,050 --> 00:11:56,850
There are a lot of words around five characters or more, so you can say a 15-character passphrase is probably three words, which is extremely difficult.

163
00:11:56,870 --> 00:11:59,770
You'd have to go through more than 50 quadrillion options to be sure.

164
00:11:59,770 --> 00:12:02,670
Okay, big number, but certainly smaller than the last one.

165
00:12:03,050 --> 00:12:16,530
And the last one I've heard, perhaps the most educated of these strawman arguments, is based on the common requirement of eight characters doubling that gets you just above the 15-character requirement, so maybe we should think about passphrases as just multiple passwords combined.

166
00:12:16,530 --> 00:12:26,170
In which case, the lowest margin for cracking all of the combinations of two passphrases is just the combinations of two common passwords combined.

167
00:12:26,170 --> 00:12:32,530
Which, if we're using the RACU dictionary, is still over 205 trillion, which they'll tell you is unreasonable.

168
00:12:32,850 --> 00:12:42,330
Well, I'm here to tell you that all of these arguments that say that cracking past 15 characters, regardless of reasoning, can be undermined, and they can be undermined with only three factors.

169
00:12:42,470 --> 00:12:43,890
What are those factors, you might ask?

170
00:12:43,890 --> 00:12:45,230
Are you just teasing us?

171
00:12:45,230 --> 00:12:47,390
Is this a timeshare scheme in disguise?

172
00:12:47,510 --> 00:12:51,150
No, the big secret weakness is humans.

173
00:12:51,810 --> 00:12:52,690
Inconceivable!

174
00:12:53,090 --> 00:12:53,870
I know.

175
00:12:55,010 --> 00:13:03,190
Specifically, humans are bad at big numbers, humans pack complexity on the ends, the ends of passwords or passphrases, and humans pick similar things.

176
00:13:03,190 --> 00:13:06,890
Similar things to other humans, common things are common because they're commonly picked.

177
00:13:07,350 --> 00:13:15,550
Before I get too far, we should define some limits on what is reasonable, and I should address the other part of the clickbaity title of this talk.

178
00:13:15,550 --> 00:13:17,070
Why the $500 limit?

179
00:13:17,310 --> 00:13:29,550
Well, besides it being a nice round number that is easy to pitch, it's also the roundabout cost of an entertainment system, and you can safely assume that every type of threat actor you might need to be worried about, including LulzSec and the Script Kitties,

180
00:13:29,550 --> 00:13:31,170
has access to this amount of money.

181
00:13:31,170 --> 00:13:37,570
It's also an amount that can pack a sizable punch regardless of the path you take, either owning a cracking rig or renting out cloud computing.

182
00:13:37,570 --> 00:13:50,750
$500 is more than enough to go off and build a small cracking system out of a GPU from eBay and some outdated desktop parts, which you might have found in a dumpster, which should net you the theoretical max of 53 gigahashes against NTLM.

183
00:13:50,870 --> 00:13:59,450
As for the cloud, in AWS, $500 will get you 68 hours on a spot instance, which, yes, might get preempted.

184
00:13:59,650 --> 00:14:00,630
Probably won't, though.

185
00:14:00,630 --> 00:14:10,010
With eight V100 GPUs, which you can do manually, or you can use a management tool like CoalFire's NPK to manage the spot instances for you, for both scale and automation of the attack.

186
00:14:10,190 --> 00:14:19,690
If you're an attacker, and what you're planning on doing is a series of short-running attacks, instead of waiting 68 hours to get all the results, why not just spend 68 instances and get the results in one hour?

187
00:14:20,110 --> 00:14:30,930
Sadly, NPK doesn't work with Google Cloud, which actually appears to be cheaper, and if you squeeze out everything you can, you can get 83 hours of time on an instance with eight V100 GPUs.

188
00:14:30,930 --> 00:14:40,390
Which, besides being terrifically cheap, brings us to a terrifying theoretical max of 189.3 petahashes of NTLM, we can guess.

189
00:14:40,390 --> 00:14:42,850
Not mega, not giga, not tera.

190
00:14:43,110 --> 00:14:43,970
Peta.

191
00:14:44,370 --> 00:14:45,990
189 quadrillion.

192
00:14:45,990 --> 00:14:56,850
If we compare that to that last strawman argument of the ROCU dictionary on top of itself, sure, theoretical isn't real performance, but the difference isn't off by a factor of a thousand times.

193
00:14:57,150 --> 00:14:59,090
Although humans aren't bad with big numbers.

194
00:14:59,370 --> 00:15:02,730
Which brings us around to the second strawman argument.

195
00:15:02,990 --> 00:15:08,970
I'd like to throw in an alternative equation that is still very conservative for how many guesses it takes to crack a three-word passphrase.

196
00:15:09,170 --> 00:15:20,370
All of the words that are obsolete to the third power divided by the number of people in the organization or number of hashes an attacker has to crack, all of which is divided by the factor of human laziness squared.

197
00:15:20,370 --> 00:15:22,930
How do you quantify human laziness, you might ask?

198
00:15:22,930 --> 00:15:27,770
Don't ask me, but trust me, the value of that variable always seems to be greater than one.

199
00:15:28,050 --> 00:15:41,690
This is a somewhat joking equation, but the very conservative hypothesis here is that people making a passphrase will use words from languages they know and can think of under the duress of password creation, which tends to be a much more limited set.

200
00:15:41,690 --> 00:15:47,770
In fact, I'm going to say now and support later that the pool to pick from for a lot of people seems to be between 32,000 and 64,000 words.

201
00:15:48,050 --> 00:15:51,890
Which brings me to a point where we are going to need to break out a lot of math.

202
00:15:51,950 --> 00:15:55,490
Because underminer number one, people are bad at big numbers.

203
00:15:55,690 --> 00:15:59,130
Thankfully, people are good at spotting trends after they have all the information.

204
00:15:59,410 --> 00:16:02,870
So let me give you something that is easier to parse, or hopefully easier to parse.

205
00:16:02,870 --> 00:16:13,990
This is a chart of the actual computational limits of combining words together in an attack on a single 2080 Ti on NTLM hashes, which I picked because it's a consumer GPU and I have access to one.

206
00:16:13,990 --> 00:16:17,690
The horizontal axis of this chart is the number of words in a passphrase.

207
00:16:17,690 --> 00:16:23,670
The vertical axis is the size of the dictionary, or perhaps a more useful way to think about it, the rarest word in a passphrase that can be cracked.

208
00:16:23,770 --> 00:16:26,870
Because a logical attacker is going to use the list of words by frequency.

209
00:16:26,870 --> 00:16:30,110
The bigger that list is, the rarer the words are going to be that are in it.

210
00:16:32,510 --> 00:16:40,170
Now, all the numbers in the colored boxes are the amount of minutes required to complete an attack search space.

211
00:16:40,170 --> 00:16:44,690
And the coloration tells you how long a time that is relative to minutes, hours, days, weeks, months, or years.

212
00:16:44,790 --> 00:16:48,250
Because I'm not going to lie, I don't know off the top of my head how many minutes are in a week.

213
00:16:48,590 --> 00:16:52,830
Going down or to the right exponentially increases the amount of work needed.

214
00:16:54,330 --> 00:17:00,250
And there's a lot of spots here where the jumps in difficulty are sharp.

215
00:17:00,250 --> 00:17:03,130
And this is where the idea of a computational wall comes in.

216
00:17:03,130 --> 00:17:06,270
A seemingly sudden increase in difficulty that you can't go over.

217
00:17:06,510 --> 00:17:10,090
But of course, this is only on the chart for a consumer GPU.

218
00:17:10,250 --> 00:17:11,530
What about a V100?

219
00:17:12,270 --> 00:17:14,630
Well , it's not actually that much different.

220
00:17:15,610 --> 00:17:21,490
There are a lot of reasons why V100 should be much better for cracking generally, but it isn't a variable for this particular chart.

221
00:17:21,490 --> 00:17:23,410
Anyway, what if we have more than one GPU?

222
00:17:23,410 --> 00:17:24,370
Why not eight?

223
00:17:24,630 --> 00:17:28,170
Well, the chart is going to shift down a little bit and open up some options.

224
00:17:28,170 --> 00:17:37,270
Those of you that have noticed the size of the numbers we're dealing with on the vertical axis probably already have some nightmares to take home, but I'm going to make sure everyone else has them too.

225
00:17:37,330 --> 00:17:41,590
In the two-word column, that is more than 16 million words in 20 minutes.

226
00:17:41,590 --> 00:17:51,170
Basically, every word actually in use from every language spoken by at least 1% of the world's population fits in here with room to spare for a couple extra million common passwords.

227
00:17:51,650 --> 00:17:58,830
In the three-word column, that is every non-obsolete word in the English language and it's testable in a matter of hours.

228
00:17:58,990 --> 00:18:06,750
In the four-word column , we have a sizable chunk of commonly used words where a target attack, say from scraping the memos and websites of the target makes sense.

229
00:18:07,630 --> 00:18:12,290
Before I get too excited, I'm sure someone is thinking, okay, cool, that's just NTLM.

230
00:18:12,290 --> 00:18:16,190
What about a slower actually secure hash or quote-unquote secure hash?

231
00:18:16,190 --> 00:18:23,750
Well, here's that same chart for shop512unitspassphrases and you'll notice there are still some viable attacks on two- and three-word passphrases.

232
00:18:23,790 --> 00:18:29,630
And here's bcrypt or blowfish configured with the Unix defaults, albeit this is some pretty weak Unix defaults.

233
00:18:29,630 --> 00:18:32,550
I think Ubuntu has gone well past this now.

234
00:18:32,550 --> 00:18:45,210
In any case, we lose a lot of capability, but even when that difficulty curve is ramped way the heck up, we still have options in the two-word passphrase category.

235
00:18:45,210 --> 00:18:59,830
As an attacker, this chart makes me really sad, but the reality of most corporations using Windows somewhere in infrastructure is that there will be somewhere something using a hash that, like NTLM, isn't going away for quite a while to come.

236
00:19:00,190 --> 00:19:14,910
And as far as individual users that are concerned with what they need to have as a passphrase, well, they need to make sure what they have isn't going to get cracked when the hashes get dumped, either inside an institution or when a website gets all of its password dumped by SQL injection.

237
00:19:14,910 --> 00:19:22,990
And let's be real, a lot of major websites and companies keep on getting caught with their pants down, and we only find out they're using a fast hash or plaintext the hard way.

238
00:19:23,730 --> 00:19:29,650
Not to mention the difficulty of computing a hash is a linear factor in a world where computing power increases exponentially.

239
00:19:29,730 --> 00:19:35,630
So I'm going to go back to the other chart, because it's time to get into the attacker mindset and play a game of bad recommendations.

240
00:19:35,990 --> 00:19:43,890
First up is Google, and yes, the advice is old, but the advice, much like their policy, hasn't been updated in more than a decade.

241
00:19:43,890 --> 00:19:45,830
So, I love sandwiches.

242
00:19:45,850 --> 00:19:50,410
It's not a great example, and that mix of leet-speak and case-shifting doesn't do much for the difficulty.

243
00:19:50,410 --> 00:19:53,230
I'll be generous and say that it makes it about 100 times harder.

244
00:19:53,370 --> 00:20:05,530
In terms of the rarity, this slide shows where the various words fall on Google's own most searched list, that's the G number, and the Wikipedia frequency list, which would be the W number.

245
00:20:06,770 --> 00:20:11,130
The fact of the matter here is, the underlying phrase is crackable in under 3 minutes.

246
00:20:11,130 --> 00:20:17,350
And even giving the benefit of the doubt and the difficulty of guessing leet-speak substitutions, that's crackable in 244 minutes.

247
00:20:17,650 --> 00:20:32,550
I should probably also mention the recommendation put forth in the absolute latest NIST and FBI recommendation, because they suggested in a... they suggested the passphrase, voices protected 2020 we are, and then suggested the passphrase that is even better.

248
00:20:33,010 --> 00:20:34,130
At least according to them.

249
00:20:34,130 --> 00:20:37,630
Which is director-month-learn-truck, because the words are unrelated.

250
00:20:38,270 --> 00:20:43,370
Well, those words might seem unrelated, but they all have one thing in common, and that's they're all eye-searingly common.

251
00:20:43,390 --> 00:20:51,570
The rarest word in there is truck, and oh boy, that isn't the top 4,000, regardless of which list you choose.

252
00:20:52,130 --> 00:21:01,410
Four common words are not safe from offline cracking, which does bring up another, perhaps more viral recommendation from XKCD 936.

253
00:21:02,310 --> 00:21:10,090
Now, a lot of people have used this as password advice, including the management intercontinental exchange.

254
00:21:10,090 --> 00:21:20,330
And the matter of it is, the math in XKCD's advice as written is actually fine, because it was written to handle an online attack where the rate of guessing is only 1,000 a second.

255
00:21:20,450 --> 00:21:29,970
Now, there's a claim here that the average user shouldn't have to worry about attempts to crack a stolen hash, and I'm here to tell you from experience the average user reuses passwords.

256
00:21:30,030 --> 00:21:41,610
The average user also works at a company, and if that company is larger than a couple dozen people, they should also worry about stolen or dumped hashes, both from their own infrastructure and the websites their users are using both professionally and personally.

257
00:21:41,970 --> 00:21:44,110
Four common words isn't safe from offline attacks.

258
00:21:44,110 --> 00:21:49,370
If anything, XKCD the example here is a little stronger than intended because staple isn't actually that common.

259
00:21:49,370 --> 00:21:55,670
It's number 11,363 on the Wikipedia frequency list and completely off the end of the Google list.

260
00:21:56,110 --> 00:21:57,610
Then there's level entropy.

261
00:21:57,610 --> 00:22:00,430
XKCD says it's a common word.

262
00:22:00,430 --> 00:22:11,610
If we say common words are words that are in the first 2048 of any given word list, and the attackers, well, they're going to win all the way out to six word phrases.

263
00:22:11,610 --> 00:22:12,470
Yes, really six.

264
00:22:12,470 --> 00:22:14,230
Like, good luck Diceware users.

265
00:22:15,490 --> 00:22:16,830
This is nasty.

266
00:22:17,850 --> 00:22:25,470
This is not how this... there is no way out of this computationally with just throwing on common words.

267
00:22:25,930 --> 00:22:27,690
Mind you, there are some caveats.

268
00:22:27,730 --> 00:22:38,730
The real world isn't as simple as an Excel sheet, so before we get into real world results and the mechanics of attacks, we should very quickly cover the things that are going to be ever present when attacking these passwords using a GPU.

269
00:22:39,750 --> 00:22:41,770
Yeah, this is going to get real technical real quick.

270
00:22:41,770 --> 00:22:44,210
First of which is the dictionaries and the size of the dictionaries.

271
00:22:44,210 --> 00:22:49,250
There's a lot of bandwidths to go around for operations within a GPU and its memory, but transferring data to the GPU?

272
00:22:49,250 --> 00:23:02,090
Well, PCI Gen 3 by 16 is only 16 gigabytes per second max theoretical, not real world, and that might seem like a lot, but when we're dealing with 16 billion theoretical bytes per second,

273
00:23:05,430 --> 00:23:15,750
modern GPUs can do 26 billion real hashes of a passphrase per second, and one of these numbers doesn't fit within the other and also is real, not theoretical.

274
00:23:16,050 --> 00:23:19,850
That PCI bandwidth is not going to match up with the hash rates.

275
00:23:19,950 --> 00:23:30,150
The other limitation to be mindful in terms of what kind of attacks are possible is the nature of CUDA or the AMD equivalent, I'm not going to get into it, cores in the GPU and what they can do.

276
00:23:30,150 --> 00:23:33,730
Compute Unified Divided Architecture, which is, well, not a lot actually.

277
00:23:33,730 --> 00:23:46,410
They were built to do lots of single instruction multiple data computations on matrices and vectors for graphics, which means lots and lots of units they can do arithmetic, ALUs, and not a lot of space or silicon devoted to controlling them.

278
00:23:46,410 --> 00:23:59,630
The nature of single instruction multiple data means groups, or in this diagram rows of ALUs, all need to be doing the same type of thing at the same time, and those instructions and a significant portion of the data needs to fit in a smaller shared cache,

279
00:23:59,630 --> 00:24:03,470
and oh right, the instructions better be simple and something it can actually do.

280
00:24:03,470 --> 00:24:09,430
If that something isn't exactly implemented in HashCat or John the Ripper, often the best bet is to find a workaround .

281
00:24:09,550 --> 00:24:14,370
Also, thank you HashCat and John the Ripper devs for making it easy to use these devices for cracking.

282
00:24:14,370 --> 00:24:17,050
Okay, let's talk about techniques and results.

283
00:24:17,050 --> 00:24:26,650
First, dictionary attacks, basically checking through a massive list of passwords in a file, with or without GPU generating some additional candidates to check, though more on rules later.

284
00:24:26,970 --> 00:24:43,990
Intercontinental exchange, we've been running a dictionary attack during the period that Jerry mentioned in that soundbite, while we rolled out the 15 character policy, and as you can see in this graph, the average length of a cracked password, the policy wasn't just successful,

285
00:24:43,990 --> 00:24:47,190
it caused some rapid jumps in length when it started to be enforced.

286
00:24:47,270 --> 00:24:51,610
And after implementation, the average length evened out despite some outlying spikes.

287
00:24:51,610 --> 00:24:53,850
But this is the less interesting half of the story.

288
00:24:53,850 --> 00:24:58,770
This is the graph of the percentage of passwords that were cracked by dictionary attacks, only dictionary attacks.

289
00:24:59,130 --> 00:25:02,550
Yes, that number in the upper left is 50%.

290
00:25:02,550 --> 00:25:08,670
Dictionary attacks are very good when you have a dictionary of passwords made of the same password policy that you're targeting.

291
00:25:08,770 --> 00:25:19,710
And yes, dictionaries also aren't very good after people change their password under a completely different and significantly changed policy and start picking things that aren't going to be in the dictionary anymore.

292
00:25:19,710 --> 00:25:31,890
In fact, if we overlay the two graphs, we see multiple downward shifts in the number of cracked passwords, even after the average of cracked passwords is above 15 characters, as further enforcement for cracking cracked passwords was rolled out.

293
00:25:31,890 --> 00:25:35,470
Until it settled down and around the 1% range.

294
00:25:35,470 --> 00:25:37,390
Mind you, it didn't approach zero.

295
00:25:37,390 --> 00:25:39,450
It held down near a certain percentage.

296
00:25:39,470 --> 00:25:43,110
There is always somebody picking and re-picking a terrible password.

297
00:25:43,150 --> 00:25:45,690
And these attacks are trimmed and don't show anything that has happened recently.

298
00:25:45,690 --> 00:25:48,810
But I assure you, straight dictionary attacks have not had much success.

299
00:25:49,750 --> 00:25:51,670
Though I was hired around this time.

300
00:25:51,670 --> 00:25:53,950
So let's talk combinator attacks.

301
00:25:54,030 --> 00:26:00,850
Attacks centered around combining different dictionaries or the same dictionary results into itself.

302
00:26:01,170 --> 00:26:03,430
Or sorry, the same dictionary onto itself.

303
00:26:03,430 --> 00:26:08,190
The attack here is pretty straightforward and we've kind of already talked about it so let's get right into the results.

304
00:26:08,470 --> 00:26:14,290
And well, here's a chart of every passphrase password longer than 15 characters ever cracked in a continental exchange.

305
00:26:14,290 --> 00:26:22,850
That was crackable with a small dictionary of words or common passwords organized to reflect the charts from the computational wall part of the presentation a little bit earlier.

306
00:26:23,150 --> 00:26:35,870
In order to do this, I had to modify an algorithm for dissecting passwords called zxubn to be able to actually properly handle common separators like spaces between passwords and a passphrase because apparently the creators of zxubn didn't think that was important to handle.

307
00:26:35,870 --> 00:26:37,130
Anyway, I digress.

308
00:26:37,710 --> 00:26:55,590
A password slide here based on how many elements, usually words, but sometimes a common password zxubn believes it is made up of and the rarity of the rarest element based on the number of guesses required, which should roughly dictate the size of the source dictionary required.

309
00:26:56,030 --> 00:27:01,870
And you can see there's a rather precipitous drop-off somewhere between 32,000 and 64,000.

310
00:27:01,870 --> 00:27:11,670
Along with some pretty significant preference for three element passphrases, which might have had something to do with certain recommendations packaged with the policy.

311
00:27:13,350 --> 00:27:16,430
Now, this is neat and all, but what about the other datasets?

312
00:27:16,430 --> 00:27:18,010
Say, not from this company.

313
00:27:18,230 --> 00:27:24,110
Well, I considered calling up various companies with 15-character policies and seeing if they were willing to give me their hashes.

314
00:27:26,530 --> 00:27:29,970
But it didn't work and it seemed pretty unlikely, so I had to artificially make one.

315
00:27:29,970 --> 00:27:42,190
So this is the result of over 37 million hashes from the have-I-been-pwned version 2 collection, where every password known to be less than 15 characters long has been stripped out, which is really only possible because over 90% of this list has already been cracked.

316
00:27:42,450 --> 00:27:53,150
Both of the attacks here are pretty shallow and short-running, in large part because I only needed to prove a point, and also the hashrate is artificially terrible when cross-checking 37 million hashes for matches.

317
00:27:53,350 --> 00:28:00,070
That being said, this is 1.14% of all the passphrases in the dataset in less than 3 minutes.

318
00:28:00,370 --> 00:28:01,630
Scared yet?

319
00:28:01,710 --> 00:28:02,750
Good!

320
00:28:02,850 --> 00:28:08,450
Because this is an example of what happens when you use a lot more candidates and checking combinations of passwords.

321
00:28:08,450 --> 00:28:15,050
If you still remember that third strawman argument, this is all of the ROKU word list on top of itself.

322
00:28:15,050 --> 00:28:21,510
Sure, it takes a day and 16 hours on some piddly GPU horrifically bogged down by 37 million hashes to crack.

323
00:28:21,750 --> 00:28:24,870
Normally in cloud infrastructure, this would take 16 minutes.

324
00:28:24,870 --> 00:28:30,110
For a single machine in AWS or Google Cloud with those 8 GPUs, it would cost single-digit dollars.

325
00:28:30,870 --> 00:28:36,030
Now that I've got the would-be crackers excited, there are some technical shortfalls with HashCat that also need to be noted.

326
00:28:36,030 --> 00:28:38,390
The combination mode only takes 2 files as input.

327
00:28:38,390 --> 00:28:51,430
You want to use this so HashCat can load as much as it can on GPU RAM ahead of time, which means if we want to check 3 or 4 element passphrases, you need intermediate dictionaries, being mindful of the exponential file size.

328
00:28:51,610 --> 00:28:56,890
And it's a similar deal for the hybrid mode, which can only take one word list and one mask file.

329
00:28:57,110 --> 00:29:02,130
You could use other programs and pipe in candidates, but you pay the piper when doing so in a fast hash.

330
00:29:02,330 --> 00:29:10,510
And the other thing HashCat isn't going to do for you is generate variants of passphrase candidates with all the spaces and capitalization that people generally use.

331
00:29:10,630 --> 00:29:15,970
From what I've seen, you're going to want title case, sentence, and all lowercase, both with and without spaces.

332
00:29:16,630 --> 00:29:19,450
No, I do not consider spaces a special character anymore.

333
00:29:19,510 --> 00:29:28,830
The easiest way to do this is with individual rules on a combinator tack, starting with a preprocessed dictionary that already has the spaces between capitalized words.

334
00:29:28,830 --> 00:29:32,210
Then you can manipulate it easily enough to get the spaces and capitalization desired.

335
00:29:32,210 --> 00:29:35,970
For HashCat, J corresponds to the left word list, K corresponds to the right list.

336
00:29:36,010 --> 00:29:39,110
Which, on the topic of rules, is another shortfall.

337
00:29:39,110 --> 00:29:41,890
You can only do one set of rules per word list in combination mode.

338
00:29:41,890 --> 00:29:53,130
Yes, sorry, if you want to check lots of different things using rules like common words in between two words, you're going to need a honking, massive, and ugly bash file, or a program to manage it for you.

339
00:29:53,130 --> 00:29:58,410
This is actually what TrustedSexHatecrack is doing behind the scenes for what they call middle or thorough combinator attacks.

340
00:29:58,410 --> 00:30:02,810
It's basically spawning off tons of HashCat command lines.

341
00:30:03,870 --> 00:30:04,570
Alright.

342
00:30:05,370 --> 00:30:13,610
Enough about conditions of combinators, let's move on to PrinceAttacks, which, despite the other name for the attack, has nothing to do with the artist formerly known as.

343
00:30:13,710 --> 00:30:21,490
Prince is a acronym for Probability Infinite Chained Elements, but it is pretty simple in purpose.

344
00:30:21,570 --> 00:30:26,850
Take the path of least resistance and find more passphrases sooner by outputting shorter linked candidates first.

345
00:30:26,890 --> 00:30:34,130
Not only is the search space smaller, but we can also expect to find more passphrases here because people tend to pick passphrases close to the minimum required effort.

346
00:30:34,350 --> 00:30:37,870
This overlap of least resistance motivations is just great for an attacker.

347
00:30:38,430 --> 00:30:39,390
How does Prince work?

348
00:30:39,390 --> 00:30:54,150
Well, it ingests a word list, sorts all the contents by links, and puts them into separate lists, and then begins producing candidates at the minimum specified length out of the lists of the various links, iterating through all possible combinations of lists until the options are exhausted,

349
00:30:54,150 --> 00:30:56,770
at which point it moves on to making longer candidates.

350
00:30:57,450 --> 00:31:04,550
Now, after that explanation of how Prince works, you might be wondering, why not just use combinators of length-cut lists?

351
00:31:04,570 --> 00:31:06,270
Aren't Prince and Hashcat separate programs?

352
00:31:06,270 --> 00:31:07,410
Won't I have to pay the piper?

353
00:31:07,410 --> 00:31:10,930
Didn't you just say that transferring all that stuff for PCIe was terrible for performance?

354
00:31:10,930 --> 00:31:20,370
Well, yes, you do have to pay the piper, and you could manage all of these attacks manually, but it gets pretty crazy to manage all the lists and combinations for 3- and 4-word elements.

355
00:31:20,370 --> 00:31:28,150
It's doable, but you really need another programmer script, and there's a solution that circumvents this, and it comes back to one of the undermining factors.

356
00:31:28,870 --> 00:31:33,390
This is the positions of dictionary elements in passphrases.

357
00:31:33,550 --> 00:31:38,190
Larger numbers here mean more passphrases contained in elements straight out of a dictionary in that position.

358
00:31:38,190 --> 00:31:44,670
And there is one heck of a disparity between the last position in a passphrase and the rest of a passphrase.

359
00:31:44,810 --> 00:31:47,290
Because humans pack complexity on the ends.

360
00:31:47,290 --> 00:31:51,810
Most of the end, sometimes in the beginning, extremely rarely in the middle.

361
00:31:52,550 --> 00:31:57,510
So, the fix for Prince's terrible hashrate on fast hashes when it's piped in?

362
00:31:57,610 --> 00:31:58,430
Rules.

363
00:31:58,450 --> 00:32:03,310
Because you can use the default hashcat cracking mode, you can specify with a rules file.

364
00:32:03,890 --> 00:32:04,530
Any problems?

365
00:32:04,530 --> 00:32:17,470
Well, yeah, most rule lists are made by people on the internet and aren't long enough to make use of a GPU's spare resources or are more focused on modifying passwords and not altering passphrases, like adding suffixes or prefixes.

366
00:32:17,690 --> 00:32:24,810
So, I've made them one more focused on common prefixes and suffixes, you know, your 20, 20, your exclamation point, etc.

367
00:32:24,850 --> 00:32:42,670
With 4,175 rules, which is up in the rephraser repo I'll mention later, and soon to come I'll also be releasing a prefix and suffix list, which probably is already up by now, based on the frequency data of those cracked password phrases mentioned earlier in the have-I-been-pwned-version-2 list.

368
00:32:43,130 --> 00:32:43,830
Okay.

369
00:32:43,830 --> 00:32:47,150
Let's talk success rates for print.

370
00:32:48,970 --> 00:32:57,130
Now, the kicker here is that we're making use of that rule list I mentioned to catch passphrases with common suffixes and prefixes.

371
00:32:57,130 --> 00:32:59,590
There are no single-element passphrases here.

372
00:32:59,590 --> 00:33:02,730
We can see a repeat of an earlier trend.

373
00:33:02,990 --> 00:33:10,410
Namely, a sudden drop-off between 32,000 and 64,000 with some clustering around three elements, including the suffix or prefix.

374
00:33:10,990 --> 00:33:13,430
You've got to remember all of these are being run with the rules.

375
00:33:14,030 --> 00:33:19,670
This works out pretty well for sussing out passphrases, at least within your continental exchange.

376
00:33:20,570 --> 00:33:22,390
What about a much larger dataset?

377
00:33:22,630 --> 00:33:27,990
Well, we can also see the reason why people like using print's attacks.

378
00:33:28,070 --> 00:33:38,670
Both of these attacks were using the RockU password dictionary as the source, and both were stopped at the same time at 1.8, the runtime of the RockU squared combinator, RockU on top of itself.

379
00:33:38,710 --> 00:33:45,250
That complete attack I mentioned earlier took one day, 16 hours on our piddly setup, and got 5.82%.

380
00:33:45,250 --> 00:33:50,450
These attacks managed to concentrate a significant portion of that success very early in cracking.

381
00:33:50,470 --> 00:33:57,250
The other comparison here is the performance between restricting the number of elements print is allowed to use in the attack.

382
00:33:57,250 --> 00:34:05,050
At least in this case, there was a limited but significant advantage to focusing only on three-word element passphrases.

383
00:34:05,270 --> 00:34:10,150
Because again, we're also using that ruleset mentioned earlier with the prefixes and suffixes, based on the print's candidates.

384
00:34:10,370 --> 00:34:14,250
I'll also say again, this was at a really abysmal hash rate.

385
00:34:14,530 --> 00:34:24,370
We barely were reaching one gigahash when doing this, and these attacks can be much, much faster when you're not drowning your GPU in 37 million hashes to check.

386
00:34:25,010 --> 00:34:28,250
And speaking of fast, it's about time I get to the new and shiny.

387
00:34:28,250 --> 00:34:33,470
Word-level markup chains for going after passwords that are at their core phrases.

388
00:34:33,930 --> 00:34:36,030
What are word-level markup chains?

389
00:34:36,030 --> 00:34:42,690
The simplest explanation I can give is it's an over-glorified state model to store relationships between groups of words.

390
00:34:42,690 --> 00:34:48,410
For this example, we'll just do a two-gram model, think two elements in the state.

391
00:34:48,410 --> 00:34:58,690
If the phrase used for training is the cows eat grass, a two-gram model will record state transitions for the cows to eat and cows eat to grass.

392
00:34:58,690 --> 00:35:07,790
Obviously, this isn't a terribly useful model by itself, but imagine if it had some more training data, say, hundreds, thousands, or millions of sentences.

393
00:35:07,790 --> 00:35:11,210
The intent is to build up a model of the relationships between groups of words.

394
00:35:11,210 --> 00:35:18,570
And if we want to be more accurate, we can also increase the number of elements in the state, or raise the number-gram of the model to three or beyond.

395
00:35:19,190 --> 00:35:24,670
Though research generally seems to show that three is probably the point where you should stop.

396
00:35:25,430 --> 00:35:37,170
Now, there is one pre-existing proof of concept I could find that does more or less this and actually would generate output fast enough to be useful in password cracking.

397
00:35:37,170 --> 00:35:43,730
Sadly, it was single-threaded, written in a mix of C-sharp and C++, and designed with a Windows Compile target in mind.

398
00:35:43,730 --> 00:35:51,010
That simply wouldn't do for my purposes, so I created something similar in Python that is parallel, uses existing libraries, and is naturally more multiplatform.

399
00:35:51,030 --> 00:35:52,490
So, how well does it do?

400
00:35:52,810 --> 00:36:09,750
Well, the astute members of the audience when I showed this table on the right of every passphrase crack that was combinator-findable may have noticed some numbers that were a little too far into the lower right based on the computational complexity charts we went through before.

401
00:36:10,010 --> 00:36:11,850
Let me color that in for you.

402
00:36:12,350 --> 00:36:26,150
Now, the very astute of you might also infer that I did not in fact have unlimited access to eight V100s, and also that chart on the right is strangely positioned almost as if it extends further to the right.

403
00:36:26,230 --> 00:36:27,770
Well, it does.

404
00:36:27,890 --> 00:36:30,730
And I had a single 2080 tie for my research.

405
00:36:30,910 --> 00:36:37,350
I was also heavily timeboxing everything on here that isn't a shade of green, not from combinator attacks.

406
00:36:37,350 --> 00:36:38,370
Flat out.

407
00:36:38,550 --> 00:36:42,430
Admittedly, it's not a deluge of results, but, come on.

408
00:36:42,570 --> 00:36:43,470
Years.

409
00:36:43,470 --> 00:36:46,610
Literal years for the combinator attack would not have yielded some of these.

410
00:36:46,610 --> 00:36:49,890
And the couple out in the six and seven element column?

411
00:36:49,890 --> 00:36:52,110
Do you have any idea how long 10 to the 13 is?

412
00:36:52,110 --> 00:36:55,990
Because that's what it is corresponding on the difficulty computation.

413
00:36:55,990 --> 00:36:57,230
It's millennia.

414
00:36:57,610 --> 00:37:00,490
Certainly I'm very happy, but what about our much larger dataset?

415
00:37:00,870 --> 00:37:01,950
Well, a similar story.

416
00:37:01,950 --> 00:37:07,630
These attacks are very quick when doing only a couple of words, but admittedly don't pull in too much.

417
00:37:07,830 --> 00:37:09,870
Only tens of thousands, you know.

418
00:37:10,410 --> 00:37:18,890
The other factor you're likely to play here is there's just not that many passphrases that are also phrases that exist in the dataset with four words.

419
00:37:19,290 --> 00:37:24,470
While we're here, I would like to point out the accuracy tradeoff of choosing a 3-gram over 2-gram model.

420
00:37:27,310 --> 00:37:33,310
You can see that the 3-gram got a little over half as much, but it only took 1 twelfth the time.

421
00:37:33,570 --> 00:37:35,390
That is the accuracy tradeoff.

422
00:37:35,470 --> 00:37:43,250
Now, before people get too uninterested, I should show off the really impressive thing for me, which is what happens when you put these to use on even longer passphrases.

423
00:37:43,850 --> 00:37:49,770
There still shouldn't be much out here in the search space, but people seem content to use phrases at this length.

424
00:37:49,770 --> 00:37:53,070
Possibly because these should be safe, according to everybody's advice.

425
00:37:53,070 --> 00:37:56,850
And these aren't even common phrases, they're just kind of normal phrases.

426
00:37:56,910 --> 00:37:59,210
Here are some examples of what isn't safe anymore.

427
00:37:59,470 --> 00:38:08,630
These probably aren't the passphrases you expected to leave here knowing are crackable, and certainly not crackable in 1, 2, or 9 hours at speeds barely over 1GHz a second.

428
00:38:08,690 --> 00:38:09,830
Do you have nightmares yet?

429
00:38:09,830 --> 00:38:14,410
Because everything here was generated by a Markov model and a simple hashcat rule set.

430
00:38:14,410 --> 00:38:20,410
No dump passwords as input, no cherry picking shenanigans, and the training data was completely agnostic to the target passphrases.

431
00:38:20,470 --> 00:38:22,610
No targeting of any kind.

432
00:38:22,810 --> 00:38:28,650
Admittedly, it does produce some strange candidates sometimes, and I've collected some of the weirder ones I've seen on the right here.

433
00:38:29,070 --> 00:38:32,930
I don't know how he went from intrauterine pressure catheters to Kiwi or Kiwis.

434
00:38:32,930 --> 00:38:39,490
I can only assume one of the websites scraped from the training data was a blog post about making Kiwi or Kiwis with an embedded catheter cowboy advertisement.

435
00:38:39,490 --> 00:38:40,750
I really don't know.

436
00:38:40,750 --> 00:38:43,870
Now I should head off to some common questions I'm anticipating.

437
00:38:44,190 --> 00:38:49,450
Some of you familiar with hashcat might be thinking, um, doesn't hashcat already have Markov chains?

438
00:38:49,450 --> 00:38:51,050
Why can't we just do this?

439
00:38:51,150 --> 00:38:51,970
Well, it does.

440
00:38:51,970 --> 00:39:01,010
It has a pre-made model for character-level predictions, which, when you start going out to 15 character passwords and what you want is multiple actual words, that model falls apart pretty quickly.

441
00:39:01,010 --> 00:39:09,250
Not to mention it doesn't store relationships between words, and it will basically never finish, because the search space is at least 333 sextillion combinations.

442
00:39:09,250 --> 00:39:14,490
If you're thinking, haven't you tried this with GPT-2 or some other machine learning algorithm?

443
00:39:15,470 --> 00:39:18,150
My answer is, have you considered hash rates?

444
00:39:18,150 --> 00:39:30,090
Markov models are good for this because they're quick, especially compared to massive models like GPT-2 or some other ML model, which by itself is more than 5 gigabytes and tends to take multiple seconds to pop out a single prediction.

445
00:39:30,090 --> 00:39:34,970
We need millions of predictions in a second for it to be viable in password cracking.

446
00:39:35,110 --> 00:39:40,350
The other side of this is, the more advanced models focus on making paragraphs, or complete pages.

447
00:39:40,510 --> 00:39:41,930
We barely need sentences.

448
00:39:41,970 --> 00:39:47,610
And there are very few passwords I've seen that resemble more than a sentence fragment.

449
00:39:48,190 --> 00:39:51,450
Alright , head back out of the weeds here, it's time to wrap up and summarize.

450
00:39:51,550 --> 00:39:57,990
If you're not an attacker, you've probably been sitting through this talk, mildly terrified , waiting for some kind of recommendation .

451
00:39:58,430 --> 00:40:02,450
Allow me to make you wait slightly longer by addressing the red teamers first.

452
00:40:02,450 --> 00:40:06,270
Red teams, please , don't cop out.

453
00:40:06,290 --> 00:40:09,730
15 character passwords are hard, but they aren't that hard to crack.

454
00:40:10,130 --> 00:40:15,750
Even against Bcrypt, you should at least be doing Combinators, PrinceAttacks, and MarkovChains for the duration of your engagement.

455
00:40:15,910 --> 00:40:20,410
And don't pretend your results should approach zero, it should never be zero.

456
00:40:20,770 --> 00:40:25,670
There will always be somebody who picks something like HelloSpring2020 as their passphrase.

457
00:40:25,930 --> 00:40:28,050
Blue team, your turn finally.

458
00:40:28,150 --> 00:40:39,230
Do the math that applies to your situation, and do a little more than just gather people that scored highly on the SAT more than a decade ago, and pack them into a conference room and whiteboard it.

459
00:40:39,270 --> 00:40:47,110
If intercepted or dumped hashes or personal password reuse is a concern for you, and it almost always should be, feel free to take my math and represent it.

460
00:40:47,110 --> 00:40:51,770
Unless your organization is cracking its own passwords, you will not know what people are using.

461
00:40:52,110 --> 00:40:54,970
I recommend the best behaviors , but plan for the absolute worst.

462
00:40:55,010 --> 00:41:00,770
Which brings me to something that can serve as a starting point for what to pass along to end users.

463
00:41:00,770 --> 00:41:13,070
And this is my personal recommendation, which of course is fairly paranoid, but the intent here is to make sure a hash, regardless of what type of hash it is, can't be cracked in $500 of expense.

464
00:41:13,290 --> 00:41:20,710
Which means you're going to be making illogical or highly unlikely phrases of five or more relatively uncommon words that are thematically unrelated.

465
00:41:21,350 --> 00:41:22,070
Whew.

466
00:41:22,610 --> 00:41:28,210
That seems like a lot, but we're talking about diabetic unicorn trap Chicago tunnel as a passphrase.

467
00:41:28,210 --> 00:41:34,330
It takes a little bit to make, but these things should be able to hang around for a while.

468
00:41:34,330 --> 00:41:46,390
And unless you force an attacker to use a large dictionary combining multiple types of words, cities, structures, fantasy creatures, verbs, medical conditions, and use some words that are uncommon, you're going to be building your security posture with cracks at the foundation.

469
00:41:46,390 --> 00:41:51,010
There will be some edge case that will allow them to crack your passwords.

470
00:41:52,370 --> 00:41:56,090
So here's a very overfull slide of everything.

471
00:41:56,090 --> 00:41:57,330
Any questions?

472
00:41:57,330 --> 00:42:01,250
I am in the Discord channel waiting by this time.

473
00:42:02,870 --> 00:42:09,950
Rephraser is up there at the top, though it's probably just easier to look for GitHub trap code rephraser in Google.

474
00:42:10,810 --> 00:42:12,050
And, yeah.

475
00:42:13,010 --> 00:42:14,350
Feedback is appreciated.