Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Encryption Security Unix AMD IBM Software Wireless Networking Linux

John the Ripper Cracks Slow Hashes On GPU 61

solardiz writes "A new community-enhanced version of John the Ripper adds support for GPUs via CUDA and OpenCL, currently focusing on slow-to-compute hashes and ciphers such as Fedora's and Ubuntu's sha512crypt, OpenBSD's bcrypt, encrypted RAR archives, WiFi WPA-PSK. A 5x speedup over AMD FX-8120 CPU per-chip is achieved for sha512crypt on NVIDIA GTX 570, whereas bcrypt barely reaches the CPU's speed on an AMD Radeon HD 7970 (a high-end GPU). This result reaffirms that bcrypt is a better current choice than sha512crypt (let alone sha256crypt) for operating systems, applications, and websites to move to, unless they already use one of these 'slow' hashes and until a newer/future password hashing method such as one based on the sequential memory-hard functions concept is ready to move to. The same John the Ripper release also happens to add support for cracking of many additional and diverse hash types ranging from IBM RACF's as used on mainframes to Russian GOST and to Drupal 7's as used on popular websites — just to give a few examples — as well as support for Mac OS X keychains, KeePass and Password Safe databases, Office 2007/2010 and ODF documents, Firefox/Thunderbird/SeaMonkey master passwords, more RAR archive kinds, WPA-PSK, VNC and SIP authentication, and it makes greater use of AMD Bulldozer's XOP extensions."
This discussion has been archived. No new comments can be posted.

John the Ripper Cracks Slow Hashes On GPU

