[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
