Date: Thu, 11 Aug 2016 13:03:31 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: How long should I let JtR munch? On Wed, Aug 10, 2016 at 09:18:21AM -0500, Skip Montanaro wrote: > I'm using JtR simply as a test tool to compare the effectiveness of various > parameter choices in an XKCD936-based password generating program I've > written, polly <https://github.com/smontanaro/polly>. I don't think there > is anything particularly earth-shaking in my program, but I just wanted to > make sure I wasn't making some sort of fatal mistake in my assumptions > about how good it might be. So, I downloaded and built JtR. You won't literally make sure there's no fatal mistake in your assumptions by running JtR. You might only find out that there is. In general, trying a specific set of attacks (on anything, not just passwords) can only potentially prove vulnerability (although you'd also need statistics to differentiate that from poor luck). It can't prove lack of vulnerability. (But it can improve the confidence.) There might always be another attack you had not tried yet. That said, doing what you can to find possible mistakes makes sense. > I fed it a few raw MD5 encrypted passwords yesterday. That's fine (and it's "hashed", not "encrypted"), but JtR also supports "cracking" of plaintext passwords specifically for experiments like yours. It'll run a bit faster against the plaintexts - but just a bit, since raw MD5 is so fast. To use this support in jumbo, as long as your passwords don't contain certain special characters, simply prefix them with "$0$", like this: [solar@...er run]$ cat pw $0$password [solar@...er run]$ ./john pw Using default input encoding: UTF-8 Loaded 1 password hash (plaintext, $0$ [n/a]) Warning: no OpenMP support for this hash type, consider --fork=32 Press 'q' or Ctrl-C to abort, almost any other key for status password (?) 1g 0:00:00:00 DONE 2/3 (2016-08-11 12:30) 3.125g/s 406.2p/s 406.2c/s 406.2C/s 123456..karen Use the "--show" option to display all of the cracked passwords reliably Session completed Alternatively, you may use "$dummy$" followed by hex-encoded password. > JtR has now been > running for about 18 hours (--fork=4) and has yet to crack any of them. My > machine is just a quad-core Intel Xeon (3.1ghz). Is there some way to > compare it with some faster machines using their graphics cards? Is it > possible to say something like, "if it doesn't complete in 24 hours on my > machine, it would be the equivalent if not completing in N hours (N < 24) > on a more studly machine?" You're running at about 100M p/s. A high-end GPU could be roughly 100x faster than that when targeting a raw MD5 hash, but there's no implementation on a GPU of this exact cracking mode you're running, so it's not a direct comparison. (OTOH, the cracking mode you're running is not necessarily optimal for attacking your passwords.) Far more importantly, this is a wrong question for you to ask, unless you expect that your users will actually have raw MD5 hashes yet want to try and use strong passwords along with this inappropriate hash type. (MD5 was never meant for direct use for password hashing. Any such use was always a misuse, even if very common.) A more appropriate question would be: how long would an equivalent run take against a proper password hashing function, such as bcrypt, scrypt, or Argon2 with reasonable settings? If we assume a speed of, say, 10k hashes per second, that's 10k times slower than your attack. So your 1 day would correspond to 10k days, or 27 years. Whether 10k/s is the correct speed figure to use depends on what target defensive and offensive setups you have in mind. It's perfectly fine to use a much faster hash for testing, like you did. No reason for you to run an attack for years when you can simply use a faster hash. (And you can even use plaintext to simulate an attack.) Also, it's fine for you to use a saltless hash (or plaintext) like you did, but you should also want to take advantage of that by running the attack against a large number of hashes (or plaintexts) at once. Like against a million of them. Then consider that a real password hash will use salts, slowing down the attack on multiple hashes accordingly. > Finally, on a related note, is there some way to > tell which mode it's in? It's just running like this: > > ./john --format=Raw-MD5 --fork=4 ~/tmp/sample.txt > > I believe it will automatically work its way through the various modes > <http://www.openwall.com/john/doc/EXAMPLES.shtml> it has. How do I know > what mode it's in at any given time? Here's recent status output: > > % ./john --status > 1 0g 0:18:08:50 3/3 0g/s 24709Kp/s 24709Kc/s 123549KC/s > 2 0g 0:18:08:50 3/3 0g/s 24371Kp/s 24371Kc/s 121858KC/s > 3 0g 0:18:08:50 3/3 0g/s 24664Kp/s 24664Kc/s 123322KC/s > 4 0g 0:18:08:50 3/3 0g/s 25029Kp/s 25029Kc/s 125148KC/s The 3/3 means that it's running in mode 3 out of the 3 that it goes through when you didn't specify a mode. It went through the first 2 in under a second since your hash is so fast and your wordlist and ruleset are tiny. So it's running in incremental mode now, producing candidate passwords based on character frequencies recorded in ascii.chr. The candidate password lengths for this mode are by default limited to 0 to 13 characters. So if your password is longer than 13, it won't ever be cracked despite of this mode running effectively forever. (You can raise the length limit to higher than 13 in john.conf, up to 24, but we chose 13 as it appeared optimal when targeting real-world human-chosen passwords with this cracking mode in our testing.) What you might want to do is: 1. Generate a million of test passwords, encode them as $dummy$ hex (if weird characters are possible) or as $0$ plaintext. 2. Obtain some assorted wordlists, use jumbo's "--rules=all". http://www.openwall.com/passwords/wordlists/#links 3. Also consider generating a second (separate) one million (or bigger) training set, and generating and using a custom .chr file from it, so that you'd test an attack somewhat-targeting (in an automated and preprogrammed manner only; a human or AI could do better) specifically your password generation algorithm. 4. After running such attacks for e.g. an hour each and noticing the speeds and numbers of cracked passwords, extrapolate to different speeds (e.g. from 1 per second to billions per second and beyond - all of these are realistic speeds for different scenarios) and to salted hashes: http://www.openwall.com/presentations/Passwords12-The-Future-Of-Hashing/mgp00009.html I hope this helps. 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.