1
00:00:05,330 --> 00:00:07,170
I'm watching myself on the stream.

2
00:00:07,170 --> 00:00:08,070
There we go.

3
00:00:08,590 --> 00:00:09,450
So, hi everybody.

4
00:00:09,450 --> 00:00:18,850
I'm Hank Leininger, a co-worker and fellow organizer of some of the events like the Bachelor Village and the Crack Me If You Can contest.

5
00:00:19,410 --> 00:00:34,630
So, I'm going to give a talk on a defensive technique and technology and open source tool that we ended up developing after sitting around thinking about all these interesting all these ways that we can make password cracking easier.

6
00:00:34,790 --> 00:00:40,270
We asked ourselves, okay, well, can we turn those into ways to make password cracking harder?

7
00:00:41,330 --> 00:00:51,370
The deal I didn't watch is we're going to learn from successful attacks and use that to inform us of how to make better defenses.

8
00:00:52,570 --> 00:00:54,710
Just a little about me.

9
00:00:54,930 --> 00:01:00,290
I came up wearing a sysadmin hat and, you know, got into security that way.

10
00:01:00,510 --> 00:01:04,370
Still enjoy building stuff about as much as I enjoy breaking them.

11
00:01:04,910 --> 00:01:09,770
And, yeah, I, you know, sometimes do talks and build things.

12
00:01:10,690 --> 00:01:14,110
And, PathWell, the topic of this talk.

13
00:01:15,730 --> 00:01:26,670
Like I said, it came sort of as just a, you know, brainstormed idea, but my co-workers actually turned it into running code that we released.

14
00:01:26,670 --> 00:01:28,350
So, kudos to them.

15
00:01:29,230 --> 00:01:36,070
So, the audience probably includes people that can't spell hashcat and people who wrote hashcat.

16
00:01:36,550 --> 00:01:48,430
So, I'm going to give a very oversimplified overview of a particular kind of cracking technique for the sake of people for whom this is not second nature.

17
00:01:48,430 --> 00:01:54,190
And those of you who know that I'm oversimplifying, don't at me, bro.

18
00:01:55,750 --> 00:02:00,310
So, we have a bunch of classic defenses used for password cracking.

19
00:02:00,910 --> 00:02:05,290
I got to keep in mind that the slides update way slower than I do.

20
00:02:07,150 --> 00:02:15,190
All of these standard old ways that we try to make passwords stronger, yeah, they basically don't work.

21
00:02:15,210 --> 00:02:37,610
There's a bunch of talks that go into a lot more detail than I'm going to, but password complexity rules, they helped a little when they were newly enforced, but it turns out humans make very similar decisions in the face of similar policies.

22
00:02:37,730 --> 00:02:43,230
And password crackers have figured out the way humans respond to being given certain rules.

23
00:02:43,570 --> 00:02:48,130
And we can guess where everybody's going to end up.

24
00:02:48,130 --> 00:02:54,050
As soon as we know the password policy of a company, we can guess what a lot of those users passwords are going to look like.

25
00:02:54,050 --> 00:03:02,330
And if we know what their passwords were a year ago, and we know their rotation requirements, we can probably guess what they are today.

26
00:03:04,610 --> 00:03:10,810
Just to illustrate some examples, I want to throw some numbers up here, which are rough.

27
00:03:10,810 --> 00:03:12,150
Again, don't at me.

28
00:03:12,390 --> 00:03:22,870
But suppose you built yourself a budget password cracking rig, and congratulations, you can exhaust the entire eight character key space in a day or under a day.

29
00:03:23,010 --> 00:03:29,030
But once password links get up to 9, 10, 11 characters, that becomes infeasible.

30
00:03:29,810 --> 00:03:35,110
However, nobody actually tries to brute force the entire key space.

31
00:03:35,330 --> 00:03:42,110
We'll figure out what's the most relevant or bang for the buck places to spend our compute time.

32
00:03:44,410 --> 00:03:51,570
So the math and the proportions still apply, but we're not going after the entire key space.

33
00:03:51,570 --> 00:03:57,910
We're going after the most relevant tiny slice of the password key space.

34
00:03:58,070 --> 00:04:14,210
So one way to divide up that key space is what Hashcat calls mask attacks, where you say, in this character position, it's going to be an uppercase letter, and I want you to try every uppercase letter, and in this position, I want you to try every number,

35
00:04:14,210 --> 00:04:15,410
and so on.

36
00:04:15,410 --> 00:04:17,690
And usually you don't do this for the entire password.

37
00:04:17,690 --> 00:04:29,490
You do it for, I want to take a dictionary word and then tack this pattern onto the end of it, or I want to take a dictionary word and apply rules that morph it in these ways in these positions.

38
00:04:30,030 --> 00:04:41,970
So again, just for the sake of figuring out how to discuss this and do the math, we'll use this way of looking at it in this notation.

39
00:04:42,150 --> 00:04:50,810
So suppose you wanted to try every possible password of a specific mask.

40
00:04:51,350 --> 00:05:07,630
And so the math that I've done here is, if we have four different character classes, uppercase letters, lowercase letters, numbers, and special characters, each position of the password could be one of those four.

41
00:05:07,630 --> 00:05:18,870
So essentially, the password key space might be 95 to the 8th, but the topology key space is 4 to the 8th.

42
00:05:19,470 --> 00:05:27,530
And if we have an 11 character, there's 4 to the 11th different topologies.

43
00:05:27,530 --> 00:05:40,090
If we pick the single topology of uppercase number, lowercase, lowercase, lowercase, whatever, number, number, special, we multiply out the possibilities in each of those positions.

44
00:05:40,090 --> 00:05:53,350
And we say to exhaust that entirely, which again, we would actually combine that with word lists or other things, so that we didn't have to blindly guess, we would guess the most frequent or the most likely ones.

45
00:05:53,350 --> 00:06:01,710
In any case, if you did want to exhaust the whole thing, there would be 265 trillion possible combinations.

