WEBVTT 00:01.690 --> 00:07.430 Hello, and welcome to Cracking Beyond 15 Characters for under $500. 00:07.750 --> 00:16.110 Some alternative titles for this talk were Greener Pastures Over the Computational Wall or Why XKCD Advice is Easy to Understand and Hard to Do. 00:16.210 --> 00:20.570 That last one was suggested by my management, and we'll talk more about that one later. 00:21.510 --> 00:23.010 Hi, I'm Travis Palmer. 00:23.010 --> 00:25.330 I'm also a nerd, so I go by the pseudonym tramco. 00:25.330 --> 00:29.390 I am an OSCP, OSCE, and GMOD, if those letters mean something to you. 00:29.390 --> 00:34.590 And as is traditional for speakers, a couple of my favorite hobbies outside of security are on the right. 00:34.810 --> 00:36.290 D&D, Arma 3, and BBC. 00:36.770 --> 00:38.430 Yes, again, I am a nerd. 00:38.670 --> 00:47.890 And these slides arguably have too much on them, so this is the point where I ditch my ugly mug so that we can happily reveal that picture from the Red Team Village last year. 00:48.290 --> 00:52.170 Yeah, let's just say that room was pretty tight. 00:52.170 --> 00:54.530 I'm glad we're not trying to do that again this year. 00:55.150 --> 00:58.350 Everybody would have COVID by now if we were trying to be doing this live. 00:59.530 --> 01:05.450 For this talk, we're going to start with a fair bit of background before we get into the meat of things. 01:05.450 --> 01:07.010 I should give a disclaimer. 01:07.190 --> 01:09.410 This isn't going to be an all-inclusive introductory talk. 01:09.410 --> 01:11.630 There is just too much to get through. 01:11.790 --> 01:15.670 And if you've never heard of HashGap before and are thinking, where can I adopt one? 01:15.690 --> 01:17.830 This talk is going to be a little rough to follow. 01:18.010 --> 01:19.030 Just stick around. 01:19.030 --> 01:22.750 You'll still learn something, and you'll definitely have some keywords to Google later. 01:22.750 --> 01:26.130 So, let's address what should always be the first question. 01:26.450 --> 01:27.210 Why? 01:27.510 --> 01:39.810 Well, large web corporations are still using character requirements that were determined in 1985 by the Department of Defense to be resistant only resistant to online brute force attacks over a 1,200-baud modem. 01:39.810 --> 01:43.670 And even then, they should have been rotated every couple months. 01:44.190 --> 01:59.250 They also have complexity requirements that should seem familiar because they have become pervasive and are largely responsive for a lot of people honestly believing that they can take almost any English word and add a number and an exclamation point to it. 01:59.350 --> 02:01.450 And it makes it an acceptable password. 02:01.450 --> 02:09.390 Spoiler, these policies in isolation have not magically become more secure since 1985 and are still guarding some very sensitive things. 02:09.850 --> 02:16.970 Thankfully, most of these websites and companies have some additional safety nets, like detecting questionable login origins or 2FA. 02:17.510 --> 02:20.730 Well, except Wikipedia, which, well, doesn't. 02:20.790 --> 02:24.910 And historically might have had one of the worst password policies on the internet. 02:24.910 --> 02:28.110 Thank you, Troy Hunt, for using a megaphone to broadcast the history here, which... 02:29.130 --> 02:31.090 I just... why? 02:31.470 --> 02:35.450 Your fix for zero-character passwords was a one-character requirement? 02:35.810 --> 02:43.170 There's also a large number of places where that eight-character standard, well, isn't, which frankly is a little baffling given some of the sensitivity here. 02:43.170 --> 02:51.130 PCI, the payment card industry, which only covers the systems where the payment card info is stored, this just seems lackluster. 02:51.310 --> 02:56.790 And on the other side of things, imagine what kind of information someone could collect for getting into your Facebook or Pornhub account. 02:56.790 --> 02:59.430 Imagine what they could do to your reputation by controlling it. 02:59.750 --> 03:06.150 And then there's eBay, which I should need to explain the level of financial ruin an auction site can bring if somebody else is bidding for you. 03:06.210 --> 03:10.550 Wells Fargo, a deserving punchbag perhaps, but they just haven't wisened up. 03:10.550 --> 03:12.370 That's a 14-character limit. 03:12.990 --> 03:18.370 And is there seriously a database with plain-text referentials limited to 14 characters in the background somewhere? 03:19.770 --> 03:21.010 Then there's Netflix. 03:21.870 --> 03:26.350 Does it make sense why hijacked Netflix accounts are so commonplace? 03:26.350 --> 03:30.410 I understand the want to make four-number pins usable, but really? 03:30.750 --> 03:45.130 Finally, we have a whole suite of devices in tech, and I'll pick on Cisco because I love them so much, that historically, by default, have no password, and the policy might get set by the people installing it, but, you know, eight characters suggest it. 03:45.310 --> 03:53.610 This seems like a deeply questionable recommendation when, again, those passwords were determined to only be resistant to attacks on networks in 1985. 03:54.090 --> 04:03.750 And while I'm on the trend of bashing trustworthy sources, it's only proper that I talk about NIST, or the National Institute of Science and Technology, and what they say, given that what they say often seeps into government regulation. 04:03.750 --> 04:19.030 The special publication 800-63B, released in 2017, said that the requirement should actually be 8-plus characters with no complexity, because someone did the statistical analysis and found out that people actually produce easier-to-reinforce passwords under complexity requirements. 04:19.030 --> 04:22.070 Like, adding a number and an exclamation point. 04:22.170 --> 04:26.530 They also say the maximum should at least be 64 characters. 04:26.690 --> 04:27.330 Hmm. 04:27.330 --> 04:29.310 I anted where things might be going. 04:29.310 --> 04:35.910 There's also a key section here that says increased password length is a key security control and to encourage passphrases. 04:36.270 --> 04:36.650 Hmm. 04:36.650 --> 04:37.490 You hear that? 04:37.490 --> 04:38.710 The future is coming. 04:38.850 --> 04:39.670 Slowly. 04:39.670 --> 04:42.150 And the 80s might finally end soon. 04:42.550 --> 04:50.450 The most recent guidance on February this year, mind you, this was not the first time it was published, from NIST and the FBI, is that, well, a lot more explict. 04:50.450 --> 04:54.350 15 characters without other complexity requirements is where we should be going. 04:54.350 --> 04:56.830 In fact, we should require it as soon as possible. 04:57.470 --> 05:04.930 And this is in line with what a bunch of other experts and sources that aren't the largest tech companies have been saying for much, much longer. 05:05.290 --> 05:15.070 In fact, a security consulting group that I greatly respect, Black Hills Information Security, makes this suggestion to their clients and uses a more paranoid standard of 20 characters internally. 05:15.270 --> 05:15.970 Neat. 05:16.170 --> 05:19.550 Though you might be asking, okay, why is Black Hills specifically on here? 05:19.550 --> 05:24.310 Well, it's because I'm picking on them and we're about to listen to some snippets of audio from a webcast last December. 05:24.310 --> 05:28.690 Mind you, this is a little cut up and out of context, but don't worry, most of the context is still there. 05:29.270 --> 05:32.910 7 characters is just easy to crack. 05:32.910 --> 05:33.910 How easy? 05:34.650 --> 05:38.950 If you go to the next slide, my son's computer, he's got a gaming computer. 05:38.950 --> 05:41.690 It takes 8 minutes to crack an LM hash. 05:42.130 --> 05:46.790 If you take the same 14 character password, it would take 4.3 billion years. 05:47.050 --> 05:48.430 Well, we got time. 05:48.710 --> 05:55.230 This is kind of what I'm talking about with regards to the password policy that they set in 1985. 05:55.230 --> 06:01.650 I mean, in 1985, an 8 character password policy was secure forever. 06:03.230 --> 06:04.410 90 days. 06:04.410 --> 06:05.870 90 days, okay. 06:05.870 --> 06:09.230 So it was secure for long enough for them to... 06:10.910 --> 06:12.990 we don't need to do anything. 06:13.730 --> 06:19.610 But, I mean, as technology changes, so do the password policies need to. 06:19.650 --> 06:21.850 Hey, this is warfare, right? 06:21.850 --> 06:24.090 Everything is move, counter, move. 06:24.090 --> 06:26.210 We have electronic countermeasures. 06:26.210 --> 06:28.530 You have electronic counter-countermeasures. 06:28.710 --> 06:31.610 And then it goes up above that and I lose track. 06:31.610 --> 06:39.530 So we're getting questions about have you run the Google common word attack against passphrases? 06:39.530 --> 06:46.030 So, like, if you just load words into a cracker, then doesn't that crack passphrases? 06:46.030 --> 06:46.790 Sure. 06:46.790 --> 06:48.130 Yes, it does. 06:48.290 --> 06:52.310 How many combinations of four-word passwords are there? 06:54.410 --> 06:56.490 So how long is that going to take you? 06:56.490 --> 06:59.490 What if you start using words from a foreign dictionary? 06:59.810 --> 07:02.510 What if you start putting salt into those words? 07:02.510 --> 07:14.370 Like, but I just, I think if four words, and if you start using special characters as a spacer between your words and things like this, the question is, are you more secure than you were with eight? 07:15.610 --> 07:18.250 But, yes, there are attacks against everything. 07:21.110 --> 07:26.950 So, Darren kind of summarized this up, this from-the-field kind of our results, but I just did want to talk about it. 07:26.950 --> 07:30.070 We have no success with people who have 15-character passwords. 07:30.170 --> 07:31.630 Approach is zero. 07:31.930 --> 07:33.130 And we have tried these things. 07:33.130 --> 07:35.250 Now, we're constrained in our time. 07:35.250 --> 07:44.290 Normally, we don't have more than a week or so to do our password guessing, whereas ATT&CK, according to a Verizon report, they've got, like, what, nine months, something like that? 07:44.890 --> 07:46.530 Okay, another question, Jason. 07:46.530 --> 07:49.530 Yes, so this question's come up a few times. 07:49.530 --> 07:51.450 Are spaces legal? 07:51.670 --> 07:55.790 Yes, they are a special character, and they are very good. 07:56.070 --> 07:57.910 And it depends on the... 07:58.910 --> 08:00.650 And I'm going to cut it there. 08:00.730 --> 08:13.830 So, they have some pretty solid reasons, a couple of pointed recommendations, but perhaps the most interesting thing mentioned is that they have been given hashes from a domain with a 15-character passphrase policy specifically to crack them. 08:13.830 --> 08:17.050 And the amount they can crack in a week approaches zero. 08:17.050 --> 08:18.630 Basically, no success. 08:19.130 --> 08:22.330 There's also that mention of spaces are a special character. 08:22.430 --> 08:24.650 We'll get back around to that one. 08:25.370 --> 08:27.370 They are a character, certainly. 08:27.930 --> 08:30.930 Any case, approaching zero success. 08:31.290 --> 08:32.410 Pack it in. 08:32.490 --> 08:33.550 Presentation over. 08:34.190 --> 08:35.690 That's all, folks. 08:37.610 --> 08:38.490 No? 08:38.490 --> 08:39.810 You're not buying that? 08:39.810 --> 08:48.290 Well, good, because neither am I, and I should address the final reason I'm here presenting on this topic in particular, which is the CISO of my company. 08:49.410 --> 08:55.210 So, getting on the password policy, so, taking that innovative kind of incubator mindset and looking at passwords. 08:55.310 --> 09:00.370 So, passwords are something that's highly audited, because it's very easy to do. 09:00.370 --> 09:06.830 If you're an auditor and you're trying to assess whether somebody's passing muster, you can have this rule set, and you can walk in and either they pass or they fail. 09:07.110 --> 09:11.470 And you'll see a lot of that, and a lot of the companies have this password policy that comes straight out of audits. 09:11.470 --> 09:15.230 Eight characters and three or four of uppercase, lowercase, special characters and numbers. 09:15.230 --> 09:16.110 There, I just rattled it off. 09:16.110 --> 09:17.870 It's been almost 20 years of that. 09:19.090 --> 09:33.210 So, we looked at that, though, and as we went through the red teaming, we found that one step in what we call the kill chain, if an attacker were successful, and we actually give them a leg up, we actually bring hackers on and bring them in as fake employees. 09:33.210 --> 09:35.670 We give them a laptop and a password and they start. 09:35.890 --> 09:40.070 And we found one step in the kill chain was taking all the passwords and cracking them. 09:40.070 --> 09:52.010 And they would run computers with graphic processing unit, augmentation, and they'd run for hours, and they'd be able to crack a few passwords and hopefully they'd find a privileged account, and then they were off to the races with that. 09:52.070 --> 09:57.150 So, while that was only one step in what I call the kill chain, we just said, you know, we want to win that battle. 09:57.150 --> 10:00.830 And here we are compliant, but it's just not getting it done. 10:00.830 --> 10:02.430 I'm just meeting compliance. 10:02.870 --> 10:10.070 So, we ran some math on the whiteboard and we said, well, what if we went out to a really long password, 15 characters, but got rid of all the complexity requirements? 10:10.710 --> 10:16.010 And, you know, I have a lot of people with high math SAT scores on my team. 10:16.010 --> 10:17.130 Let's put it that way. 10:17.510 --> 10:21.250 So, we had some great whiteboard battles and, you know, how much better would it be and that sort of thing. 10:22.390 --> 10:27.770 But what kept creeping in there because of kind of that tick box mentality was, well, we have to have complexity. 10:27.830 --> 10:28.690 Everybody's expecting that. 10:28.690 --> 10:30.810 We have to have uppercase and lowercase and on and on. 10:30.810 --> 10:32.430 But we said, well, let's just try it out. 10:32.950 --> 10:35.570 So, the math held and we felt pretty good about it. 10:35.570 --> 10:41.310 And then around that time, the National Institute of Standards and Technology, NIST, released an updated standard. 10:41.310 --> 10:42.870 And they said, well, length is king. 10:42.870 --> 10:49.030 And if you can get a longer password, you can get rid of some of that stuff as long as you look for commonly used passwords and block them out. 10:49.310 --> 10:51.230 So, long story short, we did it. 10:51.230 --> 10:53.730 And it took about 90 days to roll it in. 10:54.090 --> 10:56.990 And the impact has been substantial. 10:57.070 --> 11:06.010 And the only reason we were able to do that is because we innovated and created this thing that we called the Kraken that every single day tries to crack all the passwords in the company. 11:06.130 --> 11:09.930 And we see the success rate of that machine just dropping precipitously. 11:09.930 --> 11:10.790 We saw it. 11:11.050 --> 11:12.530 And I'm going to cut it there. 11:13.070 --> 11:16.970 So, yeah, that's out in the public domain. 11:18.290 --> 11:22.750 And we need to talk about that math Jerry mentioned. 11:23.270 --> 11:28.490 See, the math might hold up, but the equation isn't realistic. 11:28.490 --> 11:30.530 There's more than one way of approaching this problem. 11:30.530 --> 11:32.850 And I've heard the arguments spun multiple different ways. 11:32.850 --> 11:42.590 The first of which is it's inconceivable to crack a 15-character password because brute-forcing through all the possible numbers and lowercase letters is 1.6 sextillion combinations. 11:42.930 --> 11:49.050 Another argument I have heard that comes from a better standpoint is assuming the passphrase is made up of words. 11:49.050 --> 11:56.850 There are a lot of words around five characters or more, so you can say a 15-character passphrase is probably three words, which is extremely difficult. 11:56.870 --> 11:59.770 You'd have to go through more than 50 quadrillion options to be sure. 11:59.770 --> 12:02.670 Okay, big number, but certainly smaller than the last one. 12:03.050 --> 12:16.530 And the last one I've heard, perhaps the most educated of these strawman arguments, is based on the common requirement of eight characters doubling that gets you just above the 15-character requirement, so maybe we should think about passphrases as just multiple passwords combined. 12:16.530 --> 12:26.170 In which case, the lowest margin for cracking all of the combinations of two passphrases is just the combinations of two common passwords combined. 12:26.170 --> 12:32.530 Which, if we're using the RACU dictionary, is still over 205 trillion, which they'll tell you is unreasonable. 12:32.850 --> 12:42.330 Well, I'm here to tell you that all of these arguments that say that cracking past 15 characters, regardless of reasoning, can be undermined, and they can be undermined with only three factors. 12:42.470 --> 12:43.890 What are those factors, you might ask? 12:43.890 --> 12:45.230 Are you just teasing us? 12:45.230 --> 12:47.390 Is this a timeshare scheme in disguise? 12:47.510 --> 12:51.150 No, the big secret weakness is humans. 12:51.810 --> 12:52.690 Inconceivable! 12:53.090 --> 12:53.870 I know. 12:55.010 --> 13:03.190 Specifically, humans are bad at big numbers, humans pack complexity on the ends, the ends of passwords or passphrases, and humans pick similar things. 13:03.190 --> 13:06.890 Similar things to other humans, common things are common because they're commonly picked. 13:07.350 --> 13:15.550 Before I get too far, we should define some limits on what is reasonable, and I should address the other part of the clickbaity title of this talk. 13:15.550 --> 13:17.070 Why the $500 limit? 13:17.310 --> 13:29.550 Well, besides it being a nice round number that is easy to pitch, it's also the roundabout cost of an entertainment system, and you can safely assume that every type of threat actor you might need to be worried about, including LulzSec and the Script Kitties, 13:29.550 --> 13:31.170 has access to this amount of money. 13:31.170 --> 13:37.570 It's also an amount that can pack a sizable punch regardless of the path you take, either owning a cracking rig or renting out cloud computing. 13:37.570 --> 13:50.750 $500 is more than enough to go off and build a small cracking system out of a GPU from eBay and some outdated desktop parts, which you might have found in a dumpster, which should net you the theoretical max of 53 gigahashes against NTLM. 13:50.870 --> 13:59.450 As for the cloud, in AWS, $500 will get you 68 hours on a spot instance, which, yes, might get preempted. 13:59.650 --> 14:00.630 Probably won't, though. 14:00.630 --> 14:10.010 With eight V100 GPUs, which you can do manually, or you can use a management tool like CoalFire's NPK to manage the spot instances for you, for both scale and automation of the attack. 14:10.190 --> 14:19.690 If you're an attacker, and what you're planning on doing is a series of short-running attacks, instead of waiting 68 hours to get all the results, why not just spend 68 instances and get the results in one hour? 14:20.110 --> 14:30.930 Sadly, NPK doesn't work with Google Cloud, which actually appears to be cheaper, and if you squeeze out everything you can, you can get 83 hours of time on an instance with eight V100 GPUs. 14:30.930 --> 14:40.390 Which, besides being terrifically cheap, brings us to a terrifying theoretical max of 189.3 petahashes of NTLM, we can guess. 14:40.390 --> 14:42.850 Not mega, not giga, not tera. 14:43.110 --> 14:43.970 Peta. 14:44.370 --> 14:45.990 189 quadrillion. 14:45.990 --> 14:56.850 If we compare that to that last strawman argument of the ROCU dictionary on top of itself, sure, theoretical isn't real performance, but the difference isn't off by a factor of a thousand times. 14:57.150 --> 14:59.090 Although humans aren't bad with big numbers. 14:59.370 --> 15:02.730 Which brings us around to the second strawman argument. 15:02.990 --> 15:08.970 I'd like to throw in an alternative equation that is still very conservative for how many guesses it takes to crack a three-word passphrase. 15:09.170 --> 15:20.370 All of the words that are obsolete to the third power divided by the number of people in the organization or number of hashes an attacker has to crack, all of which is divided by the factor of human laziness squared. 15:20.370 --> 15:22.930 How do you quantify human laziness, you might ask? 15:22.930 --> 15:27.770 Don't ask me, but trust me, the value of that variable always seems to be greater than one. 15:28.050 --> 15:41.690 This is a somewhat joking equation, but the very conservative hypothesis here is that people making a passphrase will use words from languages they know and can think of under the duress of password creation, which tends to be a much more limited set. 15:41.690 --> 15:47.770 In fact, I'm going to say now and support later that the pool to pick from for a lot of people seems to be between 32,000 and 64,000 words. 15:48.050 --> 15:51.890 Which brings me to a point where we are going to need to break out a lot of math. 15:51.950 --> 15:55.490 Because underminer number one, people are bad at big numbers. 15:55.690 --> 15:59.130 Thankfully, people are good at spotting trends after they have all the information. 15:59.410 --> 16:02.870 So let me give you something that is easier to parse, or hopefully easier to parse. 16:02.870 --> 16:13.990 This is a chart of the actual computational limits of combining words together in an attack on a single 2080 Ti on NTLM hashes, which I picked because it's a consumer GPU and I have access to one. 16:13.990 --> 16:17.690 The horizontal axis of this chart is the number of words in a passphrase. 16:17.690 --> 16:23.670 The vertical axis is the size of the dictionary, or perhaps a more useful way to think about it, the rarest word in a passphrase that can be cracked. 16:23.770 --> 16:26.870 Because a logical attacker is going to use the list of words by frequency. 16:26.870 --> 16:30.110 The bigger that list is, the rarer the words are going to be that are in it. 16:32.510 --> 16:40.170 Now, all the numbers in the colored boxes are the amount of minutes required to complete an attack search space. 16:40.170 --> 16:44.690 And the coloration tells you how long a time that is relative to minutes, hours, days, weeks, months, or years. 16:44.790 --> 16:48.250 Because I'm not going to lie, I don't know off the top of my head how many minutes are in a week. 16:48.590 --> 16:52.830 Going down or to the right exponentially increases the amount of work needed. 16:54.330 --> 17:00.250 And there's a lot of spots here where the jumps in difficulty are sharp. 17:00.250 --> 17:03.130 And this is where the idea of a computational wall comes in. 17:03.130 --> 17:06.270 A seemingly sudden increase in difficulty that you can't go over. 17:06.510 --> 17:10.090 But of course, this is only on the chart for a consumer GPU. 17:10.250 --> 17:11.530 What about a V100? 17:12.270 --> 17:14.630 Well , it's not actually that much different. 17:15.610 --> 17:21.490 There are a lot of reasons why V100 should be much better for cracking generally, but it isn't a variable for this particular chart. 17:21.490 --> 17:23.410 Anyway, what if we have more than one GPU? 17:23.410 --> 17:24.370 Why not eight? 17:24.630 --> 17:28.170 Well, the chart is going to shift down a little bit and open up some options. 17:28.170 --> 17:37.270 Those of you that have noticed the size of the numbers we're dealing with on the vertical axis probably already have some nightmares to take home, but I'm going to make sure everyone else has them too. 17:37.330 --> 17:41.590 In the two-word column, that is more than 16 million words in 20 minutes. 17:41.590 --> 17:51.170 Basically, every word actually in use from every language spoken by at least 1% of the world's population fits in here with room to spare for a couple extra million common passwords. 17:51.650 --> 17:58.830 In the three-word column, that is every non-obsolete word in the English language and it's testable in a matter of hours. 17:58.990 --> 18:06.750 In the four-word column , we have a sizable chunk of commonly used words where a target attack, say from scraping the memos and websites of the target makes sense. 18:07.630 --> 18:12.290 Before I get too excited, I'm sure someone is thinking, okay, cool, that's just NTLM. 18:12.290 --> 18:16.190 What about a slower actually secure hash or quote-unquote secure hash? 18:16.190 --> 18:23.750 Well, here's that same chart for shop512unitspassphrases and you'll notice there are still some viable attacks on two- and three-word passphrases. 18:23.790 --> 18:29.630 And here's bcrypt or blowfish configured with the Unix defaults, albeit this is some pretty weak Unix defaults. 18:29.630 --> 18:32.550 I think Ubuntu has gone well past this now. 18:32.550 --> 18:45.210 In any case, we lose a lot of capability, but even when that difficulty curve is ramped way the heck up, we still have options in the two-word passphrase category. 18:45.210 --> 18:59.830 As an attacker, this chart makes me really sad, but the reality of most corporations using Windows somewhere in infrastructure is that there will be somewhere something using a hash that, like NTLM, isn't going away for quite a while to come. 19:00.190 --> 19:14.910 And as far as individual users that are concerned with what they need to have as a passphrase, well, they need to make sure what they have isn't going to get cracked when the hashes get dumped, either inside an institution or when a website gets all of its password dumped by SQL injection. 19:14.910 --> 19:22.990 And let's be real, a lot of major websites and companies keep on getting caught with their pants down, and we only find out they're using a fast hash or plaintext the hard way. 19:23.730 --> 19:29.650 Not to mention the difficulty of computing a hash is a linear factor in a world where computing power increases exponentially. 19:29.730 --> 19:35.630 So I'm going to go back to the other chart, because it's time to get into the attacker mindset and play a game of bad recommendations. 19:35.990 --> 19:43.890 First up is Google, and yes, the advice is old, but the advice, much like their policy, hasn't been updated in more than a decade. 19:43.890 --> 19:45.830 So, I love sandwiches. 19:45.850 --> 19:50.410 It's not a great example, and that mix of leet-speak and case-shifting doesn't do much for the difficulty. 19:50.410 --> 19:53.230 I'll be generous and say that it makes it about 100 times harder. 19:53.370 --> 20:05.530 In terms of the rarity, this slide shows where the various words fall on Google's own most searched list, that's the G number, and the Wikipedia frequency list, which would be the W number. 20:06.770 --> 20:11.130 The fact of the matter here is, the underlying phrase is crackable in under 3 minutes. 20:11.130 --> 20:17.350 And even giving the benefit of the doubt and the difficulty of guessing leet-speak substitutions, that's crackable in 244 minutes. 20:17.650 --> 20:32.550 I should probably also mention the recommendation put forth in the absolute latest NIST and FBI recommendation, because they suggested in a... they suggested the passphrase, voices protected 2020 we are, and then suggested the passphrase that is even better. 20:33.010 --> 20:34.130 At least according to them. 20:34.130 --> 20:37.630 Which is director-month-learn-truck, because the words are unrelated. 20:38.270 --> 20:43.370 Well, those words might seem unrelated, but they all have one thing in common, and that's they're all eye-searingly common. 20:43.390 --> 20:51.570 The rarest word in there is truck, and oh boy, that isn't the top 4,000, regardless of which list you choose. 20:52.130 --> 21:01.410 Four common words are not safe from offline cracking, which does bring up another, perhaps more viral recommendation from XKCD 936. 21:02.310 --> 21:10.090 Now, a lot of people have used this as password advice, including the management intercontinental exchange. 21:10.090 --> 21:20.330 And the matter of it is, the math in XKCD's advice as written is actually fine, because it was written to handle an online attack where the rate of guessing is only 1,000 a second. 21:20.450 --> 21:29.970 Now, there's a claim here that the average user shouldn't have to worry about attempts to crack a stolen hash, and I'm here to tell you from experience the average user reuses passwords. 21:30.030 --> 21:41.610 The average user also works at a company, and if that company is larger than a couple dozen people, they should also worry about stolen or dumped hashes, both from their own infrastructure and the websites their users are using both professionally and personally. 21:41.970 --> 21:44.110 Four common words isn't safe from offline attacks. 21:44.110 --> 21:49.370 If anything, XKCD the example here is a little stronger than intended because staple isn't actually that common. 21:49.370 --> 21:55.670 It's number 11,363 on the Wikipedia frequency list and completely off the end of the Google list. 21:56.110 --> 21:57.610 Then there's level entropy. 21:57.610 --> 22:00.430 XKCD says it's a common word. 22:00.430 --> 22:11.610 If we say common words are words that are in the first 2048 of any given word list, and the attackers, well, they're going to win all the way out to six word phrases. 22:11.610 --> 22:12.470 Yes, really six. 22:12.470 --> 22:14.230 Like, good luck Diceware users. 22:15.490 --> 22:16.830 This is nasty. 22:17.850 --> 22:25.470 This is not how this... there is no way out of this computationally with just throwing on common words. 22:25.930 --> 22:27.690 Mind you, there are some caveats. 22:27.730 --> 22:38.730 The real world isn't as simple as an Excel sheet, so before we get into real world results and the mechanics of attacks, we should very quickly cover the things that are going to be ever present when attacking these passwords using a GPU. 22:39.750 --> 22:41.770 Yeah, this is going to get real technical real quick. 22:41.770 --> 22:44.210 First of which is the dictionaries and the size of the dictionaries. 22:44.210 --> 22:49.250 There's a lot of bandwidths to go around for operations within a GPU and its memory, but transferring data to the GPU? 22:49.250 --> 23:02.090 Well, PCI Gen 3 by 16 is only 16 gigabytes per second max theoretical, not real world, and that might seem like a lot, but when we're dealing with 16 billion theoretical bytes per second, 23:05.430 --> 23:15.750 modern GPUs can do 26 billion real hashes of a passphrase per second, and one of these numbers doesn't fit within the other and also is real, not theoretical. 23:16.050 --> 23:19.850 That PCI bandwidth is not going to match up with the hash rates. 23:19.950 --> 23:30.150 The other limitation to be mindful in terms of what kind of attacks are possible is the nature of CUDA or the AMD equivalent, I'm not going to get into it, cores in the GPU and what they can do. 23:30.150 --> 23:33.730 Compute Unified Divided Architecture, which is, well, not a lot actually. 23:33.730 --> 23:46.410 They were built to do lots of single instruction multiple data computations on matrices and vectors for graphics, which means lots and lots of units they can do arithmetic, ALUs, and not a lot of space or silicon devoted to controlling them. 23:46.410 --> 23:59.630 The nature of single instruction multiple data means groups, or in this diagram rows of ALUs, all need to be doing the same type of thing at the same time, and those instructions and a significant portion of the data needs to fit in a smaller shared cache, 23:59.630 --> 24:03.470 and oh right, the instructions better be simple and something it can actually do. 24:03.470 --> 24:09.430 If that something isn't exactly implemented in HashCat or John the Ripper, often the best bet is to find a workaround . 24:09.550 --> 24:14.370 Also, thank you HashCat and John the Ripper devs for making it easy to use these devices for cracking. 24:14.370 --> 24:17.050 Okay, let's talk about techniques and results. 24:17.050 --> 24:26.650 First, dictionary attacks, basically checking through a massive list of passwords in a file, with or without GPU generating some additional candidates to check, though more on rules later. 24:26.970 --> 24:43.990 Intercontinental exchange, we've been running a dictionary attack during the period that Jerry mentioned in that soundbite, while we rolled out the 15 character policy, and as you can see in this graph, the average length of a cracked password, the policy wasn't just successful, 24:43.990 --> 24:47.190 it caused some rapid jumps in length when it started to be enforced. 24:47.270 --> 24:51.610 And after implementation, the average length evened out despite some outlying spikes. 24:51.610 --> 24:53.850 But this is the less interesting half of the story. 24:53.850 --> 24:58.770 This is the graph of the percentage of passwords that were cracked by dictionary attacks, only dictionary attacks. 24:59.130 --> 25:02.550 Yes, that number in the upper left is 50%. 25:02.550 --> 25:08.670 Dictionary attacks are very good when you have a dictionary of passwords made of the same password policy that you're targeting. 25:08.770 --> 25:19.710 And yes, dictionaries also aren't very good after people change their password under a completely different and significantly changed policy and start picking things that aren't going to be in the dictionary anymore. 25:19.710 --> 25:31.890 In fact, if we overlay the two graphs, we see multiple downward shifts in the number of cracked passwords, even after the average of cracked passwords is above 15 characters, as further enforcement for cracking cracked passwords was rolled out. 25:31.890 --> 25:35.470 Until it settled down and around the 1% range. 25:35.470 --> 25:37.390 Mind you, it didn't approach zero. 25:37.390 --> 25:39.450 It held down near a certain percentage. 25:39.470 --> 25:43.110 There is always somebody picking and re-picking a terrible password. 25:43.150 --> 25:45.690 And these attacks are trimmed and don't show anything that has happened recently. 25:45.690 --> 25:48.810 But I assure you, straight dictionary attacks have not had much success. 25:49.750 --> 25:51.670 Though I was hired around this time. 25:51.670 --> 25:53.950 So let's talk combinator attacks. 25:54.030 --> 26:00.850 Attacks centered around combining different dictionaries or the same dictionary results into itself. 26:01.170 --> 26:03.430 Or sorry, the same dictionary onto itself. 26:03.430 --> 26:08.190 The attack here is pretty straightforward and we've kind of already talked about it so let's get right into the results. 26:08.470 --> 26:14.290 And well, here's a chart of every passphrase password longer than 15 characters ever cracked in a continental exchange. 26:14.290 --> 26:22.850 That was crackable with a small dictionary of words or common passwords organized to reflect the charts from the computational wall part of the presentation a little bit earlier. 26:23.150 --> 26:35.870 In order to do this, I had to modify an algorithm for dissecting passwords called zxubn to be able to actually properly handle common separators like spaces between passwords and a passphrase because apparently the creators of zxubn didn't think that was important to handle. 26:35.870 --> 26:37.130 Anyway, I digress. 26:37.710 --> 26:55.590 A password slide here based on how many elements, usually words, but sometimes a common password zxubn believes it is made up of and the rarity of the rarest element based on the number of guesses required, which should roughly dictate the size of the source dictionary required. 26:56.030 --> 27:01.870 And you can see there's a rather precipitous drop-off somewhere between 32,000 and 64,000. 27:01.870 --> 27:11.670 Along with some pretty significant preference for three element passphrases, which might have had something to do with certain recommendations packaged with the policy. 27:13.350 --> 27:16.430 Now, this is neat and all, but what about the other datasets? 27:16.430 --> 27:18.010 Say, not from this company. 27:18.230 --> 27:24.110 Well, I considered calling up various companies with 15-character policies and seeing if they were willing to give me their hashes. 27:26.530 --> 27:29.970 But it didn't work and it seemed pretty unlikely, so I had to artificially make one. 27:29.970 --> 27:42.190 So this is the result of over 37 million hashes from the have-I-been-pwned version 2 collection, where every password known to be less than 15 characters long has been stripped out, which is really only possible because over 90% of this list has already been cracked. 27:42.450 --> 27:53.150 Both of the attacks here are pretty shallow and short-running, in large part because I only needed to prove a point, and also the hashrate is artificially terrible when cross-checking 37 million hashes for matches. 27:53.350 --> 28:00.070 That being said, this is 1.14% of all the passphrases in the dataset in less than 3 minutes. 28:00.370 --> 28:01.630 Scared yet? 28:01.710 --> 28:02.750 Good! 28:02.850 --> 28:08.450 Because this is an example of what happens when you use a lot more candidates and checking combinations of passwords. 28:08.450 --> 28:15.050 If you still remember that third strawman argument, this is all of the ROKU word list on top of itself. 28:15.050 --> 28:21.510 Sure, it takes a day and 16 hours on some piddly GPU horrifically bogged down by 37 million hashes to crack. 28:21.750 --> 28:24.870 Normally in cloud infrastructure, this would take 16 minutes. 28:24.870 --> 28:30.110 For a single machine in AWS or Google Cloud with those 8 GPUs, it would cost single-digit dollars. 28:30.870 --> 28:36.030 Now that I've got the would-be crackers excited, there are some technical shortfalls with HashCat that also need to be noted. 28:36.030 --> 28:38.390 The combination mode only takes 2 files as input. 28:38.390 --> 28:51.430 You want to use this so HashCat can load as much as it can on GPU RAM ahead of time, which means if we want to check 3 or 4 element passphrases, you need intermediate dictionaries, being mindful of the exponential file size. 28:51.610 --> 28:56.890 And it's a similar deal for the hybrid mode, which can only take one word list and one mask file. 28:57.110 --> 29:02.130 You could use other programs and pipe in candidates, but you pay the piper when doing so in a fast hash. 29:02.330 --> 29:10.510 And the other thing HashCat isn't going to do for you is generate variants of passphrase candidates with all the spaces and capitalization that people generally use. 29:10.630 --> 29:15.970 From what I've seen, you're going to want title case, sentence, and all lowercase, both with and without spaces. 29:16.630 --> 29:19.450 No, I do not consider spaces a special character anymore. 29:19.510 --> 29:28.830 The easiest way to do this is with individual rules on a combinator tack, starting with a preprocessed dictionary that already has the spaces between capitalized words. 29:28.830 --> 29:32.210 Then you can manipulate it easily enough to get the spaces and capitalization desired. 29:32.210 --> 29:35.970 For HashCat, J corresponds to the left word list, K corresponds to the right list. 29:36.010 --> 29:39.110 Which, on the topic of rules, is another shortfall. 29:39.110 --> 29:41.890 You can only do one set of rules per word list in combination mode. 29:41.890 --> 29:53.130 Yes, sorry, if you want to check lots of different things using rules like common words in between two words, you're going to need a honking, massive, and ugly bash file, or a program to manage it for you. 29:53.130 --> 29:58.410 This is actually what TrustedSexHatecrack is doing behind the scenes for what they call middle or thorough combinator attacks. 29:58.410 --> 30:02.810 It's basically spawning off tons of HashCat command lines. 30:03.870 --> 30:04.570 Alright. 30:05.370 --> 30:13.610 Enough about conditions of combinators, let's move on to PrinceAttacks, which, despite the other name for the attack, has nothing to do with the artist formerly known as. 30:13.710 --> 30:21.490 Prince is a acronym for Probability Infinite Chained Elements, but it is pretty simple in purpose. 30:21.570 --> 30:26.850 Take the path of least resistance and find more passphrases sooner by outputting shorter linked candidates first. 30:26.890 --> 30:34.130 Not only is the search space smaller, but we can also expect to find more passphrases here because people tend to pick passphrases close to the minimum required effort. 30:34.350 --> 30:37.870 This overlap of least resistance motivations is just great for an attacker. 30:38.430 --> 30:39.390 How does Prince work? 30:39.390 --> 30:54.150 Well, it ingests a word list, sorts all the contents by links, and puts them into separate lists, and then begins producing candidates at the minimum specified length out of the lists of the various links, iterating through all possible combinations of lists until the options are exhausted, 30:54.150 --> 30:56.770 at which point it moves on to making longer candidates. 30:57.450 --> 31:04.550 Now, after that explanation of how Prince works, you might be wondering, why not just use combinators of length-cut lists? 31:04.570 --> 31:06.270 Aren't Prince and Hashcat separate programs? 31:06.270 --> 31:07.410 Won't I have to pay the piper? 31:07.410 --> 31:10.930 Didn't you just say that transferring all that stuff for PCIe was terrible for performance? 31:10.930 --> 31:20.370 Well, yes, you do have to pay the piper, and you could manage all of these attacks manually, but it gets pretty crazy to manage all the lists and combinations for 3- and 4-word elements. 31:20.370 --> 31:28.150 It's doable, but you really need another programmer script, and there's a solution that circumvents this, and it comes back to one of the undermining factors. 31:28.870 --> 31:33.390 This is the positions of dictionary elements in passphrases. 31:33.550 --> 31:38.190 Larger numbers here mean more passphrases contained in elements straight out of a dictionary in that position. 31:38.190 --> 31:44.670 And there is one heck of a disparity between the last position in a passphrase and the rest of a passphrase. 31:44.810 --> 31:47.290 Because humans pack complexity on the ends. 31:47.290 --> 31:51.810 Most of the end, sometimes in the beginning, extremely rarely in the middle. 31:52.550 --> 31:57.510 So, the fix for Prince's terrible hashrate on fast hashes when it's piped in? 31:57.610 --> 31:58.430 Rules. 31:58.450 --> 32:03.310 Because you can use the default hashcat cracking mode, you can specify with a rules file. 32:03.890 --> 32:04.530 Any problems? 32:04.530 --> 32:17.470 Well, yeah, most rule lists are made by people on the internet and aren't long enough to make use of a GPU's spare resources or are more focused on modifying passwords and not altering passphrases, like adding suffixes or prefixes. 32:17.690 --> 32:24.810 So, I've made them one more focused on common prefixes and suffixes, you know, your 20, 20, your exclamation point, etc. 32:24.850 --> 32:42.670 With 4,175 rules, which is up in the rephraser repo I'll mention later, and soon to come I'll also be releasing a prefix and suffix list, which probably is already up by now, based on the frequency data of those cracked password phrases mentioned earlier in the have-I-been-pwned-version-2 list. 32:43.130 --> 32:43.830 Okay. 32:43.830 --> 32:47.150 Let's talk success rates for print. 32:48.970 --> 32:57.130 Now, the kicker here is that we're making use of that rule list I mentioned to catch passphrases with common suffixes and prefixes. 32:57.130 --> 32:59.590 There are no single-element passphrases here. 32:59.590 --> 33:02.730 We can see a repeat of an earlier trend. 33:02.990 --> 33:10.410 Namely, a sudden drop-off between 32,000 and 64,000 with some clustering around three elements, including the suffix or prefix. 33:10.990 --> 33:13.430 You've got to remember all of these are being run with the rules. 33:14.030 --> 33:19.670 This works out pretty well for sussing out passphrases, at least within your continental exchange. 33:20.570 --> 33:22.390 What about a much larger dataset? 33:22.630 --> 33:27.990 Well, we can also see the reason why people like using print's attacks. 33:28.070 --> 33:38.670 Both of these attacks were using the RockU password dictionary as the source, and both were stopped at the same time at 1.8, the runtime of the RockU squared combinator, RockU on top of itself. 33:38.710 --> 33:45.250 That complete attack I mentioned earlier took one day, 16 hours on our piddly setup, and got 5.82%. 33:45.250 --> 33:50.450 These attacks managed to concentrate a significant portion of that success very early in cracking. 33:50.470 --> 33:57.250 The other comparison here is the performance between restricting the number of elements print is allowed to use in the attack. 33:57.250 --> 34:05.050 At least in this case, there was a limited but significant advantage to focusing only on three-word element passphrases. 34:05.270 --> 34:10.150 Because again, we're also using that ruleset mentioned earlier with the prefixes and suffixes, based on the print's candidates. 34:10.370 --> 34:14.250 I'll also say again, this was at a really abysmal hash rate. 34:14.530 --> 34:24.370 We barely were reaching one gigahash when doing this, and these attacks can be much, much faster when you're not drowning your GPU in 37 million hashes to check. 34:25.010 --> 34:28.250 And speaking of fast, it's about time I get to the new and shiny. 34:28.250 --> 34:33.470 Word-level markup chains for going after passwords that are at their core phrases. 34:33.930 --> 34:36.030 What are word-level markup chains? 34:36.030 --> 34:42.690 The simplest explanation I can give is it's an over-glorified state model to store relationships between groups of words. 34:42.690 --> 34:48.410 For this example, we'll just do a two-gram model, think two elements in the state. 34:48.410 --> 34:58.690 If the phrase used for training is the cows eat grass, a two-gram model will record state transitions for the cows to eat and cows eat to grass. 34:58.690 --> 35:07.790 Obviously, this isn't a terribly useful model by itself, but imagine if it had some more training data, say, hundreds, thousands, or millions of sentences. 35:07.790 --> 35:11.210 The intent is to build up a model of the relationships between groups of words. 35:11.210 --> 35:18.570 And if we want to be more accurate, we can also increase the number of elements in the state, or raise the number-gram of the model to three or beyond. 35:19.190 --> 35:24.670 Though research generally seems to show that three is probably the point where you should stop. 35:25.430 --> 35:37.170 Now, there is one pre-existing proof of concept I could find that does more or less this and actually would generate output fast enough to be useful in password cracking. 35:37.170 --> 35:43.730 Sadly, it was single-threaded, written in a mix of C-sharp and C++, and designed with a Windows Compile target in mind. 35:43.730 --> 35:51.010 That simply wouldn't do for my purposes, so I created something similar in Python that is parallel, uses existing libraries, and is naturally more multiplatform. 35:51.030 --> 35:52.490 So, how well does it do? 35:52.810 --> 36:09.750 Well, the astute members of the audience when I showed this table on the right of every passphrase crack that was combinator-findable may have noticed some numbers that were a little too far into the lower right based on the computational complexity charts we went through before. 36:10.010 --> 36:11.850 Let me color that in for you. 36:12.350 --> 36:26.150 Now, the very astute of you might also infer that I did not in fact have unlimited access to eight V100s, and also that chart on the right is strangely positioned almost as if it extends further to the right. 36:26.230 --> 36:27.770 Well, it does. 36:27.890 --> 36:30.730 And I had a single 2080 tie for my research. 36:30.910 --> 36:37.350 I was also heavily timeboxing everything on here that isn't a shade of green, not from combinator attacks. 36:37.350 --> 36:38.370 Flat out. 36:38.550 --> 36:42.430 Admittedly, it's not a deluge of results, but, come on. 36:42.570 --> 36:43.470 Years. 36:43.470 --> 36:46.610 Literal years for the combinator attack would not have yielded some of these. 36:46.610 --> 36:49.890 And the couple out in the six and seven element column? 36:49.890 --> 36:52.110 Do you have any idea how long 10 to the 13 is? 36:52.110 --> 36:55.990 Because that's what it is corresponding on the difficulty computation. 36:55.990 --> 36:57.230 It's millennia. 36:57.610 --> 37:00.490 Certainly I'm very happy, but what about our much larger dataset? 37:00.870 --> 37:01.950 Well, a similar story. 37:01.950 --> 37:07.630 These attacks are very quick when doing only a couple of words, but admittedly don't pull in too much. 37:07.830 --> 37:09.870 Only tens of thousands, you know. 37:10.410 --> 37:18.890 The other factor you're likely to play here is there's just not that many passphrases that are also phrases that exist in the dataset with four words. 37:19.290 --> 37:24.470 While we're here, I would like to point out the accuracy tradeoff of choosing a 3-gram over 2-gram model. 37:27.310 --> 37:33.310 You can see that the 3-gram got a little over half as much, but it only took 1 twelfth the time. 37:33.570 --> 37:35.390 That is the accuracy tradeoff. 37:35.470 --> 37:43.250 Now, before people get too uninterested, I should show off the really impressive thing for me, which is what happens when you put these to use on even longer passphrases. 37:43.850 --> 37:49.770 There still shouldn't be much out here in the search space, but people seem content to use phrases at this length. 37:49.770 --> 37:53.070 Possibly because these should be safe, according to everybody's advice. 37:53.070 --> 37:56.850 And these aren't even common phrases, they're just kind of normal phrases. 37:56.910 --> 37:59.210 Here are some examples of what isn't safe anymore. 37:59.470 --> 38:08.630 These probably aren't the passphrases you expected to leave here knowing are crackable, and certainly not crackable in 1, 2, or 9 hours at speeds barely over 1GHz a second. 38:08.690 --> 38:09.830 Do you have nightmares yet? 38:09.830 --> 38:14.410 Because everything here was generated by a Markov model and a simple hashcat rule set. 38:14.410 --> 38:20.410 No dump passwords as input, no cherry picking shenanigans, and the training data was completely agnostic to the target passphrases. 38:20.470 --> 38:22.610 No targeting of any kind. 38:22.810 --> 38:28.650 Admittedly, it does produce some strange candidates sometimes, and I've collected some of the weirder ones I've seen on the right here. 38:29.070 --> 38:32.930 I don't know how he went from intrauterine pressure catheters to Kiwi or Kiwis. 38:32.930 --> 38:39.490 I can only assume one of the websites scraped from the training data was a blog post about making Kiwi or Kiwis with an embedded catheter cowboy advertisement. 38:39.490 --> 38:40.750 I really don't know. 38:40.750 --> 38:43.870 Now I should head off to some common questions I'm anticipating. 38:44.190 --> 38:49.450 Some of you familiar with hashcat might be thinking, um, doesn't hashcat already have Markov chains? 38:49.450 --> 38:51.050 Why can't we just do this? 38:51.150 --> 38:51.970 Well, it does. 38:51.970 --> 39:01.010 It has a pre-made model for character-level predictions, which, when you start going out to 15 character passwords and what you want is multiple actual words, that model falls apart pretty quickly. 39:01.010 --> 39:09.250 Not to mention it doesn't store relationships between words, and it will basically never finish, because the search space is at least 333 sextillion combinations. 39:09.250 --> 39:14.490 If you're thinking, haven't you tried this with GPT-2 or some other machine learning algorithm? 39:15.470 --> 39:18.150 My answer is, have you considered hash rates? 39:18.150 --> 39:30.090 Markov models are good for this because they're quick, especially compared to massive models like GPT-2 or some other ML model, which by itself is more than 5 gigabytes and tends to take multiple seconds to pop out a single prediction. 39:30.090 --> 39:34.970 We need millions of predictions in a second for it to be viable in password cracking. 39:35.110 --> 39:40.350 The other side of this is, the more advanced models focus on making paragraphs, or complete pages. 39:40.510 --> 39:41.930 We barely need sentences. 39:41.970 --> 39:47.610 And there are very few passwords I've seen that resemble more than a sentence fragment. 39:48.190 --> 39:51.450 Alright , head back out of the weeds here, it's time to wrap up and summarize. 39:51.550 --> 39:57.990 If you're not an attacker, you've probably been sitting through this talk, mildly terrified , waiting for some kind of recommendation . 39:58.430 --> 40:02.450 Allow me to make you wait slightly longer by addressing the red teamers first. 40:02.450 --> 40:06.270 Red teams, please , don't cop out. 40:06.290 --> 40:09.730 15 character passwords are hard, but they aren't that hard to crack. 40:10.130 --> 40:15.750 Even against Bcrypt, you should at least be doing Combinators, PrinceAttacks, and MarkovChains for the duration of your engagement. 40:15.910 --> 40:20.410 And don't pretend your results should approach zero, it should never be zero. 40:20.770 --> 40:25.670 There will always be somebody who picks something like HelloSpring2020 as their passphrase. 40:25.930 --> 40:28.050 Blue team, your turn finally. 40:28.150 --> 40:39.230 Do the math that applies to your situation, and do a little more than just gather people that scored highly on the SAT more than a decade ago, and pack them into a conference room and whiteboard it. 40:39.270 --> 40:47.110 If intercepted or dumped hashes or personal password reuse is a concern for you, and it almost always should be, feel free to take my math and represent it. 40:47.110 --> 40:51.770 Unless your organization is cracking its own passwords, you will not know what people are using. 40:52.110 --> 40:54.970 I recommend the best behaviors , but plan for the absolute worst. 40:55.010 --> 41:00.770 Which brings me to something that can serve as a starting point for what to pass along to end users. 41:00.770 --> 41:13.070 And this is my personal recommendation, which of course is fairly paranoid, but the intent here is to make sure a hash, regardless of what type of hash it is, can't be cracked in $500 of expense. 41:13.290 --> 41:20.710 Which means you're going to be making illogical or highly unlikely phrases of five or more relatively uncommon words that are thematically unrelated. 41:21.350 --> 41:22.070 Whew. 41:22.610 --> 41:28.210 That seems like a lot, but we're talking about diabetic unicorn trap Chicago tunnel as a passphrase. 41:28.210 --> 41:34.330 It takes a little bit to make, but these things should be able to hang around for a while. 41:34.330 --> 41:46.390 And unless you force an attacker to use a large dictionary combining multiple types of words, cities, structures, fantasy creatures, verbs, medical conditions, and use some words that are uncommon, you're going to be building your security posture with cracks at the foundation. 41:46.390 --> 41:51.010 There will be some edge case that will allow them to crack your passwords. 41:52.370 --> 41:56.090 So here's a very overfull slide of everything. 41:56.090 --> 41:57.330 Any questions? 41:57.330 --> 42:01.250 I am in the Discord channel waiting by this time. 42:02.870 --> 42:09.950 Rephraser is up there at the top, though it's probably just easier to look for GitHub trap code rephraser in Google. 42:10.810 --> 42:12.050 And, yeah. 42:13.010 --> 42:14.350 Feedback is appreciated.