Date: Fri, 12 Aug 2016 09:22:17 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: How long should I let JtR munch? On Thu, Aug 11, 2016 at 10:56:47AM -0500, Skip Montanaro wrote: > I presumed that if I did something stupid in my attempts > to "improve" on XKCD936, this might catch them. I don't expect it to be an > exhaustive test, more of a regression test (or more-than-minimal smoke > test). That's right. Unfortunately, JtR's only builtin passphrase-targeting mode is PRINCE, and it might not be exactly what you need. An attacker knowing how you derived your passphrases would do better than that. Yet for now please feel free to experiment with whatever cracking modes we readily have. Also, I hope you're aware the XKCD was by far not the first time the use of (generated) passphrases was proposed. For example, there was Diceware (1995?), and our passwdqc included a passphrase generator right away when I wrote it in 2000. You might want to play with it: http://www.openwall.com/passwdqc/ polly looks broken in at least its use of a non-cryptographic PRNG. Per Python documentation, this is Mersenne Twister. Cracking it amounts to finding the 32-bit seed, somewhat similarly to (but also differently from) how I did it for PHP's here: http://www.openwall.com/php_mt_seed/ Also take a look at the Strip external mode in the default john.conf for an example of attacking a similarly broken password generator with small seed space. Even if this is fixed by substituting a CSPRNG into polly, it doesn't look trivial to figure out whether your generated passphrases are distributed uniformly or not (most likely not), and what the total size of the search space is. It's a pitfall similar to the one pwgen fell into (albeit with phonemes rather than words), and it's especially bad if you don't use word separators: http://www.openwall.com/lists/oss-security/2012/01/22/6 For a decent password/passphrase generator, you should be able to prove that the distribution is uniform, and calculate exactly how large the search space is. If you can't, then the generator is presumably broken. > I was unaware of the "$n$" prefix in general, but knew > "$1$" meant "MD5". BTW, I chose MD5 precisely because I see that used for > the bulk of the passwords in the NIS password database where I work. "$1$" refers to md5crypt. You might be confusing raw MD5 and md5crypt. There's roughly a 1000 times difference in performance between the two, and md5crypt is salted. Unlike raw MD5, md5crypt was in fact intended for password hashing back when it was introduced in 1994. (Yet md5crypt has been declared end-of-life by its designer in 2012, since attacks on it became too fast and since we have better password hashing methods now.) > Obviously, I have no control over the hashing [...] used by my systems. If those systems are yours, then technically you have control, but you might not want (and know how) to deviate from the system vendors' supported settings and code. > My intent is mostly > to consider how difficult it might be to guess/construct passwords my tool > generates. The extent to which the hash algorithm chosen slows that down is > mostly a secondary consideration. The speed differences between hash types affect how many words you need to include in a passphrase. Well, not with a 32-bit seed. > While I use polly to generate my own passwords > and am obviously concerned that I choose good passwords, the fact that I > tossed the code up on GitHub implies that someone else might stumble upon > it and decide to use it. It thus makes sense to me that I do what I can to > minimize the chance that others might be negatively affected by bugs in my > tool. Yes, that's a responsible thing for you to do. I suggest that you add a "don't use this" warning to polly for now. I hope my (somewhat harsh) criticism is OK with you. Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.