46
00:06:02,230 --> 00:06:13,650
And that hypothetical cheapo cracking box that would be totally infeasible to try to reinforce the entire key space could do that one topology in about half an hour.

47
00:06:15,870 --> 00:06:33,930
So the question we have to ask for the sort of evaluating the effectiveness of hash mask based attacks is, do users bias towards specific math pattern or specific topologies?

48
00:06:34,090 --> 00:06:42,190
If we could guess which patterns were overused by users, then we would focus our attacks just on those.

49
00:06:42,190 --> 00:06:47,270
And we wouldn't have to, we wouldn't have to worry about 99.99% of the key space.

50
00:06:47,270 --> 00:06:52,110
We would only have to worry about the parts of the key space where the users are all clustered.

51
00:06:52,870 --> 00:06:56,670
And again, we would actually combine this with other smarts.

52
00:06:56,670 --> 00:07:00,070
So in actual fact, our work would be even less.

53
00:07:01,830 --> 00:07:10,470
So at our, at our company, at our day job, we do a lot of password audits, both regular routine recurring ones and one-offs when we do a pen test.

54
00:07:10,470 --> 00:07:13,030
So we have a whole bunch of data to look at.

55
00:07:14,710 --> 00:07:15,750
Spoiler alert.

56
00:07:15,750 --> 00:07:19,210
Yes, of course users cluster into common topologies.

57
00:07:19,210 --> 00:07:21,770
That's why mask attacks are worth doing.

58
00:07:21,810 --> 00:07:24,770
But we wanted to get some science and some numbers behind that.

59
00:07:24,770 --> 00:07:33,430
So we analyzed the results of having cracked high percentages of a number of different organizations.

60
00:07:35,450 --> 00:07:44,990
The first case study I'm going to throw out numbers of, we cracked, you know, around over 99% of current and historical hashes.

61
00:07:45,150 --> 00:07:50,770
And then we broke the, we attacked them not with a mask centric focus.

62
00:07:50,770 --> 00:08:00,990
We attacked them with all our regular techniques, but then we did the crunching in the math and we said, okay, how many different topologies were in here and what were the most frequent and how frequent were they?

63
00:08:01,570 --> 00:08:10,810
Out of those quarter million different logins and hashes, there were only around 7,000 unique topologies in use.

64
00:08:11,610 --> 00:08:23,590
And over 10% of the population used each of the two most popular, actually three of the three most popular topologies.

65
00:08:24,990 --> 00:08:39,710
So if we knew nothing about this organization whatsoever, other than that uppercase lower, lower, lower, lower number number was going to be highly successful, we would crack over 10% of their population without a second thought.

66
00:08:41,610 --> 00:08:45,810
And if we did, if we did all the top five, we would have gotten almost half the company.

67
00:08:46,190 --> 00:08:55,010
If we did the top 100, which is still a tiny slice of the overall key space, we would have gotten 85% of all hashes.

68
00:08:55,390 --> 00:09:17,810
And by the way, you can also determine, you can discern from the relationship between the number one most popular and the number two most popular and the number three and four, sorry, three and five, that this organization made their password policy stronger sometime in the history of the dump that we have.

69
00:09:17,810 --> 00:09:20,290
Good for them, stronger password policy.

70
00:09:20,290 --> 00:09:29,670
No, totally worthless because all their users did was made the word inside just one letter longer and added another lowercase to that run.

71
00:09:29,670 --> 00:09:33,890
So trivial for us to figure that out and go after.

72
00:09:35,290 --> 00:09:43,010
Now this is a graphical depiction of how frequent the most frequent topologies were.

73
00:09:43,070 --> 00:09:45,570
Pay no attention to the labels on the x-axis.

74
00:09:45,570 --> 00:09:50,710
They don't mean anything other than the unique identifier that we assigned to each particular topology.

75
00:09:50,710 --> 00:10:03,130
The point being, the most, the few most popular topologies, the ones that we've crowded on, you know, we've lined up on the left-hand side of the graph, were, you know, 10% or more of the population.

76
00:10:03,130 --> 00:10:06,490
And then it tailed off very, very quickly and steeply.

77
00:10:06,490 --> 00:10:15,730
So there were some users who were indeed special snowflakes, but they were like a handful of them way off to the right side of the graph.

78
00:10:16,270 --> 00:10:25,610
They don't help the organization as a whole stay safe because the people on the left-hand side that are all grouped together, they're easy prey.

79
00:10:26,870 --> 00:10:37,330
No other organization, kind of a similar story, slightly larger hash pool, slightly lower crack percentage at the time we did this crunching, but still well over 90%.

80
00:10:37,330 --> 00:10:44,690
So we were confident that the data that we were, the conclusions we were going to draw from this data were valid.

81
00:10:44,770 --> 00:10:58,450
By the way, to preempt a question that I would ask if I was watching this presentation, all of the subsequent stuff is based on number of cracks compared to total population, not number of cracks compared to total number of cracks.

82
00:10:58,450 --> 00:11:15,550
For instance, when I say that 19,000 people using or hashes using that one topology is 4.3%, it's 4.3% of 449,000, not 4.3% of 419,000 that we were successful at.

83
00:11:15,590 --> 00:11:23,990
We don't know what the 30,000 were that we didn't crack, but we know what percentage of the total the ones we did crack are.

84
00:11:26,560 --> 00:11:34,340
So in this organization, the numbers aren't as bad, but it's still a very significant relationship.

85
00:11:34,340 --> 00:11:44,600
And it's also, once again, the case that somewhere embodied in the password history that we captured, they changed their policies to make them stronger.

86
00:11:44,600 --> 00:11:54,060
But the way people responded to it was, oops, was just to add another special, added another character at the end, which was a special.

87
00:11:54,720 --> 00:12:00,120
Because they went from requiring eight characters, three of four, to requiring nine characters, four of four.

88
00:12:00,120 --> 00:12:03,700
So users are just like, oh, okay, I'm gonna put an exclamation point at the end.

