[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150107084827.GA2887@openwall.com>
Date: Wed, 7 Jan 2015 11:48:27 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: PRINCE approach from hashcat
On Tue, Jan 06, 2015 at 11:40:55AM -0500, Matt Weir wrote:
> If you can make less
> than 100M guesses it seems like you are still in the area where dictionary
> attacks are a better bet than PRINCE or Incremental.
Surely 100M is small enough that you can put this many "words" in a text
file, and yes wordlists are a better bet, but in an optimal attack some
of those 100M would need to come from a mode like incremental or PRINCE
anyway, as well as the more common keyboard-based combinations and such.
When I started experimenting with this stuff in 1994-95, I was able to
crack some non-word-based passwords with what later became JtR's
incremental mode. Those passwords were not crackable with wordlists of
the time and programs such as Crack (with its default rules) and Cracker
Jack. In fact, this provided much of the motivation to create JtR.
At the time, a few thousand c/s at descrypt, such as on an early Pentium
or an Alpha, was a great speed. (I later improved it to 10k c/s on a
Pentium-120 for JtR, in part due to Pentium optimization hints from
Roman Rusakov, and to 30k c/s on a DEC Multia VX40 by 1997, just before
finally switching to bitslice DES for ~200k c/s on newer Alphas in 1998.)
Faster hashes such as raw MD5 were not yet in use (no web apps yet).
So, going at ~3k c/s with C code on a fast machine in 1994-95 against a
bunch of descrypt hashes with different salts, how many passwords can
one reasonably test? This is ~260M hashes computed per day, but with,
say, 1000 different salts (out of a maximum of 4096), we're down to ~260k
different candidate passwords tested per day. Give it a month, and
we're still at only 8 million. Yet it was not only wordlist+rules, not
even at these seemingly low candidate password counts.
My point is that it _does_ make sense to try non-wordlist+rules
passwords even for under-1M candidates runs (against slow hashes), let
alone 100M.
RockYou's plaintext leak, and in general availability of better password
cracking wordlists, has probably changed this somewhat (some previously
not wordlist-crackable passwords now are), but not to an extent where we
should completely disregard other than wordlist+rules candidates when
attacking today's slow hashes. For example, testing RockYou top 1M plus
first 100k of JtR incremental candidates may very well provide better
results than testing RockYou top 1.1M. (It'd be curious to try this.
I don't know what the optimal mix really is, and of course it will vary
across different sets of target password hashes.)
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.
