Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Aug 2016 10:56:47 -0500
From: Skip Montanaro <skip.montanaro@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: How long should I let JtR munch?

Alexander wrote:

> 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.

Yes, understood. 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).

>> 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:

Ooh, much better. 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.

> 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.)

Thanks. Point taken. Obviously, I have no control over the hashing (yes,
sorry for the use of "encryption") used by my systems. 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. I seems that raw passwords would be
better for my needs. I actually do want JtR to run as fast as possible.

> 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.

Yes, it most certainly does. I appreciate all the patient guidance I've
received here as a newcomer. 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.

correct-horse-battery-staple-ly y'rs,

Skip

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.