89
00:12:04,040 --> 00:12:09,380
Once again, didn't stop us, you know, from cracking the new ones.

90
00:12:10,460 --> 00:12:13,400
This is the graph for that organization.

91
00:12:13,400 --> 00:12:18,680
It's not nearly as bad and ugly, but it is still bad and ugly.

92
00:12:22,440 --> 00:12:29,400
So we did this same kind of math across eight or so different large data compilations.

93
00:12:29,400 --> 00:12:40,480
We discarded anything that was too small to be, you know, we didn't want a single outlier to skew the overall numbers too much.

94
00:12:40,480 --> 00:12:48,480
And we also limited it to ones that we had cracked a substantial portion, over 90%.

95
00:12:48,480 --> 00:13:02,420
Again, so that the conclusions we were able to draw were sort of statistically, you know, valid for the population, knowing whatever the caveats, you know, you had to take into account.

96
00:13:02,880 --> 00:13:21,600
This graphic is all of the histograms for each of those organizations, not sorted by what's popular for them, but basically stacking on top of each other, so that we can see clear patterns occur.

97
00:13:22,380 --> 00:13:32,180
This very first topology on the list, it was popular in all five of the organizations, or all eight that are included in this data set.

98
00:13:32,180 --> 00:13:35,020
Same thing, you know, the number three one was pretty popular.

99
00:13:35,020 --> 00:13:38,620
The number five one was hugely popular across everybody.

100
00:13:38,740 --> 00:13:51,620
The only organization that was substantially different from all the others is the one that was graphed in cyan or light blue here, where they're a huge false spike and nobody else is a huge spike in that area.

101
00:13:52,240 --> 00:14:09,760
This is a big enough anomaly we dug in to figure out why, and it's because that particular organization had a default password that was so commonly used and still used by all their users, by a huge percentage of their users, that it threw off all the rest of the numbers.

102
00:14:12,040 --> 00:14:14,800
And it was a specific outlier just for them.

103
00:14:14,800 --> 00:14:22,380
I don't even remember what it was, but imagine it was, you know, one change me, and it was a number one, and then all lowercase.

104
00:14:22,380 --> 00:14:29,440
And even when people changed their password away from one change me, they made it two change me, or three change it.

105
00:14:29,440 --> 00:14:33,600
And so their topology was exactly the same as the original password was.

106
00:14:34,300 --> 00:14:43,480
Once you exclude that one data point, we see there's a huge commonality in which topologies are super common across industries.

107
00:14:43,480 --> 00:14:47,700
And these are companies in different sectors.

108
00:14:47,700 --> 00:14:51,260
They are, for the most part, US-centric.

109
00:14:51,360 --> 00:14:56,300
Some of them are global, but the majority of their user population was still English speakers.

110
00:14:56,300 --> 00:14:57,800
So that is one caveat.

111
00:14:57,800 --> 00:15:05,020
It's very possible that somebody with alternate language sets that users gravitate towards would look somewhat different.

112
00:15:05,020 --> 00:15:18,140
But if you knew nothing at all about a company other than that it had a substantial presence in the United States, take the top five common topologies on this list, attack those, and you're going to get tons of users.

113
00:15:19,200 --> 00:15:32,460
And as a defender, this is terrible, because even in the strength of what we think of as good password strength policies, we know our users are going to land this way, and attackers are going to come after them and hunt them down and kill them.

114
00:15:33,920 --> 00:15:46,840
So just to recap the kind of things that all this data crunching told us to confirm our suspicion about the problem and where we ought to try to find a way to improve the situation.

115
00:15:49,710 --> 00:15:51,910
Users pick the lowest competent denominator.

116
00:15:52,130 --> 00:15:57,730
There's specific things that they commonly do when told that the password policy is getting stronger.

117
00:15:58,470 --> 00:16:15,050
And those behaviors, although there are absolutely smart ways to attack an organization specific to that organization, go after word lists for their industry, go after the proper names of things in their hometown and sport, you know, sports teams and location names and blah,

118
00:16:15,050 --> 00:16:15,830
blah, blah.

119
00:16:16,170 --> 00:16:23,110
Still, these trends are going to be common no matter who and where the company is.

120
00:16:25,130 --> 00:16:30,670
And complexity rules just don't help, not nearly as much as we think they do anyway.

121
00:16:33,310 --> 00:16:41,450
By the way, another way to think about this in the COVID-19 era is users are not social distancing their passwords.

122
00:16:42,250 --> 00:16:55,050
To graphically depict what having 12% of your user population landing in a single topology means, if you were to imagine the land area of the...

123
00:17:43,140 --> 00:17:44,600
All right, I should be back.

124
00:17:44,600 --> 00:17:45,660
Sorry about that.

125
00:17:46,940 --> 00:18:04,780
So, if we were to imagine the entire land area of the United States as being the possible password key space that users could pick from, 13% of all users choose to live together in a land area smaller than Manhattan.

126
00:18:05,220 --> 00:18:10,680
And what's worse is when you tell users to change their password, they don't go far.

127
00:18:10,680 --> 00:18:13,920
They just move a couple doors down or maybe one block away.

128
00:18:14,120 --> 00:18:18,140
So, any attacker knows they don't have to go far to hunt them down.

129
00:18:20,540 --> 00:18:28,780
And another thing about this is it applies even to much stronger password policies out of the box.

130
00:18:30,120 --> 00:18:37,040
We discussed this with some of our friends that work in places where... and this was going back to 2010.

131
00:18:37,160 --> 00:18:43,000
They had rules like you have to use a 15-character password and it has to have minimum two of everything.

132
00:18:43,080 --> 00:18:45,220
And they were like, so how strong is that really?

133
00:18:45,220 --> 00:18:50,700
And we said, well, it's really strong if you're not a smart attacker.

134
00:18:50,980 --> 00:19:08,460
But if you were a smart attacker and used, among other things, mask-based attacks targeting the most common topologies, you would have painfully... you would have a surprisingly good success rate.

