WEBVTT 00:05.330 --> 00:07.170 I'm watching myself on the stream. 00:07.170 --> 00:08.070 There we go. 00:08.590 --> 00:09.450 So, hi everybody. 00:09.450 --> 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. 00:19.410 --> 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. 00:34.790 --> 00:40.270 We asked ourselves, okay, well, can we turn those into ways to make password cracking harder? 00:41.330 --> 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. 00:52.570 --> 00:54.710 Just a little about me. 00:54.930 --> 01:00.290 I came up wearing a sysadmin hat and, you know, got into security that way. 01:00.510 --> 01:04.370 Still enjoy building stuff about as much as I enjoy breaking them. 01:04.910 --> 01:09.770 And, yeah, I, you know, sometimes do talks and build things. 01:10.690 --> 01:14.110 And, PathWell, the topic of this talk. 01:15.730 --> 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. 01:26.670 --> 01:28.350 So, kudos to them. 01:29.230 --> 01:36.070 So, the audience probably includes people that can't spell hashcat and people who wrote hashcat. 01:36.550 --> 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. 01:48.430 --> 01:54.190 And those of you who know that I'm oversimplifying, don't at me, bro. 01:55.750 --> 02:00.310 So, we have a bunch of classic defenses used for password cracking. 02:00.910 --> 02:05.290 I got to keep in mind that the slides update way slower than I do. 02:07.150 --> 02:15.190 All of these standard old ways that we try to make passwords stronger, yeah, they basically don't work. 02:15.210 --> 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. 02:37.730 --> 02:43.230 And password crackers have figured out the way humans respond to being given certain rules. 02:43.570 --> 02:48.130 And we can guess where everybody's going to end up. 02:48.130 --> 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. 02:54.050 --> 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. 03:04.610 --> 03:10.810 Just to illustrate some examples, I want to throw some numbers up here, which are rough. 03:10.810 --> 03:12.150 Again, don't at me. 03:12.390 --> 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. 03:23.010 --> 03:29.030 But once password links get up to 9, 10, 11 characters, that becomes infeasible. 03:29.810 --> 03:35.110 However, nobody actually tries to brute force the entire key space. 03:35.330 --> 03:42.110 We'll figure out what's the most relevant or bang for the buck places to spend our compute time. 03:44.410 --> 03:51.570 So the math and the proportions still apply, but we're not going after the entire key space. 03:51.570 --> 03:57.910 We're going after the most relevant tiny slice of the password key space. 03:58.070 --> 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, 04:14.210 --> 04:15.410 and so on. 04:15.410 --> 04:17.690 And usually you don't do this for the entire password. 04:17.690 --> 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. 04:30.030 --> 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. 04:42.150 --> 04:50.810 So suppose you wanted to try every possible password of a specific mask. 04:51.350 --> 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. 05:07.630 --> 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. 05:19.470 --> 05:27.530 And if we have an 11 character, there's 4 to the 11th different topologies. 05:27.530 --> 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. 05:40.090 --> 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. 05:53.350 --> 06:01.710 In any case, if you did want to exhaust the whole thing, there would be 265 trillion possible combinations. 06:02.230 --> 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. 06:15.870 --> 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? 06:34.090 --> 06:42.190 If we could guess which patterns were overused by users, then we would focus our attacks just on those. 06:42.190 --> 06:47.270 And we wouldn't have to, we wouldn't have to worry about 99.99% of the key space. 06:47.270 --> 06:52.110 We would only have to worry about the parts of the key space where the users are all clustered. 06:52.870 --> 06:56.670 And again, we would actually combine this with other smarts. 06:56.670 --> 07:00.070 So in actual fact, our work would be even less. 07:01.830 --> 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. 07:10.470 --> 07:13.030 So we have a whole bunch of data to look at. 07:14.710 --> 07:15.750 Spoiler alert. 07:15.750 --> 07:19.210 Yes, of course users cluster into common topologies. 07:19.210 --> 07:21.770 That's why mask attacks are worth doing. 07:21.810 --> 07:24.770 But we wanted to get some science and some numbers behind that. 07:24.770 --> 07:33.430 So we analyzed the results of having cracked high percentages of a number of different organizations. 07:35.450 --> 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. 07:45.150 --> 07:50.770 And then we broke the, we attacked them not with a mask centric focus. 07:50.770 --> 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? 08:01.570 --> 08:10.810 Out of those quarter million different logins and hashes, there were only around 7,000 unique topologies in use. 08:11.610 --> 08:23.590 And over 10% of the population used each of the two most popular, actually three of the three most popular topologies. 08:24.990 --> 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. 08:41.610 --> 08:45.810 And if we did, if we did all the top five, we would have gotten almost half the company. 08:46.190 --> 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. 08:55.390 --> 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. 09:17.810 --> 09:20.290 Good for them, stronger password policy. 09:20.290 --> 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. 09:29.670 --> 09:33.890 So trivial for us to figure that out and go after. 09:35.290 --> 09:43.010 Now this is a graphical depiction of how frequent the most frequent topologies were. 09:43.070 --> 09:45.570 Pay no attention to the labels on the x-axis. 09:45.570 --> 09:50.710 They don't mean anything other than the unique identifier that we assigned to each particular topology. 09:50.710 --> 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. 10:03.130 --> 10:06.490 And then it tailed off very, very quickly and steeply. 10:06.490 --> 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. 10:16.270 --> 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. 10:26.870 --> 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%. 10:37.330 --> 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. 10:44.770 --> 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. 10:58.450 --> 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. 11:15.590 --> 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. 11:26.560 --> 11:34.340 So in this organization, the numbers aren't as bad, but it's still a very significant relationship. 11:34.340 --> 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. 11:44.600 --> 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. 11:54.720 --> 12:00.120 Because they went from requiring eight characters, three of four, to requiring nine characters, four of four. 12:00.120 --> 12:03.700 So users are just like, oh, okay, I'm gonna put an exclamation point at the end. 12:04.040 --> 12:09.380 Once again, didn't stop us, you know, from cracking the new ones. 12:10.460 --> 12:13.400 This is the graph for that organization. 12:13.400 --> 12:18.680 It's not nearly as bad and ugly, but it is still bad and ugly. 12:22.440 --> 12:29.400 So we did this same kind of math across eight or so different large data compilations. 12:29.400 --> 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. 12:40.480 --> 12:48.480 And we also limited it to ones that we had cracked a substantial portion, over 90%. 12:48.480 --> 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. 13:02.880 --> 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. 13:22.380 --> 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. 13:32.180 --> 13:35.020 Same thing, you know, the number three one was pretty popular. 13:35.020 --> 13:38.620 The number five one was hugely popular across everybody. 13:38.740 --> 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. 13:52.240 --> 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. 14:12.040 --> 14:14.800 And it was a specific outlier just for them. 14:14.800 --> 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. 14:22.380 --> 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. 14:29.440 --> 14:33.600 And so their topology was exactly the same as the original password was. 14:34.300 --> 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. 14:43.480 --> 14:47.700 And these are companies in different sectors. 14:47.700 --> 14:51.260 They are, for the most part, US-centric. 14:51.360 --> 14:56.300 Some of them are global, but the majority of their user population was still English speakers. 14:56.300 --> 14:57.800 So that is one caveat. 14:57.800 --> 15:05.020 It's very possible that somebody with alternate language sets that users gravitate towards would look somewhat different. 15:05.020 --> 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. 15:19.200 --> 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. 15:33.920 --> 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. 15:49.710 --> 15:51.910 Users pick the lowest competent denominator. 15:52.130 --> 15:57.730 There's specific things that they commonly do when told that the password policy is getting stronger. 15:58.470 --> 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, 16:15.050 --> 16:15.830 blah, blah. 16:16.170 --> 16:23.110 Still, these trends are going to be common no matter who and where the company is. 16:25.130 --> 16:30.670 And complexity rules just don't help, not nearly as much as we think they do anyway. 16:33.310 --> 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. 16:42.250 --> 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... 17:43.140 --> 17:44.600 All right, I should be back. 17:44.600 --> 17:45.660 Sorry about that. 17:46.940 --> 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. 18:05.220 --> 18:10.680 And what's worse is when you tell users to change their password, they don't go far. 18:10.680 --> 18:13.920 They just move a couple doors down or maybe one block away. 18:14.120 --> 18:18.140 So, any attacker knows they don't have to go far to hunt them down. 18:20.540 --> 18:28.780 And another thing about this is it applies even to much stronger password policies out of the box. 18:30.120 --> 18:37.040 We discussed this with some of our friends that work in places where... and this was going back to 2010. 18:37.160 --> 18:43.000 They had rules like you have to use a 15-character password and it has to have minimum two of everything. 18:43.080 --> 18:45.220 And they were like, so how strong is that really? 18:45.220 --> 18:50.700 And we said, well, it's really strong if you're not a smart attacker. 18:50.980 --> 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. 19:11.890 --> 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. 19:33.990 --> 19:37.390 But you don't need more than a few to get you started. 19:40.850 --> 19:41.690 All right. 19:41.690 --> 19:49.630 So, that's kind of the foundational concept that led to what I'm going to talk about next. 19:50.750 --> 19:54.670 So, it became clear we need new defenses. 19:54.670 --> 19:56.930 We need new ways to make things harder. 19:59.570 --> 20:03.210 The rules that we have now aren't terrible, but they're not enough. 20:04.110 --> 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. 20:10.790 --> 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. 20:24.610 --> 20:27.830 So, at a high level, what are some things we could do? 20:27.830 --> 20:37.370 We could blacklist topologies that we know are a problem, where we know or predict users are going to land. 20:37.370 --> 20:44.530 And not just blacklist individual passwords, but blacklist the topologies, the shapes of those passwords. 20:44.770 --> 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. 20:52.530 --> 20:53.890 Just can't happen. 20:54.790 --> 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. 21:04.550 --> 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. 21:20.810 --> 21:29.210 And also, don't allow your users to congregate on whatever topology they choose to congregate on. 21:29.910 --> 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. 21:51.890 --> 21:58.430 There's two big costs to this, which are key space reduction and user rebellion. 21:58.470 --> 22:01.050 I'll talk more about those in a bit. 22:03.240 --> 22:05.500 So first, what do I mean by blacklisting? 22:05.500 --> 22:07.200 It's not that complicated. 22:07.200 --> 22:15.180 We figure out what the most popular topologies are, usually for a given policy. 22:15.180 --> 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. 22:25.900 --> 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. 22:37.840 --> 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. 22:51.280 --> 22:55.800 So we published what was our working set at the time , back in 2014. 22:56.360 --> 23:02.100 We could, you know, we and a bunch of others can probably contribute updated data by now. 23:03.180 --> 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. 23:12.220 --> 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. 23:26.680 --> 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. 23:36.690 --> 23:39.470 So what is the effectiveness of blacklisting? 23:40.050 --> 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, 23:56.490 --> 23:58.110 in their initial pass. 23:58.110 --> 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. 24:05.810 --> 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. 24:16.330 --> 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. 24:28.290 --> 24:31.270 We just, you know, go back and forth, maybe. 24:34.170 --> 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. 24:42.210 --> 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. 24:55.410 --> 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, 25:16.470 --> 25:18.090 or pick a lower and flip it to upper. 25:18.470 --> 25:21.050 That would pass the test. 25:22.110 --> 25:29.050 But it would still be lower down on an attacker's list than incrementing a number, or possibly incrementing a letter. 25:29.390 --> 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? 25:51.300 --> 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. 26:01.480 --> 26:03.360 And I said, what's that? 26:03.940 --> 26:07.060 It was what I wanted without knowing it. 26:08.300 --> 26:12.560 It's a science, it's a way to measure the distance between two strings. 26:12.560 --> 26:24.940 How many edits, how many inserts, or removals, or increments, or whatever did, oops, yep. 26:27.560 --> 26:28.460 So, 26:31.580 --> 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. 26:45.580 --> 26:48.680 For topologies, we can do much the same thing. 26:49.420 --> 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. 27:06.780 --> 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. 27:19.340 --> 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. 27:32.820 --> 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. 27:41.200 --> 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. 27:50.920 --> 27:53.020 It might be the 10th. 27:53.020 --> 27:58.180 The, you know, more interesting if you change more positions throughout the string. 28:00.260 --> 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. 28:10.660 --> 28:14.340 Okay, so this still isn't really where leveling. 28:14.440 --> 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. 28:32.880 --> 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. 28:42.560 --> 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. 28:59.900 --> 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. 29:19.640 --> 29:29.840 So we have to think about what are the impacts to an attacker of using where leveling effectively and uniformly. 29:30.020 --> 29:34.120 Now, there are downsides to doing it too, and I'll get to those in a second. 29:34.240 --> 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, 30:04.640 --> 30:11.660 or six orders of magnitude fewer cracks using the same amount of guessing time. 30:11.820 --> 30:15.980 Now, in reality, it's not going to be that good. 30:15.980 --> 30:17.680 And it could be even worse. 30:17.740 --> 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. 30:31.520 --> 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. 30:53.740 --> 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. 31:06.040 --> 31:12.900 But in the realistic case, you're probably looking at a four to five orders of magnitude change in work factor. 31:13.540 --> 31:19.080 And again, by that, I mean, surprisingly to us, it works out more or less reflexively. 31:19.080 --> 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. 31:36.620 --> 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. 31:54.860 --> 31:57.380 So what are some costs here? 31:57.760 --> 32:05.160 The one that first comes to sort of mathematical minds is, I'm blacklisting parts of the keyspace. 32:05.160 --> 32:10.020 That means I'm making it so that there's fewer possible passwords users could choose. 32:10.020 --> 32:12.080 Oh my God, we're reducing our keyspace. 32:12.080 --> 32:15.600 That helps the attacker because now they have less ground to cover. 32:15.820 --> 32:21.960 But once you do the math, that actually almost disappears into nothing. 32:22.140 --> 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. 32:37.420 --> 32:38.480 Start with eight characters. 32:38.480 --> 32:45.140 We're going to have 48 possible different topologies, 64K, 65,000. 32:45.220 --> 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. 32:56.600 --> 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 33:15.440 --> 33:16.120 . 33:17.140 --> 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. 33:39.880 --> 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, 34:00.400 --> 34:09.240 then the difference is still massively in our favor that this is an improvement for the defender. 34:10.980 --> 34:15.340 Now, there's another possible downside. 34:15.520 --> 34:21.060 As Perth said, you're going to have, you know, violence against your security staff. 34:21.060 --> 34:22.280 Well, maybe. 34:23.340 --> 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. 34:30.920 --> 34:36.720 One of the ways, one of the things that you could do about this is measure it, like do pilot testing. 34:37.520 --> 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. 34:51.640 --> 34:53.020 That's the TLDR of it. 34:53.020 --> 34:56.660 And that there are specific ways you can address it with user hinting. 34:57.160 --> 35:03.400 Now, what are ways you could hint to user, hey, your password isn't strong enough. 35:03.500 --> 35:06.200 If you adjust it this way, it would become strong enough. 35:06.300 --> 35:10.300 Or literally, your password is too weak, make it this instead. 35:11.060 --> 35:17.480 Those are decisions that, you know, we can work our way through and different organizations can choose differently. 35:17.520 --> 35:28.380 But it appears from CMU's research that some flavor of that can drastically solve the user complaints. 35:28.380 --> 35:33.380 You're going to have cranky users, but you're not going to have 100% of your users get cranky. 35:34.380 --> 35:37.200 And, yeah. 35:37.640 --> 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. 35:52.740 --> 35:57.140 Some of those things we've thought through and figured out ways to address. 35:57.140 --> 36:00.820 Others are just going to be tradeoffs we're going to have to know that we're making. 36:03.820 --> 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. 36:11.360 --> 36:11.680 All right. 36:11.680 --> 36:12.600 So, enough of that. 36:12.600 --> 36:13.440 The code. 36:14.180 --> 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. 36:28.760 --> 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. 36:43.480 --> 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. 36:52.020 --> 36:55.700 We did patent the ideas here, but the code is AGPL. 36:55.700 --> 36:57.680 You can use it for free all you want. 36:57.680 --> 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. 37:04.560 --> 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. 37:13.380 --> 37:17.700 You'll have to ask us for a dual license on something or other, but that's fine. 37:18.800 --> 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. 37:36.300 --> 37:43.440 Yes, so Perth is thinking about how attackers would adapt. 37:43.440 --> 37:46.180 I actually have that in here in a little bit too. 37:47.600 --> 37:52.300 Okay, so what are the different modes that we implemented in the PathWell open source code? 37:52.300 --> 38:03.100 So audit mode is simply the tracking of topologies that are used as users change their passwords. 38:03.100 --> 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. 38:11.920 --> 38:17.180 So you could enable this to record topology use as it goes. 38:17.880 --> 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. 38:26.820 --> 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. 38:42.200 --> 38:48.380 Then there's enforcement modes, which actually impose different controls. 38:48.380 --> 38:51.480 The first and most obvious one I'm going to talk about is blacklisting. 38:51.480 --> 38:55.860 And it's basically everything I said before that blacklisting should do, it does. 38:55.940 --> 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. 39:05.960 --> 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. 39:25.120 --> 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. 39:34.360 --> 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. 39:47.420 --> 39:55.040 This enforcement, actually, I should mention, neither blacklist mode nor minlev mode require auditing to be turned on. 39:55.040 --> 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, 40:11.720 --> 40:16.180 or what your new password is compared to your old password in the case of minlev. 40:16.180 --> 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. 40:24.880 --> 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. 40:39.920 --> 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, 41:03.280 --> 41:07.900 or if not more than two have used, or whatever your setting is. 41:09.760 --> 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. 41:26.980 --> 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. 41:45.200 --> 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. 42:03.960 --> 42:09.400 But if you choose to, if it's right for your organization, you can turn up hint levels. 42:10.440 --> 42:14.460 And this is supported by the backend API as well, not just by the PAM library. 42:14.460 --> 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. 42:23.280 --> 42:33.700 Right now, hints are only hooked up for blacklist violations, but the other types should be doable without a problem too. 42:34.260 --> 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. 42:43.460 --> 42:50.440 So, you install the PAM library and you modify your PAM.d settings. 42:50.440 --> 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. 43:01.960 --> 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. 43:14.260 --> 43:24.440 So again, maxuse requires that audit be turned on, but the other enforcement modes don't require audit to be enabled. 43:26.060 --> 43:29.920 So, what's it look like when things happen? 43:29.920 --> 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. 43:47.340 --> 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. 43:56.980 --> 43:58.460 It won't tell them use this one instead. 43:58.460 --> 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. 44:09.880 --> 44:15.640 It'll just tell them, you know, they failed and we log that. 44:16.940 --> 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. 44:31.760 --> 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. 44:40.140 --> 44:41.660 And we log that. 44:42.180 --> 44:47.160 But again, we don't give anything else about, you know, give away anything else. 44:48.740 --> 44:52.860 Now, showing a little bit of what some of the hint level stuff. 44:56.550 --> 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. 45:08.890 --> 45:12.990 Let's figure out what a change, what change would be viable. 45:12.990 --> 45:19.950 And the what change would be viable is basically randomly selected at password change time. 45:19.970 --> 45:24.950 By the engine, it says, okay, this topology they asked for is not allowed. 45:25.090 --> 45:28.190 What are the neighbors of this topology that are allowed? 45:28.190 --> 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. 45:34.650 --> 45:41.030 Now, funny enough, what it's suggesting here is actually a topology that wouldn't be great on its own. 45:41.190 --> 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. 45:57.550 --> 45:59.690 You jack up the hint level one more. 46:01.950 --> 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. 46:20.550 --> 46:25.850 And then even more, we can suggest specific things. 46:29.280 --> 46:37.220 You can say, you know, here, try replacing this with a that and try inserting a this here. 46:37.940 --> 46:40.460 And your password is going to end up as this. 46:41.300 --> 46:50.920 You know, classically and back in the day, nobody ever suggests echoing plain text back to the human. 46:51.540 --> 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. 46:58.760 --> 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. 47:08.440 --> 47:09.860 And it's always just a trade-off. 47:09.860 --> 47:13.480 So if it's right for your organization, it's right for your organization. 47:13.480 --> 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. 47:18.780 --> 47:21.060 So what's next for the Pathwell project? 47:21.840 --> 47:25.340 Well, like I said, hints are only implemented for one of the modes. 47:25.340 --> 47:31.340 So easily, it's easy to say we should just go ahead and add hint support for the other modes. 47:32.820 --> 47:34.020 More platforms. 47:35.180 --> 47:39.160 The working implementation, like I said, is Linux, PAM. 47:40.220 --> 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. 47:51.220 --> 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. 48:00.740 --> 48:07.740 The other thing, too, is we can easily come up with more ways we could improve things, more enforcement options. 48:10.500 --> 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. 48:25.160 --> 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? 48:40.120 --> 48:45.880 Say, well, I know that that thing you just tasked for is going to fall victim to this specific attack. 48:45.880 --> 48:52.700 We can compensate for that attack pretty easily and not allow you to make that requested password change. 48:54.840 --> 49:02.380 Now, an easier, more straightforward thing would be, hey, we could easily do regular expression support. 49:02.380 --> 49:07.600 Right now, our blacklists are basically just the masks tokenized into a machine format. 49:07.600 --> 49:10.460 But basically, right now, we just have a list of masks. 49:10.600 --> 49:15.780 We could enforce RegExes, too. 49:15.820 --> 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. 49:24.500 --> 49:28.880 And do that with, you know, do that with whatever your company name is. 49:28.880 --> 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. 49:39.300 --> 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. 49:50.940 --> 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. 50:00.500 --> 50:04.420 And then, if this did get adopted, what would attackers do next? 50:04.420 --> 50:07.940 And what would we need to do to adapt to that? 50:09.400 --> 50:11.200 So that's pretty much it. 50:11.300 --> 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.