[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160811100331.GA8526@openwall.com>
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.