135
00:19:11,890 --> 00:19:32,970
If you were looking at a large organization with lots of users and password histories, you would still likely be able... and you picked the topology that had the most users in it, you would likely still succeed in cracking a password roughly once every 12 hours for however many millions of years.

136
00:19:33,990 --> 00:19:37,390
But you don't need more than a few to get you started.

137
00:19:40,850 --> 00:19:41,690
All right.

138
00:19:41,690 --> 00:19:49,630
So, that's kind of the foundational concept that led to what I'm going to talk about next.

139
00:19:50,750 --> 00:19:54,670
So, it became clear we need new defenses.

140
00:19:54,670 --> 00:19:56,930
We need new ways to make things harder.

141
00:19:59,570 --> 00:20:03,210
The rules that we have now aren't terrible, but they're not enough.

142
00:20:04,110 --> 00:20:10,750
And one of the worst things we need... one of the strongest things we need to do is figure out how to keep users from all congregating in the same place.

143
00:20:10,790 --> 00:20:23,870
No matter what rules we impose on them, human nature says the majority of those users are going to cluster in a few new places, which can still be predicted or discovered by the attacker.

144
00:20:24,610 --> 00:20:27,830
So, at a high level, what are some things we could do?

145
00:20:27,830 --> 00:20:37,370
We could blacklist topologies that we know are a problem, where we know or predict users are going to land.

146
00:20:37,370 --> 00:20:44,530
And not just blacklist individual passwords, but blacklist the topologies, the shapes of those passwords.

147
00:20:44,770 --> 00:20:52,350
Nobody is ever allowed, again, to have a password that's an uppercase letter followed by a bunch of lowercase, followed by a couple of numbers, followed by a special.

148
00:20:52,530 --> 00:20:53,890
Just can't happen.

149
00:20:54,790 --> 00:21:04,150
Another thing we can do is require a minimum change distance between where your current password is and where the new one is that you want to go to.

150
00:21:04,550 --> 00:21:19,250
So, whatever words you're using, if you're using a three-letter word and a four-letter word with the first letters capitalized, the second letters replaced with numbers, and a special character in between, you can't use that exact same pattern on your next password change.

151
00:21:20,810 --> 00:21:29,210
And also, don't allow your users to congregate on whatever topology they choose to congregate on.

152
00:21:29,910 --> 00:21:50,210
This is a term that we didn't know when we were thinking about this early, but which is becoming one of the ways to describe this part, is dynamic password strength enforcement, meaning the password strength or the password policies you enforce are adaptive based on what your user population is doing.

153
00:21:51,890 --> 00:21:58,430
There's two big costs to this, which are key space reduction and user rebellion.

154
00:21:58,470 --> 00:22:01,050
I'll talk more about those in a bit.

155
00:22:03,240 --> 00:22:05,500
So first, what do I mean by blacklisting?

156
00:22:05,500 --> 00:22:07,200
It's not that complicated.

157
00:22:07,200 --> 00:22:15,180
We figure out what the most popular topologies are, usually for a given policy.

158
00:22:15,180 --> 00:22:25,680
Like, if your policy is 10 characters or more, it doesn't mean, it's not interesting to figure out what the most popular eight and nine character topologies are.

159
00:22:25,900 --> 00:22:35,120
But, and similarly, if you require four of four, then we don't care about blacklisting topologies that are three of four or two of four.

160
00:22:37,840 --> 00:22:50,420
By the way, whatever list you come up with as the best ones to blacklist, are also the best ones to start with when you're a cracker, you know, a patchwork cracker, and nobody's enforcing pathwell yet.

161
00:22:51,280 --> 00:22:55,800
So we published what was our working set at the time , back in 2014.

162
00:22:56,360 --> 00:23:02,100
We could, you know, we and a bunch of others can probably contribute updated data by now.

163
00:23:03,180 --> 00:23:12,100
But we also, with just about everything we figure out and publish, we figure out, we assume bad actors have already figured these things out before we started.

164
00:23:12,220 --> 00:23:26,680
That's one of the reasons that CoreLogic started the password, the Crack PC Can contest back in 2010, because we figured bad actors were already figuring out and sharing, you know, password cracking tricks.

165
00:23:26,680 --> 00:23:33,760
And we wanted to bring more of that discussion out into the open for defenders and researchers to be aware of too.

166
00:23:36,690 --> 00:23:39,470
So what is the effectiveness of blacklisting?

167
00:23:40,050 --> 00:23:56,490
Well, if the attackers have figured, follow these exact techniques, and they go after, they use a top-end approach of targeting the topologies that are most likely to be successful, then when we take those top ones away, they're going to start, they're going to get zero cracks in their early,

168
00:23:56,490 --> 00:23:58,110
in their initial pass.

169
00:23:58,110 --> 00:24:05,370
Instead of getting 25% of the organization in minutes, they're going to get zero in the first hours and wonder what's up.

170
00:24:05,810 --> 00:24:16,310
Of course, once attackers figure out what we're doing, and once they're able to figure out what users do next, then maybe we're just pushing the problem around.

171
00:24:16,330 --> 00:24:28,290
You know, we blacklist these 100 most popular topologies, and now users are going to congregate in 100 different ones, and it's just chicken and the egg, or not chicken and the egg, but it's an arms race.

172
00:24:28,290 --> 00:24:31,270
We just, you know, go back and forth, maybe.

173
00:24:34,170 --> 00:24:41,870
The next thing we can do, which is starting to get more adaptive, is a minimum topology change at password change time.

174
00:24:42,210 --> 00:24:52,550
So without any kind of enforcement of topology change, a user who just increments a number in their password is a perfectly accepted new password.

175
00:24:55,410 --> 00:25:16,470
And similarly, even once we're doing that, even if we enforce the thing that says, hey, you can't use the same topology that you did in your previous password, they're probably going to make the smallest change that constitutes a topology change, such as pick a random letter that was uppercase and flip it to lower,

176
00:25:16,470 --> 00:25:18,090
or pick a lower and flip it to upper.