Comments Filter:
  • PBKDF2 (Score:5, Insightful)

    by slackergod ( 37906 ) on Wednesday July 04, 2012 @04:49PM (#40544483) Homepage Journal

    I find it kind of odd that all of the analyses linked to in this article go on about SHA512-Crypt, BCrypt, SCrypt, etc, and the slideshow even talks about "Key Derivation Functions"... yet there doesn't seem to be any mention or comparision of PBKDF2-HMAC-SHA512 as a valid password-hashing key derivation function, despite it's widespread use, and that it's one of the core architectural components used in the design of SCrypt.

    • Re:PBKDF2 (Score:5, Interesting)

      by solardiz ( 817136 ) on Wednesday July 04, 2012 @05:07PM (#40544633) Homepage

      You make a valid point. I do intend to add a mention of PBKDF2 to a revised version of my presentation, and I am likely to use it or at least HMAC as a component if I design a new password hashing method - not so much because of actual need, but mostly to have an easy and convincing answer about cryptographic security. ;-) However, in the context of this announcement PBKDF2 is arguably less relevant, and it is inferior to the alternatives being considered specifically in the GPU-friendliness aspect (it is more GPU-friendly than all three of SHA-crypt, bcrypt, scrypt). In scrypt, PBKDF2 is used (with SHA-256) to provide/demonstrate cryptographic security, but mostly not computational cost, whereas the analysis here is about the latter, under assumption that all of the alternatives being seriously considered are sufficiently secure cryptographically.

      This release of John the Ripper supports PBKDF2 on GPU as well - in the included WPA-PSK cracking code. The release announcement shows a 27x speedup over the also-included CPU code when going from FX-8120 CPU (8 threads) to HD 7970 GPU for WPA-PSK cracking (PBKDF2-HMAC-SHA-1), which clearly shows that it is very GPU-friendly. With SHA-512, it'd be a lot less GPU-friendly, but likely not even to the point of sha512crypt.

      • by Anonymous Coward

        What about storing the SRP verifier:

        s = salt
        p = password
        H() = a hash function, e.g., SHA-256, PBKDF2, etc.

        x = H(s,p)
        v = g^x

        Store v and s. Anyone that can get at x by breaking Diffie-Hellman will make quite a news splash (but still won't get your password because of the hashing).

        • Re:PBKDF2 (Score:5, Informative)

          by solardiz ( 817136 ) on Wednesday July 04, 2012 @07:25PM (#40545659) Homepage

          SRP is great, but it does not eliminate the need for better password hashing - rather, these things may/should be used together. It does not take breaking DH to merely probe candidate passwords against a stolen/leaked SRP verifier. The Wikipedia article you referenced says that "using of functions like PBKDF2 instead of H for password hashing is highly recommended", and they were referring to the password stretching aspect. Other properties of the hashing method are also relevant, just like they are to "regular" password hashes.

          In fact, I complained [] to Tom Wu about SRP's use of non-iterated SHA-1 in 2000, and I had an e-mail exchange on a similar topic in SPEKE context with David Jablon in 1998 or so. Since then (or at about that time), the need for heavy to compute underlying hashes even along with zero-knowledge password proofs became widely recognized. I am not really into the latter topic, but I did my little bit to influence that field in that minor aspect (and I'm sure many others did as well).

    • Re:PBKDF2 (Score:4, Interesting)

      by JonySuede ( 1908576 ) on Wednesday July 04, 2012 @05:20PM (#40544735) Journal

      according to that link [] PBKDF2-HMAC-SHA512 is, when implemented correctly; as an example of bad implementation see that microsoft blog post [] about .NET 2.0 (we are at 4). A good place to start is to understand that jargon is RFC 4868 [] as it has almost all the links to the pertinent material.

      • BTW the Microsoft implementation failure is foremost a compliance and interoperability issue, we do not know about it's security impact, we can only presume bad things as we always should when face to unknowns qualities in the domains of computer security.

      • The design of PBKDF2, and the NIST publication you referenced, do not consider the difference in processing cost to defender vs. attacker, whereas that is precisely the aspect I've been focusing on in my analysis. PBKDF2 does nothing to bring the validation vs. cracking speed ratio [] close to 1.0.

        • I was not arguing with you, I was giving reference material to understand your slides are they are quite heavy if you start without a good background knowledge of that obtuse domain.

  • Hopeless situation (Score:5, Insightful)

    by Kergan ( 780543 ) on Wednesday July 04, 2012 @09:09PM (#40546503)

    The real issue isn't so much the hashing algorithm used than it is the bloggers.

    An adaptive algorithm (one that can be made to go slower by tuning the number of cycles) such as bcrypt, and as opposed to sha, is arguably much better.

    In the end, however, the real problem is the huge number of self-proclaimed experts with an opinion ranging from wrong to hopelessly wrong -- and a very big mouth. It wouldn't matter much if they were at least partially right (apart from the facts that, yes, do hash, and yes, do salt), but computer security is one of those fields where nearly no one actually understands what they're talking about. Don't believe me? Have the next security experts you meet explain encryption to you for a few good laughs.

    I like to compare this to PHP/MySQL. The MySQL module has been deprecated in favor of MySQLi for so long I dare not even think about it. Yet, pretty much every tutorial/answer out there uses the mysql_*() set of functions including, of all places, Stack Overflow. So here we are, with newbie coders learning from horrific examples, and then viewing spaghetti code bases like WordPress as best practice. And then they write their own PHP/MySQL tutorial on their own blog, and the 5 years later some newbie reads it, perpetuating the vicious circle. The next step is the same PHP/MySQL newbie wanting to secure his app, learning from poor examples and advices, and propagating them in the exact same way.

    Anyway, the "use sha to hash passwords" BS and the inane salting strategies that invariably accompany them are here to stay for a long time, because the Internet has a very, very, very, very long memory.

    • by kantos ( 1314519 )

      Sometimes I wish we could mod up beyond 5

      The fact of the matter as the parent post makes is that insecure password storage is a far larger issue, many many sites just store the passwords plaintext in a DB. If you're lucky they are bothering to use SHA1 on them first (without a salt). The website owner feeling smart adds salts but is still using SHA1 and a single round of hashing (cracking complexity... trivial). A real smart one decides he's going to use multi-round hashing, and perhaps even a stronger hash

    • bcrypt rules. Algorithm design wins against brute force.

  • I've been curious how a hash looks with respect to various lengths of a password. Is a hashed 3-character password 3 characters long, i.e. does the hashed password itself indicate how long the password is? Is it filled to a particular length?

    I'd be grateful for some insight about it looks / works.

    • In general, hash results are a fixed length.

      MD5 hashes always look like the following:
      $ echo -n "password" | md5sum
      5f4dcc3b5aa765d61d8327deb882cf99 -

      SHA1 hashes always look like:
      $ echo -n "password" | sha1sum
      5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 -

      No matter what input you give, SHA1 and MD5 hashes are always the same length:

      $ echo -n "short" | sha1sum
      a0f4ea7d91495df92bbac2e2149dfb850fe81396 -
      $ echo -n "Really Long Password" | sha1sum

Any sufficiently advanced technology is indistinguishable from a rigged demo.