start	end	text
5330	12050	I'm watching myself on the stream. There we go. So, hi everybody. I'm Hank Leininger, a co-worker
12050	17890	and fellow organizer of some of the events like the Bachelor Village and the Crack Me If You Can
17890	26250	contest. So, I'm going to give a talk on a defensive technique and technology and open
26250	30950	source tool that we ended up developing after sitting around thinking about all these interesting
30950	37310	all these ways that we can make password cracking easier. We asked ourselves, okay, well,
37310	40270	can we turn those into ways to make password cracking harder?
41330	46170	The deal I didn't watch is we're going to learn from successful attacks
46170	51370	and use that to inform us of how to make better defenses.
52570	59230	Just a little about me. I came up wearing a sysadmin hat and, you know, got into security
59230	64370	that way. Still enjoy building stuff about as much as I enjoy breaking them.
64910	73190	And, yeah, I, you know, sometimes do talks and build things. And, PathWell, the topic of this
73190	82870	talk. Like I said, it came sort of as just a, you know, brainstormed idea, but my co-workers
83590	88350	actually turned it into running code that we released. So, kudos to them.
89230	96070	So, the audience probably includes people that can't spell hashcat and people who wrote hashcat.
96550	103810	So, I'm going to give a very oversimplified overview of a particular kind of cracking
103810	109590	technique for the sake of people for whom this is not second nature. And those of you who
109590	114190	know that I'm oversimplifying, don't at me, bro.
115750	122450	So, we have a bunch of classic defenses used for password cracking. I got to keep in mind that
122450	131710	the slides update way slower than I do. All of these standard old ways that we try to make passwords
131710	138030	stronger, yeah, they basically don't work. There's a bunch of talks that go into a lot more detail
138030	149070	than I'm going to, but password complexity rules, they helped a little when they were
149630	156430	newly enforced, but it turns out humans make very similar decisions in the face of similar
156430	162590	policies. And password crackers have figured out the way humans respond to being given certain
162590	169450	rules. And we can guess where everybody's going to end up. As soon as we know the password policy
169450	174430	of a company, we can guess what a lot of those users passwords are going to look like. And if
174430	180490	we know what their passwords were a year ago, and we know their rotation requirements, we can
180490	188890	probably guess what they are today. Just to illustrate some examples, I want to throw some
188890	195170	numbers up here, which are rough. Again, don't at me. But suppose you built yourself a budget
195170	200430	password cracking rig, and congratulations, you can exhaust the entire eight character key space
200430	207930	in a day or under a day. But once password links get up to 9, 10, 11 characters, that becomes
207930	216390	infeasible. However, nobody actually tries to brute force the entire key space. We'll figure out
216390	222110	what's the most relevant or bang for the buck places to spend our compute time.
224410	231790	So the math and the proportions still apply, but we're not going after the entire key space. We're
231790	239670	going after the most relevant tiny slice of the password key space. So one way to
239670	247850	divide up that key space is what Hashcat calls mask attacks, where you say, in this character
247850	252070	position, it's going to be an uppercase letter, and I want you to try every uppercase letter,
252070	256630	and in this position, I want you to try every number, and so on. And usually you don't do this
256630	261330	for the entire password. You do it for, I want to take a dictionary word and then tack this pattern
261330	267950	onto the end of it, or I want to take a dictionary word and apply rules that morph it in these ways
267950	277830	in these positions. So again, just for the sake of figuring out how to discuss this and do the math,
278510	285190	we'll use this way of looking at it in this notation. So suppose you wanted to try every
285190	294370	possible password of a specific mask. And so the math that I've done here is,
294950	302170	if we have four different character classes, uppercase letters, lowercase letters, numbers,
302170	308810	and special characters, each position of the password could be one of those four. So essentially,
308810	318870	the password key space might be 95 to the 8th, but the topology key space is 4 to the 8th.
319470	327530	And if we have an 11 character, there's 4 to the 11th different topologies.
327530	333350	If we pick the single topology of uppercase number, lowercase, lowercase, lowercase,
333350	340090	whatever, number, number, special, we multiply out the possibilities in each of those positions.
340090	345290	And we say to exhaust that entirely, which again, we would actually combine that with
346090	350950	word lists or other things, so that we didn't have to blindly guess, we would guess the most
350950	356690	frequent or the most likely ones. In any case, if you did want to exhaust the whole thing,
356690	366050	there would be 265 trillion possible combinations. And that hypothetical cheapo cracking box that
366730	370430	would be totally infeasible to try to reinforce the entire key space
370430	373650	could do that one topology in about half an hour.
375870	381220	So the question we have to ask for the sort of evaluating the effectiveness of
383510	390770	hash mask based attacks is, do users bias towards specific
391530	398930	math pattern or specific topologies? If we could guess which patterns were overused by users,
399360	404830	then we would focus our attacks just on those. And we wouldn't have to, we wouldn't have to worry
404830	410510	about 99.99% of the key space. We would only have to worry about the parts of the key space where
410510	416670	the users are all clustered. And again, we would actually combine this with other smarts.
416670	420070	So in actual fact, our work would be even less.
421830	426110	So at our, at our company, at our day job, we do a lot of password audits,
426110	430470	both regular routine recurring ones and one-offs when we do a pen test.
430470	433030	So we have a whole bunch of data to look at.
434710	440570	Spoiler alert. Yes, of course users cluster into common topologies. That's why mask attacks are
440570	446270	worth doing. But we wanted to get some science and some numbers behind that. So we analyzed
447510	453430	the results of having cracked high percentages of a number of different organizations.
455450	461210	The first case study I'm going to throw out numbers of, we cracked, you know, around over
461210	469870	99% of current and historical hashes. And then we broke the, we attacked them not with a mask
469870	474150	centric focus. We attacked them with all our regular techniques, but then we did the crunching
474150	478250	in the math and we said, okay, how many different topologies were in here and what were the most
478250	486570	frequent and how frequent were they? Out of those quarter million different logins and hashes,
486570	496610	there were only around 7,000 unique topologies in use. And over 10% of the population used
498170	503590	each of the two most popular, actually three of the three most popular topologies.
504990	511670	So if we knew nothing about this organization whatsoever, other than that uppercase lower,
511670	516130	lower, lower, lower number number was going to be highly successful, we would crack over 10%
516130	524130	of their population without a second thought. And if we did, if we did all the top five, we would
524130	530850	have gotten almost half the company. If we did the top 100, which is still a tiny slice of the
530850	537970	overall key space, we would have gotten 85% of all hashes. And by the way, you can also determine,
537970	542390	you can discern from the relationship between the number one most popular and the number two most
542390	553170	popular and the number three and four, sorry, three and five, that this organization made
553170	558610	their password policy stronger sometime in the history of the dump that we have. Good for them,
558610	564650	stronger password policy. No, totally worthless because all their users did was made the word
564650	571310	inside just one letter longer and added another lowercase to that run. So trivial for us to
571310	581030	figure that out and go after. Now this is a graphical depiction of how frequent the most
581030	586230	frequent topologies were. Pay no attention to the labels on the x-axis. They don't mean anything
586230	592510	other than the unique identifier that we assigned to each particular topology. The point being,
592510	597350	the most, the few most popular topologies, the ones that we've crowded on, you know, we've
597350	603530	lined up on the left-hand side of the graph, were, you know, 10% or more of the population. And then
603530	610430	it tailed off very, very quickly and steeply. So there were some users who were indeed special
610430	615730	snowflakes, but they were like a handful of them way off to the right side of the graph.
616270	622390	They don't help the organization as a whole stay safe because the people on the left-hand side that
622390	629590	are all grouped together, they're easy prey. No other organization, kind of a similar story,
629590	635170	slightly larger hash pool, slightly lower crack percentage at the time we did this crunching,
635170	642470	but still well over 90%. So we were confident that the data that we were, the conclusions we
642470	646990	were going to draw from this data were valid. By the way, to preempt a question that I would ask
646990	653510	if I was watching this presentation, all of the subsequent stuff is based on number of cracks
653510	658450	compared to total population, not number of cracks compared to total number of cracks.
658450	667370	For instance, when I say that 19,000 people using or hashes using that one topology is 4.3%,
667370	677170	it's 4.3% of 449,000, not 4.3% of 419,000 that we were successful at. We don't know what the
677170	683990	30,000 were that we didn't crack, but we know what percentage of the total the ones we did crack are.
686560	694340	So in this organization, the numbers aren't as bad, but it's still a very significant relationship.
694340	701020	And it's also, once again, the case that somewhere embodied in the password history
701020	706260	that we captured, they changed their policies to make them stronger. But the way people responded
706260	713220	to it was, oops, was just to add another special, added another character at the end, which was a
713220	718740	special. Because they went from requiring eight characters, three of four, to requiring nine
718740	722880	characters, four of four. So users are just like, oh, okay, I'm gonna put an exclamation point at
722880	731900	the end. Once again, didn't stop us, you know, from cracking the new ones. This is the graph
731900	738680	for that organization. It's not nearly as bad and ugly, but it is still bad and ugly.
742440	749540	So we did this same kind of math across eight or so different large data compilations. We
749540	754840	discarded anything that was too small to be, you know, we didn't want a single
757000	765020	outlier to skew the overall numbers too much. And we also limited it to ones that we had
765020	771540	cracked a substantial portion, over 90%. Again, so that the conclusions we were able to draw
771680	779480	were sort of statistically, you know, valid for the population, knowing whatever the caveats,
779480	788380	you know, you had to take into account. This graphic is all of the histograms for each of
788380	797560	those organizations, not sorted by what's popular for them, but basically stacking on top of each
797560	805360	other, so that we can see clear patterns occur. This very first topology on the list, it was
805360	812180	popular in all five of the organizations, or all eight that are included in this data set.
812180	816180	Same thing, you know, the number three one was pretty popular. The number five one was hugely
816180	823660	popular across everybody. The only organization that was substantially different from all the
823660	829340	others is the one that was graphed in cyan or light blue here, where they're a huge false spike
829340	834780	and nobody else is a huge spike in that area. This is a big enough anomaly we dug in to figure out
834780	842460	why, and it's because that particular organization had a default password that was so commonly used
842460	847840	and still used by all their users, by a huge percentage of their users, that it threw off
847840	849760	all the rest of the numbers.
852040	857160	And it was a specific outlier just for them. I don't even remember what it was, but imagine it
857160	863040	was, you know, one change me, and it was a number one, and then all lowercase. And even when people
863040	869440	changed their password away from one change me, they made it two change me, or three change it.
869440	873600	And so their topology was exactly the same as the original password was.
874300	881600	Once you exclude that one data point, we see there's a huge commonality in which topologies
881600	888760	are super common across industries. And these are companies in different sectors. They are,
888760	894760	for the most part, US-centric. Some of them are global, but the majority of their user population
894760	899560	was still English speakers. So that is one caveat. It's very possible that somebody with alternate
899560	905960	language sets that users gravitate towards would look somewhat different. But if you knew
905960	910880	nothing at all about a company other than that it had a substantial presence in the United States,
910880	917320	take the top five common topologies on this list, attack those, and you're going to get tons of
917320	925060	users. And as a defender, this is terrible, because even in the strength of what we think
925060	929800	of as good password strength policies, we know our users are going to land this way,
929800	932460	and attackers are going to come after them and hunt them down and kill them.
933920	939280	So just to recap the kind of things that all this data crunching told us to confirm our suspicion
939280	946840	about the problem and where we ought to try to find a way to improve the situation.
949710	954770	Users pick the lowest competent denominator. There's specific things that they commonly do
954770	961090	when told that the password policy is getting stronger. And those behaviors, although there
961090	967750	are absolutely smart ways to attack an organization specific to that organization, go after word lists
967750	973190	for their industry, go after the proper names of things in their hometown and sport, you know,
973190	978910	sports teams and location names and blah, blah, blah. Still, these trends are going to be common
980230	983110	no matter who and where the company is.
985130	990670	And complexity rules just don't help, not nearly as much as we think they do anyway.
993310	1000110	By the way, another way to think about this in the COVID-19 era is users are not social distancing
1000110	1008490	their passwords. To graphically depict what having 12% of your user population
1009110	1015050	landing in a single topology means, if you were to imagine the land area of the...
1063140	1065660	All right, I should be back. Sorry about that.
1066940	1073420	So, if we were to imagine the entire land area of the United States as being the possible
1074080	1077880	password key space that users could pick from,
1078460	1084780	13% of all users choose to live together in a land area smaller than Manhattan.
1085220	1088840	And what's worse is when you tell users to change their password,
1088840	1093920	they don't go far. They just move a couple doors down or maybe one block away.
1094120	1098140	So, any attacker knows they don't have to go far to hunt them down.
1100540	1108780	And another thing about this is it applies even to much stronger password policies out of the box.
1110120	1115580	We discussed this with some of our friends that work in places where... and this was going back
1115580	1121640	to 2010. They had rules like you have to use a 15-character password and it has to have minimum
1121640	1127240	two of everything. And they were like, so how strong is that really? And we said, well,
1127880	1134200	it's really strong if you're not a smart attacker. But if you were a smart attacker and used,
1134200	1141880	among other things, mask-based attacks targeting the most common topologies, you would have
1144200	1148460	painfully... you would have a surprisingly good success rate.
1151890	1157470	If you were looking at a large organization with lots of users and password histories,
1158450	1163650	you would still likely be able... and you picked the topology that had the most users in it,
1163650	1167930	you would likely still succeed in cracking a password roughly once every 12 hours
1170730	1177390	for however many millions of years. But you don't need more than a few to get you started.
1180850	1188870	All right. So, that's kind of the foundational concept that led to what I'm going to talk about
1188870	1196930	next. So, it became clear we need new defenses. We need new ways to make things harder.
1199570	1203210	The rules that we have now aren't terrible, but they're not enough.
1204110	1208030	And one of the worst things we need... one of the strongest things we need to do is figure out how
1208030	1212970	to keep users from all congregating in the same place. No matter what rules we impose on them,
1212970	1216810	human nature says the majority of those users are going to cluster in a few
1218630	1226770	new places, which can still be predicted or discovered by the attacker. So, at a high level,
1226770	1233010	what are some things we could do? We could blacklist topologies that we know are a problem,
1233930	1239890	where we know or predict users are going to land. And not just blacklist individual passwords,
1239890	1246590	but blacklist the topologies, the shapes of those passwords. Nobody is ever allowed, again,
1246590	1249850	to have a password that's an uppercase letter followed by a bunch of lowercase,
1249850	1255730	followed by a couple of numbers, followed by a special. Just can't happen. Another thing we can
1255730	1262490	do is require a minimum change distance between where your current password is and where the new
1262490	1267970	one is that you want to go to. So, whatever words you're using, if you're using a three-letter word
1267970	1271810	and a four-letter word with the first letters capitalized, the second letters replaced with
1271810	1277790	numbers, and a special character in between, you can't use that exact same pattern on your
1277790	1287270	next password change. And also, don't allow your users to congregate on whatever topology they
1287270	1293690	choose to congregate on. This is a term that we didn't know when we were thinking about this
1293690	1299990	early, but which is becoming one of the ways to describe this part, is dynamic password strength
1299990	1306590	enforcement, meaning the password strength or the password policies you enforce are adaptive
1306590	1315130	based on what your user population is doing. There's two big costs to this, which are key
1315130	1324720	space reduction and user rebellion. I'll talk more about those in a bit. So first, what do I mean by
1324720	1332100	blacklisting? It's not that complicated. We figure out what the most popular topologies are, usually
1332700	1340200	for a given policy. Like, if your policy is 10 characters or more, it doesn't mean, it's not
1340200	1345680	interesting to figure out what the most popular eight and nine character topologies are.
1345900	1353100	But, and similarly, if you require four of four, then we don't care about blacklisting topologies
1353100	1361640	that are three of four or two of four. By the way, whatever list you come up with as
1361640	1367300	the best ones to blacklist, are also the best ones to start with when you're a cracker, you know, a
1367300	1374520	patchwork cracker, and nobody's enforcing pathwell yet. So we published what was our working set at
1374520	1379520	the time, back in 2014. We could, you know, we and a bunch of others can probably contribute
1380240	1386800	updated data by now. But we also, with just about everything we figure out and publish,
1386800	1392100	we figure out, we assume bad actors have already figured these things out before we started.
1392220	1397200	That's one of the reasons that CoreLogic started the password, the Crack PC Can contest back in
1397200	1405720	2010, because we figured bad actors were already figuring out and sharing, you know, password
1405720	1410040	cracking tricks. And we wanted to bring more of that discussion out into the open for defenders
1410040	1419470	and researchers to be aware of too. So what is the effectiveness of blacklisting?
1420050	1426010	Well, if the attackers have figured, follow these exact techniques, and they go after,
1426010	1430910	they use a top-end approach of targeting the topologies that are most likely to be successful,
1430910	1435590	then when we take those top ones away, they're going to start, they're going to get zero cracks
1435590	1440810	in their early, in their initial pass. Instead of getting 25% of the organization in minutes,
1440810	1447770	they're going to get zero in the first hours and wonder what's up. Of course, once attackers figure
1447770	1454590	out what we're doing, and once they're able to figure out what users do next, then maybe we're
1454590	1461010	just pushing the problem around. You know, we blacklist these 100 most popular topologies,
1461010	1466190	and now users are going to congregate in 100 different ones, and it's just chicken and the egg,
1466190	1471270	or not chicken and the egg, but it's an arms race. We just, you know, go back and forth, maybe.
1474170	1479710	The next thing we can do, which is starting to get more adaptive, is a minimum topology
1479710	1488350	change at password change time. So without any kind of enforcement of topology change,
1488530	1492550	a user who just increments a number in their password is a perfectly accepted new password.
1495410	1500050	And similarly, even once we're doing that, even if we enforce the thing that says, hey,
1500050	1505950	you can't use the same topology that you did in your previous password, they're probably going
1505950	1514170	to make the smallest change that constitutes a topology change, such as pick a random letter
1514170	1519690	that was uppercase and flip it to lower, or pick a lower and flip it to upper. That would pass
1519690	1526830	the test. But it would still be lower down on an attacker's list than incrementing a number,
1526830	1533730	or possibly incrementing a letter. And more importantly, if we say,
1533730	1540250	if we say, well, let's figure out how can we measure the difference, the distance between
1540250	1548010	one password and another, and then what's a minimum distance that we want to enforce?
1551300	1559000	So, one of our people who is, well, way more educated than I am in the computer science realm
1559000	1566300	said, oh, that's Levenstein distance. And I said, what's that? It was what I wanted without knowing
1566300	1573480	it. It's a science, it's a way to measure the distance between two strings. How many edits,
1573480	1588460	how many inserts, or removals, or increments, or whatever did, oops, yep. So,
1591580	1598940	so for a strip, just for string changes, you measure the Levenstein distance between two
1598940	1604140	strings by looking at how many characters were changed, added, removed.
1605580	1611660	For topologies, we can do much the same thing. But when we, so when we look at
1613000	1618280	these couple of hypothetical password changes, if you just, if you keep all of the character
1618280	1624380	types the same, and you just increment one of them, or decrement, your topology's Levenstein
1624380	1630920	distance change is zero. But if you change the character class of one of the positions,
1630920	1637600	then you've successfully, you know, moved your topology from one to another.
1639340	1646380	And obviously, if you combine more than one thing at a time, you may or may not,
1646380	1651040	you know, your edit distance of the string and your Levenstein distance of your topology
1651040	1656760	may be different. And if you go about, you know, making multiple changes at once,
1656760	1661200	then it's going to be, it's not going to be the very next thing the attacker tries.
1661200	1665940	When they learn that your password used to be password 20 exclamation point,
1665940	1673020	passwords 20 exclamation point won't be the first thing they try. It might be the 10th.
1673020	1678180	The, you know, more interesting if you change more positions throughout the string.
1680260	1686040	And everything, every time you make a topology change, you multiply out the number of different
1686040	1693080	paths the attacker has to go down in order to try to find you. Okay, so this still isn't really
1693080	1699800	where leveling. Where leveling is, you know, comes from, at least I borrowed the term from
1699800	1708380	the way things like solid state disks, SSDs, try to spread their writes out across all of the
1708380	1712180	different memory cells before they come back to one that was previously written to and write to
1712180	1718420	it again. So in this case, we want to take all these users who've bunched up in specific buckets
1718420	1726160	of a specific topology and spread them out. The most ideally where leveled population of user
1726160	1733740	passwords would have on average, you know, one or less users per bucket, or at least
1734460	1737940	no more users in any particular bucket than any other.
1739900	1749360	That way, if an attacker tries to pick any random topology there, or rather, any topology that they
1749360	1754560	know humans are likely to gravitate towards, they'll get few, if any, cracks instead of,
1754560	1764200	oh, 5% of your users landed on that topology. So we have to think about what are the impacts
1764200	1770500	to an attacker of using where leveling effectively and uniformly. Now,
1770500	1774360	there are downsides to doing it too, and I'll get to those in a second. But
1776580	1783880	if the attacker is used to being able to target that first or the first top five topologies and
1783880	1791480	get, you know, 10% of users per topology, 50% of your entire population in just, you know,
1791480	1800160	10 topologies or less, if users were spread completely out, then you would end up with
1800160	1804980	something like six orders of magnitude more work to get the same number of cracks, or
1805820	1813540	six orders of magnitude fewer cracks using the same amount of guessing time. Now, in reality,
1813540	1820420	it's not going to be that good. And it could be even worse. Suppose the attacker knew somehow
1821120	1827120	exactly which topologies were in use by within your organization, then they could target just
1827120	1833400	those topologies and ignore all the ones that aren't in use. However, because we know that
1833400	1838340	their success rate in any given topology is now minimized, it's controlled, there's not going to
1838340	1844720	be more than one or more than the number of topologies divided by your number of users
1845460	1853440	in that particular topology, their success rate still drops by two to three orders of magnitude.
1853740	1858100	In the realistic case, where users spread out, but they're not, it's not like you're originally
1858100	1861640	assigning them a topology, you may as well assign them a password if that was the case,
1861640	1867700	and that's going to be terrible, and everyone will kill you. But in the realistic case,
1867700	1872900	you're probably looking at a four to five orders of magnitude change in work factor.
1873540	1879960	And again, by that, I mean, surprisingly to us, it works out more or less reflexively. If you say,
1880480	1884740	I used to spend this many hours and crack this many thousand passwords,
1884740	1890140	I want to spend that same number of hours and see how many passwords I crack, you will crack
1891020	1896400	one ten thousandth or so of the passwords you used to do in the same amount of time.
1896620	1902660	And at the same, by the same token, if you say, I used to crack this many thousands of passwords,
1902660	1907220	I want to crack that same percentage or that same number, no matter how long it takes,
1907220	1912120	it's going to take you 10,000 to 100,000 times as long as it used to.
1914860	1923000	So what are some costs here? The one that first comes to sort of mathematical minds is,
1923000	1928240	I'm blacklisting parts of the keyspace. That means I'm making it so that there's fewer possible
1928240	1932900	passwords users could choose. Oh my God, we're reducing our keyspace. That helps the attacker
1932900	1938460	because now they have less ground to cover. But once you do the math, that actually
1939600	1947180	almost disappears into nothing. So for instance, if you are talking about eight character password
1947180	1954840	length, and in reality, there's almost no world and no hash in which eight character passwords
1954840	1959220	are okay anymore, but keep the math simple. Start with eight characters. We're going to have
1959220	1969060	48 possible different topologies, 64K, 65,000. If we blacklist the 100 most popular topologies,
1969720	1977820	we still, that's less than, that's only around 0.2% of the possible keyspace. And in fact,
1977820	1982160	if you are talking about nine character, 10 character, 11 character passwords,
1982160	1989800	the percentage of your keyspace that you're deleting by blacklisting is even smaller
1989800	1996120	if you're just talking about the top 100 out of a million instead of out of 65,000.
1997140	2004800	Now, the thing about forcing unique topology use, or at least spreading uniformly in among
2004800	2011560	the topologies that are not blacklisted, you actually do have a problem where any given
2011560	2018000	randomly selected topology is now more likely to have a password in it than before you impose
2018000	2028260	this rule. But if you think about the fact that what we're getting rid of by doing that is we're
2028260	2034480	getting rid of the property where an attacker can find one topology that has five to 10% of
2034480	2040400	your users, even if it's only that they can find a topology that has 1% of your users,
2040400	2049240	then the difference is still massively in our favor that this is an improvement for the defender.
2050980	2059020	Now, there's another possible downside. As Perth said, you're going to have, you know,
2059020	2065440	violence against your security staff. Well, maybe. On the one hand, any new control that
2065440	2072460	adds work for users is going to be resisted one way or the other. One of the ways, one of the
2072460	2078680	things that you could do about this is measure it, like do pilot testing. Carnegie Mellon actually
2078680	2087140	did a usability study on the difficulty of different stronger password strength enforcement,
2087140	2092660	and their results were, yes, it matters, but it's not as bad as you might think. That's the TLDR of
2092660	2100480	it. And that there are specific ways you can address it with user hinting. Now, what are ways
2100480	2104960	you could hint to user, hey, your password isn't strong enough. If you adjust it this way, it would
2104960	2111640	become strong enough. Or literally, your password is too weak, make it this instead. Those are
2111640	2116480	decisions that, you know, we can work our way through and different organizations can choose
2116480	2125200	differently. But it appears from CMU's research that some flavor of that can drastically
2126240	2130060	solve the user complaints. You're going to have cranky users,
2130060	2138540	but you're not going to have 100% of your users get cranky. And, yeah. Now,
2139180	2143420	we always have to remember that if we're going to give extra information to users at password
2143420	2151160	change time, that might somehow become user hints to the attacker.
2152740	2157140	Some of those things we've thought through and figured out ways to address.
2157140	2160820	Others are just going to be tradeoffs we're going to have to know that we're making.
2163820	2169300	And keep it in mind when an organization chooses, for instance, what kind of hint level to use,
2169300	2173440	they're going to have to keep that in mind. All right. So, enough of that. The code.
2174180	2180220	So, a few years back now, we released a PAM library, a PAM module that implements all this
2180220	2185400	stuff with optional controls to enable it and set the different parameters.
2188760	2198860	We developed and tested it on multiple Linuxes, Gen 2, Ubuntu, probably some of the Red Hats,
2198860	2202320	and I believe Solaris, but don't quote me on that.
2203480	2206960	And it basically implements all the things that I just talked about, and I'll
2206960	2210940	talk a little more about specifically how in a second.
2212020	2217680	We did patent the ideas here, but the code is AGPL. You can use it for free all you want.
2217680	2223820	The TLDR of the way the AGPL works is you can use this all you want for free stuff and open
2223820	2228740	source stuff. If you want to make money off of it or make custom modifications that you make money
2228740	2234780	off, then you have to talk to us because the AGPL license won't work. You'll have to ask us for a
2234780	2241920	dual license on something or other, but that's fine. We did it as a PAM library or PAM module
2241920	2248700	for Linux deployment, but with the thought that the API and the library could be used by other
2248700	2254000	things too, like an LDAP server that implements single sign-on or what have you.
2256300	2266180	Yes, so Perth is thinking about how attackers would adapt. I actually have that in here in a little bit too.
2267600	2272300	Okay, so what are the different modes that we implemented in the PathWell open source code?
2272300	2283100	So audit mode is simply the tracking of topologies that are used as users change their passwords.
2283100	2287140	When you start in an organization, you don't know other than by cracking their existing password
2287140	2292100	base, which is an option, especially for us, but it might not be an option for everybody. So you
2292100	2299640	could enable this to record topology use as it goes. Now, if you're going to keep a database
2299640	2303760	of all your users' topologies, you better consider that database pretty sensitive
2304400	2310280	and be careful with it. And because of implementation details in our proof of concept,
2310840	2315780	it's currently limited to tracking the topologies of characters up to 29
2315780	2320040	characters long, which, you know, ought to be enough for anybody.
2322200	2329720	Then there's enforcement modes, which actually impose different controls. The first and most
2329720	2333320	obvious one I'm going to talk about is blacklisting. And it's basically everything I said before that
2333320	2340220	blacklisting should do, it does. We distribute a standard list, a starter sort of list of
2340560	2347740	topologies to blacklist, but you could also add or modify your own. And again, I'll reiterate,
2347740	2355720	blacklisting itself is not enough as a permanent solution, but it does,
2357720	2364280	you know, help you be better and more resistant than other organizations that somebody might attack.
2365120	2369760	So, you know, you don't have to run faster than the bear,
2369760	2373720	you just have to run faster than the other, the other guy.
2374360	2380580	The next enforcement option is minlev, that's Levenstein distance, the minimum edit or the
2380580	2385920	minimum distance for the topology of the new password candidate versus what the previous one
2385920	2393340	was. This enforcement, actually, I should mention, neither blacklist mode nor minlev mode require
2393340	2400240	auditing to be turned on. So if you're, if you have heartburn about the idea of maintaining a
2400240	2406060	database of in-use topologies, and I don't blame you, then these features don't need that at all,
2406060	2412240	because they only care about what your new password request is in the case of blacklist,
2412240	2416440	or what your new password is compared to your old password in the case of minlev.
2416440	2421340	They don't care about what your new password is compared to the entire rest of your organization,
2422240	2428880	which is what max-use is about. Max-use, it allows you to say, I want to have a threshold,
2428880	2433040	any given topology bucket can only have one user, or can only have five users,
2433040	2436820	or whatever's the right number for the size of your organization.
2439920	2445280	And again, the point here is, you know, if the attacker, if you have successfully kept users
2445280	2453240	from clumping anywhere, or rather, if you want to prevent users from clumping anywhere, you use
2453240	2459560	this, and then a user setting their password can't set their password to be the same topology that
2459560	2466280	they or anybody else in your organization has used, or if not more than two have used, or whatever
2466280	2475920	your setting is. Now, it's called an enforcement, well, it's an option that matters in enforcement
2475920	2483240	mode, but it's not an enforcement, but rather a sort of, you know, that controls the user experience
2484680	2492460	if you want to give any hints. So, we did an experimental hint info level implementation,
2492460	2498260	partly to facilitate that kind of research that I talked about before, the user acceptance of
2498820	2502960	what's the user experience when I tell them this much information, as opposed to when I tell them
2502960	2513060	that. So, out of the box, PathWell doesn't give users any particular feedback or information,
2513060	2517160	doesn't tell them how they could make their password stronger, doesn't leak information
2517160	2522360	about the organization, doesn't give information to the screen that would be useful to somebody
2522360	2528300	shoulder surfing. But if you choose to, if it's right for your organization, you can turn up
2528300	2534740	hint levels. And this is supported by the backend API as well, not just by the PAM library. So,
2534740	2542640	if you wanted to plug this stuff into a non-PAM using single sign-on server, you know, go for it.
2543280	2550320	Right now, hints are only hooked up for blacklist violations, but the other types
2551120	2557360	should be doable without a problem too. Now, I'm not going to do a live demo, but I'm going to show
2557360	2567160	some examples of how this works in practice on a Linux box. So, you install the PAM library
2567900	2573980	and you modify your PAM.d settings. And we have readmes and examples for the different distributions
2573980	2581420	that we supported and tested it on, but you can also roll your own custom, you know, PAM settings.
2581960	2588780	So, you do a thing to turn on audit mode, you do a thing to turn on blacklist or minlev or maxuse
2588780	2595680	or any combination thereof, and you can also enable the hint level. So again,
2597780	2603580	maxuse requires that audit be turned on, but the other enforcement modes don't require audit to be
2603580	2612200	enabled. So, what's it look like when things happen? Well, because this is sort of, you know,
2612200	2618420	because this is a beta, we're verbose, although we don't include secrets in the output, but we're
2618420	2624680	verbose even on successful, even in the case of success, we log a bunch of info about the fact
2624680	2633480	that we just accepted a password change. A failure will tell the user that it failed a specific
2633480	2637480	check, the minlev check in this case, but it won't tell them anything else. It won't tell them
2637480	2643300	use this one instead. It won't say there's already one user and minlev is set to, or sorry,
2643300	2652100	it won't tell them that, you know, how to modify their candidate. It'll just tell them, you know,
2652100	2662800	they failed and we log that. And then a maxuse failure, where in this case minlev was not being,
2662800	2668920	was not turned on, so users were allowed to choose any new password they want, any new topology
2668920	2674000	they wanted, as long as it wasn't in use by somebody. Well, it was in use by them, therefore
2674560	2678920	they can't reuse the same one, but they also can't reuse the same topology as their neighbor.
2680140	2687160	And we log that. But again, we don't give anything else about, you know, give away anything else.
2688740	2698970	Now, showing a little bit of what some of the hint level stuff. You can, if you want,
2699750	2705450	look at the topology of the password that they supplied and say, that's a topology that we're
2705450	2713390	not going to allow. Let's figure out what a change, what change would be viable. And the
2713390	2719950	what change would be viable is basically randomly selected at password change time.
2719970	2724950	By the engine, it says, okay, this topology they asked for is not allowed.
2725090	2729390	What are the neighbors of this topology that are allowed? I'm going to pick one of those at random
2729390	2735670	and then suggest an edit that would land the user in the new allowed topology. Now, funny enough,
2735670	2741970	what it's suggesting here is actually a topology that wouldn't be great on its own. But for
2741970	2748790	instance, maybe the organization's minimum password length is such that, you know, by making this
2748790	2754410	longer, they'll end up being an outlier that way, because most users won't make their password any
2754410	2765550	longer than they need to. You jack up the hint level one more. And now we'll actually show them
2766130	2773870	where, you know, drawing on their existing password here, you know, point at their,
2773870	2777730	excuse me, point at the spot in their existing password and say, put a, put a this here,
2777730	2791140	put a that there. And then even more, we can suggest specific things. You can say, you know,
2792620	2797220	here, try replacing this with a that and try inserting a this here.
2797940	2803860	And your password is going to end up as this. You know, classically and back in the day,
2803860	2812660	nobody ever suggests echoing plain text back to the human. But it turns, you know, there are
2812660	2817840	actually use cases and scenarios where that's reasonable, or at least where it's reasonable to
2817840	2822900	let the user choose. That's why a lot of, you know, web apps these days have a little button
2822900	2829300	you can click or hold to show, to reveal rather than always make it opaque. And it's always just
2829420	2833840	a trade-off. So if it's right for your organization, it's right for your organization. I'm not going
2833840	2839780	to judge you until I come and pen test it and own you, and then I'll judge you. So what's next for
2839780	2845380	the Pathwell project? Well, like I said, hints are only implemented for one of the modes. So
2845380	2851340	easily, it's easy to say we should just go ahead and add hint support for the other modes.
2852820	2861560	More platforms. The working implementation, like I said, is Linux, PAM. But the bigger
2861560	2866300	organizations, places where this is going to be more useful, are going to be running either AD
2866300	2873200	or some other kind of large single sign-on platform. If a vendor of one of those platforms
2873200	2878580	wants to work on making their product better than all other products in the universe, come talk to
2878580	2886160	us. The other thing, too, is we can easily come up with more ways we could improve things, more
2886160	2899560	enforcement options. So first of all, this is highly focused on one specific, very successful,
2899560	2905360	but it's still only one specific aspect of password cracking, which is the mask attack. So
2905360	2911420	are there specific things we could learn from other highly successful password crack
2912400	2918160	methodologies which we could, in turn, turn into defensive enforcement, dynamic strength
2918160	2923400	enforcement at password change time? Say, well, I know that that thing you just tasked for is going
2923400	2928740	to fall victim to this specific attack. We can compensate for that attack pretty easily and not
2928740	2937400	allow you to make that requested password change. Now, an easier, more straightforward
2937400	2943100	thing would be, hey, we could easily do regular expression support. Right now, our blacklists
2943100	2948760	are basically just the masks tokenized into a machine format. But basically, right now,
2948760	2957240	we just have a list of masks. We could enforce RegExes, too. So you can make a RegEx that
2957240	2962260	would disallow a huge variety of different ways to say the word DefCon in your password
2962920	2969500	all at once. And do that with, you know, do that with whatever your company name is. Exactly the
2969500	2975700	word list that you find is the top most common word in your organization's passwords, because
2975700	2980820	you do regular password audits, because you're a smart customer of ours. You could say, okay, well,
2980820	2987380	my company name and my city name and my sports team name, all of those and every variation that
2987380	2992260	fits into, you know, would match these RegExes, I'm going to disallow. And now, you've taken away
2992260	2997940	not one blacklisted password or 10 blacklisted passwords, but millions of terrible passwords
2997940	3004420	all at once. And then, if this did get adopted, what would attackers do next?
3004420	3013300	And what would we need to do to adapt to that? So that's pretty much it. I'll take questions
3013300	3016740	and I'll first, I'll scroll back to look for questions,
3016740	3021380	but then I'll take more and I'll be around and in Discord the rest of the event.