177
00:25:18,470 --> 00:25:21,050
That would pass the test.

178
00:25:22,110 --> 00:25:29,050
But it would still be lower down on an attacker's list than incrementing a number, or possibly incrementing a letter.

179
00:25:29,390 --> 00:25:48,010
And more importantly, if we say, if we say, well, let's figure out how can we measure the difference, the distance between one password and another, and then what's a minimum distance that we want to enforce?

180
00:25:51,300 --> 00:26:01,480
So, one of our people who is, well, way more educated than I am in the computer science realm said, oh, that's Levenstein distance.

181
00:26:01,480 --> 00:26:03,360
And I said, what's that?

182
00:26:03,940 --> 00:26:07,060
It was what I wanted without knowing it.

183
00:26:08,300 --> 00:26:12,560
It's a science, it's a way to measure the distance between two strings.

184
00:26:12,560 --> 00:26:24,940
How many edits, how many inserts, or removals, or increments, or whatever did, oops, yep.

185
00:26:27,560 --> 00:26:28,460
So,

186
00:26:31,580 --> 00:26:44,140
so for a strip, just for string changes, you measure the Levenstein distance between two strings by looking at how many characters were changed, added, removed.

187
00:26:45,580 --> 00:26:48,680
For topologies, we can do much the same thing.

188
00:26:49,420 --> 00:27:06,320
But when we, so when we look at these couple of hypothetical password changes, if you just, if you keep all of the character types the same, and you just increment one of them, or decrement, your topology's Levenstein distance change is zero.

189
00:27:06,780 --> 00:27:17,600
But if you change the character class of one of the positions, then you've successfully, you know, moved your topology from one to another.

190
00:27:19,340 --> 00:27:32,680
And obviously, if you combine more than one thing at a time, you may or may not, you know, your edit distance of the string and your Levenstein distance of your topology may be different.

191
00:27:32,820 --> 00:27:41,200
And if you go about, you know, making multiple changes at once, then it's going to be, it's not going to be the very next thing the attacker tries.

192
00:27:41,200 --> 00:27:50,920
When they learn that your password used to be password 20 exclamation point, passwords 20 exclamation point won't be the first thing they try.

193
00:27:50,920 --> 00:27:53,020
It might be the 10th.

194
00:27:53,020 --> 00:27:58,180
The, you know, more interesting if you change more positions throughout the string.

195
00:28:00,260 --> 00:28:10,000
And everything, every time you make a topology change, you multiply out the number of different paths the attacker has to go down in order to try to find you.

196
00:28:10,660 --> 00:28:14,340
Okay, so this still isn't really where leveling.

197
00:28:14,440 --> 00:28:32,880
Where leveling is, you know, comes from, at least I borrowed the term from the way things like solid state disks, SSDs, try to spread their writes out across all of the different memory cells before they come back to one that was previously written to and write to it again.

198
00:28:32,880 --> 00:28:42,280
So in this case, we want to take all these users who've bunched up in specific buckets of a specific topology and spread them out.

199
00:28:42,560 --> 00:28:57,940
The most ideally where leveled population of user passwords would have on average, you know, one or less users per bucket, or at least no more users in any particular bucket than any other.

200
00:28:59,900 --> 00:29:18,080
That way, if an attacker tries to pick any random topology there, or rather, any topology that they know humans are likely to gravitate towards, they'll get few, if any, cracks instead of, oh, 5% of your users landed on that topology.

201
00:29:19,640 --> 00:29:29,840
So we have to think about what are the impacts to an attacker of using where leveling effectively and uniformly.

202
00:29:30,020 --> 00:29:34,120
Now, there are downsides to doing it too, and I'll get to those in a second.

203
00:29:34,240 --> 00:30:04,640
But if the attacker is used to being able to target that first or the first top five topologies and get, you know, 10% of users per topology, 50% of your entire population in just, you know, 10 topologies or less, if users were spread completely out, then you would end up with something like six orders of magnitude more work to get the same number of cracks,

204
00:30:04,640 --> 00:30:11,660
or six orders of magnitude fewer cracks using the same amount of guessing time.

205
00:30:11,820 --> 00:30:15,980
Now, in reality, it's not going to be that good.

206
00:30:15,980 --> 00:30:17,680
And it could be even worse.

207
00:30:17,740 --> 00:30:31,320
Suppose the attacker knew somehow exactly which topologies were in use by within your organization, then they could target just those topologies and ignore all the ones that aren't in use.

208
00:30:31,520 --> 00:30:53,440
However, because we know that their success rate in any given topology is now minimized, it's controlled, there's not going to be more than one or more than the number of topologies divided by your number of users in that particular topology, their success rate still drops by two to three orders of magnitude.

209
00:30:53,740 --> 00:31:04,800
In the realistic case, where users spread out, but they're not, it's not like you're originally assigning them a topology, you may as well assign them a password if that was the case, and that's going to be terrible, and everyone will kill you.

210
00:31:06,040 --> 00:31:12,900
But in the realistic case, you're probably looking at a four to five orders of magnitude change in work factor.

211
00:31:13,540 --> 00:31:19,080
And again, by that, I mean, surprisingly to us, it works out more or less reflexively.

212
00:31:19,080 --> 00:31:36,400
If you say, I used to spend this many hours and crack this many thousand passwords, I want to spend that same number of hours and see how many passwords I crack, you will crack one ten thousandth or so of the passwords you used to do in the same amount of time.

213
00:31:36,620 --> 00:31:52,120
And at the same, by the same token, if you say, I used to crack this many thousands of passwords, I want to crack that same percentage or that same number, no matter how long it takes, it's going to take you 10,000 to 100,000 times as long as it used to.

214
00:31:54,860 --> 00:31:57,380
So what are some costs here?

215
00:31:57,760 --> 00:32:05,160
The one that first comes to sort of mathematical minds is, I'm blacklisting parts of the keyspace.

216
00:32:05,160 --> 00:32:10,020
That means I'm making it so that there's fewer possible passwords users could choose.

