[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANc-5UzwWCk3shBVUWDjWaXh=3QNeR-XpWGoqoviv2T8=m92Dg@mail.gmail.com>
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.
