Slashdot Mirror

Yes! As the other poster said, account database dumps are commonly broken through brute force attempts. The tools to reverse hashes are not some "super secret cracker-only-thing either, hashcat is the best password-hash reversing brute force tool. It's free and open source and on the right hardware can have amazingly, absurdly, performant performance.

sounds like too much work, can't we just extract them from system logs. For some reason (god knows why), writing passwords into logs seem to be a trend now.

Yes! As the other poster said, account database dumps are commonly broken through brute force attempts. The tools to reverse hashes are not some "super secret cracker-only-thing either, hashcat is the best password-hash reversing brute force tool. It's free and open source and on the right hardware can have amazingly, absurdly, performant performance.

Already thought of.

https://hashcat.net/wiki/doku....

Look at this discussion of attacking 1Password for an example of poor use of a crypto library. The guy from the company behind this keychain tool genuinely wants to make it safe but they have made critical mistakes in their usage that leave it painfully vulnerable. When they get it right I'd consider them but right now they have too much to learn to trust them.

> primarily because he couldn't get people interested in it.

Probably because the topic doesn't sound all that interesting with current multi-cores except to the hard-hard-core computer geeks. :-/ While most geeks love Chess & Go I don't see too many interested in how to "solve" it.

I image once we have Intel's Knight's Corner ( http://en.wikipedia.org/wiki/Intel_MIC ) common place interest might pick up again.

The other possibility would be to move it onto the GPU like the password crackers do now-a-days. (i.e. HashCat http://hashcat.net/oclhashcat-plus/ )

I fully expected a comment just like yours. :-) hashcat is in fact superior in many ways, but JtR is superior in many others. In the context of this story, since when does hashcat support sha512crypt and bcrypt on GPU? Last time I checked (just before releasing JtR 1.7.9-jumbo-6), it did not. I've just re-checked - as far as I can see, it still does not. So hashcat could not possibly be used for the comparison that this story is about, at this time.

My guess, based on recent hashcat user polls and atom's comments on the forums (yes, I sometimes skim over the topics), is that atom will in fact add support for sha512crypt on GPU soon (especially now that JtR has it, and hashcat "got to" compete and show a better speed, which it likely will) - in fact, even reusing our code is possible since we've BSD-licensed that portion, but I doubt that atom would do that. I am less certain about bcrypt. BTW, atom's expectation, stated on their forums, was that sha512crypt would be only 2-3 times faster on GPU than it is on CPU. We achieved 5.5x, which is thus not bad. Admittedly, the CPU code could be rewritten to use SIMD and be roughly twice faster - thereby bringing us to the 2-3x expectation.

Also, some of us prefer Open Source, even if in some aspects a given implementation is inferior at a given time. Besides the current preferences/beliefs, guess what happens in case at some point atom loses interest in further hashcat development and does not release the sources under an Open Source license - or if something bad happens (I hope not!) preventing him from being able to do that? So far, hashcat is only ~2.5 years old and it is proprietary. (And yes, I am very impressed by what atom did in just 2 years.) John the Ripper has been around since 1996 and it is Open Source. BTW, this difference also means that hashcat can freely borrow low-level implementation ideas from us if atom wanted to (although I think he's good enough on his own not to use this option), whereas hashcat's EULA (as of the last time I checked, which was a long while ago) prevents us from doing the same even via reverse-engineering if we wanted to (although apparently this is not enforceable in many jurisdictions or in case the person never accepted the EULA; no, we don't rely on that and we don't RE hashcat).

Anyhow, I don't think there would be any issue in having a hashcat-focused news story if you or someone else posts one at a right time. :-)

But hashcat still does it faster.

Ha, that site says "Offline Fast Attack Scenario: (Assuming one hundred billion guesses per second)". One hundred billion hashes per second?! That's a little optimistic! Hashcat gets around 1-10 billion characters per second using high end GPUs! That's like 2 or 3 orders of magnitude off!

http://hashcat.net/oclhashcat/ runs numerous tools for this and with some users GPU rigs going totally insane: 4 x ATI Radeon 6990 throwing MD5 hashes out @ 45.7 Billion/sec, that's mixalpha-numeric password of length 8 in 1 hr 20 mins and then we can start on the dictionaries / hybrib-dictionaries / case-mutations / etc. The way passwords are used / stored is becoming broken by design.