217
00:32:10,020 --> 00:32:12,080
Oh my God, we're reducing our keyspace.

218
00:32:12,080 --> 00:32:15,600
That helps the attacker because now they have less ground to cover.

219
00:32:15,820 --> 00:32:21,960
But once you do the math, that actually almost disappears into nothing.

220
00:32:22,140 --> 00:32:37,420
So for instance, if you are talking about eight character password length, and in reality, there's almost no world and no hash in which eight character passwords are okay anymore, but keep the math simple.

221
00:32:37,420 --> 00:32:38,480
Start with eight characters.

222
00:32:38,480 --> 00:32:45,140
We're going to have 48 possible different topologies, 64K, 65,000.

223
00:32:45,220 --> 00:32:56,440
If we blacklist the 100 most popular topologies, we still, that's less than, that's only around 0.2% of the possible keyspace.

224
00:32:56,600 --> 00:33:15,440
And in fact, if you are talking about nine character, 10 character, 11 character passwords, the percentage of your keyspace that you're deleting by blacklisting is even smaller if you're just talking about the top 100 out of a million instead of out of 65,000

225
00:33:15,440 --> 00:33:16,120
.

226
00:33:17,140 --> 00:33:39,100
Now, the thing about forcing unique topology use, or at least spreading uniformly in among the topologies that are not blacklisted, you actually do have a problem where any given randomly selected topology is now more likely to have a password in it than before you impose this rule.

227
00:33:39,880 --> 00:34:00,400
But if you think about the fact that what we're getting rid of by doing that is we're getting rid of the property where an attacker can find one topology that has five to 10% of your users, even if it's only that they can find a topology that has 1% of your users,

228
00:34:00,400 --> 00:34:09,240
then the difference is still massively in our favor that this is an improvement for the defender.

229
00:34:10,980 --> 00:34:15,340
Now, there's another possible downside.

230
00:34:15,520 --> 00:34:21,060
As Perth said, you're going to have, you know, violence against your security staff.

231
00:34:21,060 --> 00:34:22,280
Well, maybe.

232
00:34:23,340 --> 00:34:29,780
On the one hand, any new control that adds work for users is going to be resisted one way or the other.

233
00:34:30,920 --> 00:34:36,720
One of the ways, one of the things that you could do about this is measure it, like do pilot testing.

234
00:34:37,520 --> 00:34:51,640
Carnegie Mellon actually did a usability study on the difficulty of different stronger password strength enforcement, and their results were, yes, it matters, but it's not as bad as you might think.

235
00:34:51,640 --> 00:34:53,020
That's the TLDR of it.

236
00:34:53,020 --> 00:34:56,660
And that there are specific ways you can address it with user hinting.

237
00:34:57,160 --> 00:35:03,400
Now, what are ways you could hint to user, hey, your password isn't strong enough.

238
00:35:03,500 --> 00:35:06,200
If you adjust it this way, it would become strong enough.

239
00:35:06,300 --> 00:35:10,300
Or literally, your password is too weak, make it this instead.

240
00:35:11,060 --> 00:35:17,480
Those are decisions that, you know, we can work our way through and different organizations can choose differently.

241
00:35:17,520 --> 00:35:28,380
But it appears from CMU's research that some flavor of that can drastically solve the user complaints.

242
00:35:28,380 --> 00:35:33,380
You're going to have cranky users, but you're not going to have 100% of your users get cranky.

243
00:35:34,380 --> 00:35:37,200
And, yeah.

244
00:35:37,640 --> 00:35:51,160
Now, we always have to remember that if we're going to give extra information to users at password change time, that might somehow become user hints to the attacker.

245
00:35:52,740 --> 00:35:57,140
Some of those things we've thought through and figured out ways to address.

246
00:35:57,140 --> 00:36:00,820
Others are just going to be tradeoffs we're going to have to know that we're making.

247
00:36:03,820 --> 00:36:10,860
And keep it in mind when an organization chooses, for instance, what kind of hint level to use, they're going to have to keep that in mind.

248
00:36:11,360 --> 00:36:11,680
All right.

249
00:36:11,680 --> 00:36:12,600
So, enough of that.

250
00:36:12,600 --> 00:36:13,440
The code.

251
00:36:14,180 --> 00:36:25,400
So, a few years back now, we released a PAM library, a PAM module that implements all this stuff with optional controls to enable it and set the different parameters.

252
00:36:28,760 --> 00:36:42,320
We developed and tested it on multiple Linuxes, Gen 2, Ubuntu, probably some of the Red Hats, and I believe Solaris, but don't quote me on that.

253
00:36:43,480 --> 00:36:50,940
And it basically implements all the things that I just talked about, and I'll talk a little more about specifically how in a second.

254
00:36:52,020 --> 00:36:55,700
We did patent the ideas here, but the code is AGPL.

255
00:36:55,700 --> 00:36:57,680
You can use it for free all you want.

256
00:36:57,680 --> 00:37:04,560
The TLDR of the way the AGPL works is you can use this all you want for free stuff and open source stuff.

257
00:37:04,560 --> 00:37:13,380
If you want to make money off of it or make custom modifications that you make money off, then you have to talk to us because the AGPL license won't work.

258
00:37:13,380 --> 00:37:17,700
You'll have to ask us for a dual license on something or other, but that's fine.

259
00:37:18,800 --> 00:37:34,000
We did it as a PAM library or PAM module for Linux deployment, but with the thought that the API and the library could be used by other things too, like an LDAP server that implements single sign-on or what have you.

260
00:37:36,300 --> 00:37:43,440
Yes, so Perth is thinking about how attackers would adapt.

261
00:37:43,440 --> 00:37:46,180
I actually have that in here in a little bit too.

262
00:37:47,600 --> 00:37:52,300
Okay, so what are the different modes that we implemented in the PathWell open source code?

263
00:37:52,300 --> 00:38:03,100
So audit mode is simply the tracking of topologies that are used as users change their passwords.

