[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100824100947.GA29825@openwall.com>
Date: Tue, 24 Aug 2010 14:09:47 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Defcon18 "Crack Me If You Can" Complete Pot File
On Tue, Aug 24, 2010 at 12:30:56AM -0400, Charles Weir wrote:
> ... I'm making the .pot file available at:
>
> https://sites.google.com/site/reusablesec/Home/random/KoreLogic_Defcon2010.pot
Thanks!
> ... some of the
> salted hashes were already cracked from the competition so I did not
> attempt to re-crack them, (though they are all in the downloadable
> .pot file).
I think this was a mistake. You have some DES-based hash passwords with
8-bit chars, which obviously don't fully match Kore's plaintexts. This
makes further processing and analysis a bit more difficult (need to drop
the 8th bit before matching against Kore's plaintexts, wordlists, rules).
> Against 1000 Oracle10 password hashes it took 1 minute and 28 seconds,
> with me making 260645 c/s
1.7.6-jumbo-7, which has the "--salt-list" bug corrected, cracks these
in under a second.
Curiously, one of the Oracle passwords is only found in Kore's
oracle.txt, but not in their all_passwords.txt. This password has an
embedded control character (^G or BEL), which probably confused Kore's
own processing of password lists. (And it is not the only occasion when
Kore's own processing was affected by their "disruptive" passwords.
To give another example, the total number of LM hashes as posted on the
stats page - "Teams were able to crack 2362 LM password hashes. 0 were
left uncracked" - is off by about 200.)
> Against 80 Blowfish hashes, it took me 3 hours and 36 minutes to crack
> them all, with me making 200 c/s
>
> Against 4077 Crypt-MD5 hashes it took 10 hours and 10 minutes to crack
> them all, with me making 3228 c/s
These speeds are too low for your computer, even considering that you
probably used a non-optimal JtR build again (32-bit instead of 64-bit).
Most likely, you had the laptop set to a power saving mode, lowering the
CPU clock frequency to around 1.2 GHz.
At full CPU clock speed (2.2 GHz as you mentioned) and with a 64-bit
build, you'd be at around 500 c/s and 9000 c/s for these two,
respectively. Making use of both CPU cores would double these (for the
Blowfish-based hashes you could do that by making an OpenMP-enabled
build; for the MD5-based hashes, you'd need to run two instances).
With Simon's "SSE intrinsics" patch (from the wiki), you'd get up to
around 20k c/s for the MD5-based hashes per core, 40k c/s total
(assuming that you use very recent gcc or clang; icc would provide
additional speedup, but you'd be unlikely to use it for your build).
> What this really brings home is how important hash type is to the
> cracking session. There's been a lot of talk in the news lately how
> GPU password crackers will soon force everyone to choose 12 character
> passwords:
>
> http://www.bbc.co.uk/news/technology-10963967
I find these news stories misleading. They talk about password security
out of context. Online attacks or offline? What hash types?
(Apparently, they only consider offline attacks against fast hashes, but
they fail to mention it.) Why not use GPUs for password hashing
(authentication) on servers eventually, to increase the computational
complexity of validating a password and thus of testing a candidate
password in an attack? Am I truly the only one considering this? Well,
not after this posting for sure.
> While team HashCat showed GPU password crackers are extremely
> effective, (and I'm still in awe of their work), even a 10x speedup
> against Crypt-MD5 hashes would only allows me to make ~30k guesses a
> second. That's compared to the 328296K, yes that's 328 MILLION guesses
> a second I'm able to make against NTLM password hashes on my laptop.
In general, I fully agree with you, but I'd like to point out that your
numbers are "a bit" off for a number of reasons. For NTLM hashes, you'd
actually get a lot higher "effective" combinations per second speed for
a longer run against this many hashes (you'd get around 30 billion
combinations per second, although this speed will be decreasing as some
passwords will be getting cracked). On the other hand, the "raw" speed
measured in candidate passwords per second is lower than what you report
(it's on the order of 10M candidates per second, although this is
considering the total number of loaded hashes and the use of only one
CPU core).
> And that completely ignores the effect that the password salt has when
> auditing large lists.
No, JtR's c/s rates reported while cracking do not ignore that... or did
you mean password hash lists larger than those we were given in the contest?
The primary reasons why you only got around 300M effective c/s for NTLM
instead of the expected 30G effective c/s (which I've just confirmed
in practice on an incremental mode run locked to length 8) were that
your run was so short (under 1 second) and that it cracked so many
passwords (so the number of hashes left to crack was decreasing, thereby
also decreasing the number of combinations tested per hash computation).
> So once again, thanks to KoreLogic for running this competition, and I
> can't wait for the next one at Defcon 19!
I second that, although it'd be non-trivial for Kore to come up with a
new password list. This time, they had the password list tied to their
unreleased word mangling rules - but next time it should probably be
different. Perhaps the passwords will need to be more real-world'ish,
yet not real.
Thanks again,
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.
