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.