264
00:38:03,100 --> 00:38:11,920
When you start in an organization, you don't know other than by cracking their existing password base, which is an option, especially for us, but it might not be an option for everybody.

265
00:38:11,920 --> 00:38:17,180
So you could enable this to record topology use as it goes.

266
00:38:17,880 --> 00:38:26,200
Now, if you're going to keep a database of all your users' topologies, you better consider that database pretty sensitive and be careful with it.

267
00:38:26,820 --> 00:38:40,040
And because of implementation details in our proof of concept, it's currently limited to tracking the topologies of characters up to 29 characters long, which, you know, ought to be enough for anybody.

268
00:38:42,200 --> 00:38:48,380
Then there's enforcement modes, which actually impose different controls.

269
00:38:48,380 --> 00:38:51,480
The first and most obvious one I'm going to talk about is blacklisting.

270
00:38:51,480 --> 00:38:55,860
And it's basically everything I said before that blacklisting should do, it does.

271
00:38:55,940 --> 00:39:04,620
We distribute a standard list, a starter sort of list of topologies to blacklist, but you could also add or modify your own.

272
00:39:05,960 --> 00:39:24,280
And again, I'll reiterate, blacklisting itself is not enough as a permanent solution, but it does, you know, help you be better and more resistant than other organizations that somebody might attack.

273
00:39:25,120 --> 00:39:33,720
So, you know, you don't have to run faster than the bear, you just have to run faster than the other, the other guy.

274
00:39:34,360 --> 00:39:46,840
The next enforcement option is minlev, that's Levenstein distance, the minimum edit or the minimum distance for the topology of the new password candidate versus what the previous one was.

275
00:39:47,420 --> 00:39:55,040
This enforcement, actually, I should mention, neither blacklist mode nor minlev mode require auditing to be turned on.

276
00:39:55,040 --> 00:40:11,720
So if you're, if you have heartburn about the idea of maintaining a database of in-use topologies, and I don't blame you, then these features don't need that at all, because they only care about what your new password request is in the case of blacklist,

277
00:40:11,720 --> 00:40:16,180
or what your new password is compared to your old password in the case of minlev.

278
00:40:16,180 --> 00:40:24,520
They don't care about what your new password is compared to the entire rest of your organization, which is what max-use is about.

279
00:40:24,880 --> 00:40:36,820
Max-use, it allows you to say, I want to have a threshold, any given topology bucket can only have one user, or can only have five users, or whatever's the right number for the size of your organization.

280
00:40:39,920 --> 00:41:03,280
And again, the point here is, you know, if the attacker, if you have successfully kept users from clumping anywhere, or rather, if you want to prevent users from clumping anywhere, you use this, and then a user setting their password can't set their password to be the same topology that they or anybody else in your organization has used,

281
00:41:03,280 --> 00:41:07,900
or if not more than two have used, or whatever your setting is.

282
00:41:09,760 --> 00:41:26,860
Now, it's called an enforcement, well, it's an option that matters in enforcement mode, but it's not an enforcement, but rather a sort of, you know, that controls the user experience if you want to give any hints.

283
00:41:26,980 --> 00:41:43,720
So, we did an experimental hint info level implementation, partly to facilitate that kind of research that I talked about before, the user acceptance of what's the user experience when I tell them this much information, as opposed to when I tell them that.

284
00:41:45,200 --> 00:42:03,440
So, out of the box, PathWell doesn't give users any particular feedback or information, doesn't tell them how they could make their password stronger, doesn't leak information about the organization, doesn't give information to the screen that would be useful to somebody shoulder surfing.

285
00:42:03,960 --> 00:42:09,400
But if you choose to, if it's right for your organization, you can turn up hint levels.

286
00:42:10,440 --> 00:42:14,460
And this is supported by the backend API as well, not just by the PAM library.

287
00:42:14,460 --> 00:42:22,640
So, if you wanted to plug this stuff into a non-PAM using single sign-on server, you know, go for it.

288
00:42:23,280 --> 00:42:33,700
Right now, hints are only hooked up for blacklist violations, but the other types should be doable without a problem too.

289
00:42:34,260 --> 00:42:43,020
Now, I'm not going to do a live demo, but I'm going to show some examples of how this works in practice on a Linux box.

290
00:42:43,460 --> 00:42:50,440
So, you install the PAM library and you modify your PAM.d settings.

291
00:42:50,440 --> 00:43:01,420
And we have readmes and examples for the different distributions that we supported and tested it on, but you can also roll your own custom, you know, PAM settings.

292
00:43:01,960 --> 00:43:13,760
So, you do a thing to turn on audit mode, you do a thing to turn on blacklist or minlev or maxuse or any combination thereof, and you can also enable the hint level.

293
00:43:14,260 --> 00:43:24,440
So again, maxuse requires that audit be turned on, but the other enforcement modes don't require audit to be enabled.

294
00:43:26,060 --> 00:43:29,920
So, what's it look like when things happen?

295
00:43:29,920 --> 00:43:46,680
Well, because this is sort of, you know, because this is a beta, we're verbose, although we don't include secrets in the output, but we're verbose even on successful, even in the case of success, we log a bunch of info about the fact that we just accepted a password change.

296
00:43:47,340 --> 00:43:56,980
A failure will tell the user that it failed a specific check, the minlev check in this case, but it won't tell them anything else.

297
00:43:56,980 --> 00:43:58,460
It won't tell them use this one instead.

298
00:43:58,460 --> 00:44:09,880
It won't say there's already one user and minlev is set to, or sorry, it won't tell them that, you know, how to modify their candidate.

299
00:44:09,880 --> 00:44:15,640
It'll just tell them, you know, they failed and we log that.

300
00:44:16,940 --> 00:44:31,760
And then a maxuse failure, where in this case minlev was not being, was not turned on, so users were allowed to choose any new password they want, any new topology they wanted, as long as it wasn't in use by somebody.

301
00:44:31,760 --> 00:44:38,920
Well, it was in use by them, therefore they can't reuse the same one, but they also can't reuse the same topology as their neighbor.

302
00:44:40,140 --> 00:44:41,660
And we log that.

303
00:44:42,180 --> 00:44:47,160
But again, we don't give anything else about, you know, give away anything else.

304
00:44:48,740 --> 00:44:52,860
Now, showing a little bit of what some of the hint level stuff.

305
00:44:56,550 --> 00:45:06,830
You can, if you want, look at the topology of the password that they supplied and say, that's a topology that we're not going to allow.

306
00:45:08,890 --> 00:45:12,990
Let's figure out what a change, what change would be viable.

307
00:45:12,990 --> 00:45:19,950
And the what change would be viable is basically randomly selected at password change time.

308
00:45:19,970 --> 00:45:24,950
By the engine, it says, okay, this topology they asked for is not allowed.

309
00:45:25,090 --> 00:45:28,190
What are the neighbors of this topology that are allowed?

310
00:45:28,190 --> 00:45:34,650
I'm going to pick one of those at random and then suggest an edit that would land the user in the new allowed topology.

311
00:45:34,650 --> 00:45:41,030
Now, funny enough, what it's suggesting here is actually a topology that wouldn't be great on its own.

312
00:45:41,190 --> 00:45:55,670
But for instance, maybe the organization's minimum password length is such that, you know, by making this longer, they'll end up being an outlier that way, because most users won't make their password any longer than they need to.

313
00:45:57,550 --> 00:45:59,690
You jack up the hint level one more.

314
00:46:01,950 --> 00:46:18,950
And now we'll actually show them where, you know, drawing on their existing password here, you know, point at their, excuse me, point at the spot in their existing password and say, put a, put a this here, put a that there.

315
00:46:20,550 --> 00:46:25,850
And then even more, we can suggest specific things.

316
00:46:29,280 --> 00:46:37,220
You can say, you know, here, try replacing this with a that and try inserting a this here.

317
00:46:37,940 --> 00:46:40,460
And your password is going to end up as this.

318
00:46:41,300 --> 00:46:50,920
You know, classically and back in the day, nobody ever suggests echoing plain text back to the human.

319
00:46:51,540 --> 00:46:58,760
But it turns, you know, there are actually use cases and scenarios where that's reasonable, or at least where it's reasonable to let the user choose.

320
00:46:58,760 --> 00:47:08,440
That's why a lot of, you know, web apps these days have a little button you can click or hold to show, to reveal rather than always make it opaque.

321
00:47:08,440 --> 00:47:09,860
And it's always just a trade-off.

322
00:47:09,860 --> 00:47:13,480
So if it's right for your organization, it's right for your organization.

323
00:47:13,480 --> 00:47:17,220
I'm not going to judge you until I come and pen test it and own you, and then I'll judge you.

324
00:47:18,780 --> 00:47:21,060
So what's next for the Pathwell project?

325
00:47:21,840 --> 00:47:25,340
Well, like I said, hints are only implemented for one of the modes.

326
00:47:25,340 --> 00:47:31,340
So easily, it's easy to say we should just go ahead and add hint support for the other modes.

327
00:47:32,820 --> 00:47:34,020
More platforms.

328
00:47:35,180 --> 00:47:39,160
The working implementation, like I said, is Linux, PAM.

329
00:47:40,220 --> 00:47:50,320
But the bigger organizations, places where this is going to be more useful, are going to be running either AD or some other kind of large single sign-on platform.

330
00:47:51,220 --> 00:47:59,760
If a vendor of one of those platforms wants to work on making their product better than all other products in the universe, come talk to us.

331
00:48:00,740 --> 00:48:07,740
The other thing, too, is we can easily come up with more ways we could improve things, more enforcement options.

332
00:48:10,500 --> 00:48:25,160
So first of all, this is highly focused on one specific, very successful, but it's still only one specific aspect of password cracking, which is the mask attack.

333
00:48:25,160 --> 00:48:40,120
So are there specific things we could learn from other highly successful password crack methodologies which we could, in turn, turn into defensive enforcement, dynamic strength enforcement at password change time?

334
00:48:40,120 --> 00:48:45,880
Say, well, I know that that thing you just tasked for is going to fall victim to this specific attack.

335
00:48:45,880 --> 00:48:52,700
We can compensate for that attack pretty easily and not allow you to make that requested password change.

336
00:48:54,840 --> 00:49:02,380
Now, an easier, more straightforward thing would be, hey, we could easily do regular expression support.

337
00:49:02,380 --> 00:49:07,600
Right now, our blacklists are basically just the masks tokenized into a machine format.

338
00:49:07,600 --> 00:49:10,460
But basically, right now, we just have a list of masks.

339
00:49:10,600 --> 00:49:15,780
We could enforce RegExes, too.

340
00:49:15,820 --> 00:49:24,400
So you can make a RegEx that would disallow a huge variety of different ways to say the word DefCon in your password all at once.

341
00:49:24,500 --> 00:49:28,880
And do that with, you know, do that with whatever your company name is.

342
00:49:28,880 --> 00:49:39,300
Exactly the word list that you find is the top most common word in your organization's passwords, because you do regular password audits, because you're a smart customer of ours.

343
00:49:39,300 --> 00:49:50,940
You could say, okay, well, my company name and my city name and my sports team name, all of those and every variation that fits into, you know, would match these RegExes, I'm going to disallow.

344
00:49:50,940 --> 00:49:59,080
And now, you've taken away not one blacklisted password or 10 blacklisted passwords, but millions of terrible passwords all at once.

345
00:50:00,500 --> 00:50:04,420
And then, if this did get adopted, what would attackers do next?

346
00:50:04,420 --> 00:50:07,940
And what would we need to do to adapt to that?

347
00:50:09,400 --> 00:50:11,200
So that's pretty much it.

348
00:50:11,300 --> 00:50:21,380
I'll take questions and I'll first, I'll scroll back to look for questions, but then I'll take more and I'll be around and in Discord the rest of the event.