John the Ripper Cracks Slow Hashes On GPU

← Back to Stories (view on slashdot.org)

John the Ripper Cracks Slow Hashes On GPU

Posted by Soulskill on Wednesday July 4, 2012 @08:38AM from the doing-it-with-style dept.

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."

61 comments

Min score:

Reason:

Sort:

Thanks for the update by Anonymous Coward · 2012-07-04 08:46 · Score: 0

Time to change the combination on my luggage!
1. Re:Thanks for the update by Svippy · 2012-07-04 09:08 · Score: 1
  
  Hey, 666 is too obvious, they are never gonna guess that!
  
  --
  Clicked pie.
2. Re:Thanks for the update by Exrio · 2012-07-04 09:56 · Score: 1
  
  Sometimes it works. A few ages ago a friend gave me his old cellphone - one of those Samsung "Slim Line" ones - but at the moment it was uncharged; when I got it charged it turned out it was locked, I didn't have the password and couldn't get a hold of him to ask, so I figured 4 numbers couldn't be that hard and tried my best to guess. I couldn't. Fast-forward one week and I finally get around to asking him about the password.. What was it? 8888. The worst part is that I did try just enetering the same number, but stopped at 5555 because I thought "he can't be that naive". LOL
3. Re:Thanks for the update by Anonymous Coward · 2012-07-04 22:56 · Score: 0
  
  That is only true for the phone's SIM PIN. For the phone's OS PIN, you can often choose how many attempts will cause a lock-out, phone-wipe, et cetera.
PBKDF2 by slackergod · 2012-07-04 08:49 · Score: 5, Insightful

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.
1. Re:PBKDF2 by solardiz · 2012-07-04 09:07 · Score: 5, Interesting
  
  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.
2. Re:PBKDF2 by JonySuede · 2012-07-04 09:20 · Score: 3, Interesting
  
  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.
  
  --
  Jehovah be praised, Oracle was not selected
3. Re:PBKDF2 by JonySuede · 2012-07-04 09:24 · Score: 1
  
  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.
  
  --
  Jehovah be praised, Oracle was not selected
4. Re:PBKDF2 by solardiz · 2012-07-04 09:45 · Score: 2
  
  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.
5. Re:PBKDF2 by Anonymous Coward · 2012-07-04 10:04 · Score: 1
  
  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).
  http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
6. Re:PBKDF2 by JonySuede · 2012-07-04 10:47 · Score: 2
  
  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.
  
  --
  Jehovah be praised, Oracle was not selected
7. Re:PBKDF2 by Anonymous Coward · 2012-07-04 10:49 · Score: 0
  
  s/are/as
8. Re:PBKDF2 by solardiz · 2012-07-04 11:25 · Score: 5, Informative
  
  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).
useless for strong passwords by Anonymous Coward · 2012-07-04 09:06 · Score: 0

Sure, John the Ripper will crack dictionary passwords and passwords used by idiots (e.g. spaceballs12345), but it will not crack an 90+ bit random password (e.g. a 16-digit mixed-case alphanumeric is 95 bits, and it's really not that hard to memorize).
Lesson of the day: Use STRONG passwords. Everywhere.
1. Re:useless for strong passwords by O('_')O_Bush · 2012-07-04 09:16 · Score: 3, Insightful
  
  One? Sure. I probably keep 50 of them, under various usernames. The hard part is remembering them all, without some easy to guess formula. That is why passwords are often reused, which is far more dangerous than password weakness.
  
  --
  while(1) attack(People.Sandy);
2. Re:useless for strong passwords by solardiz · 2012-07-04 09:26 · Score: 5, Interesting
  
  The fact that not every password is likely to be cracked is precisely what makes password security audits with John the Ripper useful. If every password would be getting cracked, there would be fewer legitimate uses for the tool. ;-)
  Memorizing one 16-digit mixed-case alphanumeric password is realistic, but it does not help you all that much unless it's a "master password" (e.g., used to access an encrypted password manager database or to generate other passwords from or to access an encrypted filesystem where you store other passwords in plaintext), because you'd have difficulty memorizing a large number of unique and dissimilar passwords of this kind. Either way, if you're developing a server application or administering a server where users can register with passwords (maybe as one of the authentication options, not necessarily the only one), it becomes sort of your responsibility to make your users' passwords less likely to be cracked, even if the server security is temporarily compromised (you should assume that this might happen). Note that many of your users' passwords might be weaker than you would have liked them to be, and you don't want to enforce too strict a password policy (as that's a tradeoff). This is where the choice of hashing method to use matters, letting you use a less strict password policy for the same level of security or/and resulting in fewer passwords getting cracked (even with no enforced policy, since some people will choose medium complexity passwords on their own).
3. Re:useless for strong passwords by Anonymous Coward · 2012-07-04 09:27 · Score: 1
  
  Memorize the important ones. Store the rest in a vault guarded by a key and a strong password that you memorized.
4. Re:useless for strong passwords by UnknownSoldier · 2012-07-04 09:45 · Score: 1
  
  Oblg.
  http://xkcd.com/936/
5. Re:useless for strong passwords by solardiz · 2012-07-04 10:01 · Score: 3, Interesting
  
  I am all for passphrases. We've been supporting them in our passwdqc password/passphrase strength checking and policy enforcement tool (initially just a PAM module, then more) since I wrote it in 2000.
  Implementation detail: when enforcing passphrase policy, we need to insist on some separators between words being present. passwdqc does, in order for the string to quality as a passphrase rather than password. Apparently, Dropbox does not, and I think that's a flaw. No wordlist can be comprehensive, and a separator-less passphrase is indistinguishable to a password/passphrase strength checker from a long and somewhat obscure dictionary word. Indeed, any passphrase (or a multi-word portion of it) can happen to be found in a dictionary (or on the web, etc.) as well - or just be reused by the user across multiple sites - but that's a somewhat different issue.
6. Re:useless for strong passwords by fatphil · 2012-07-04 11:19 · Score: 1
  
  true donkey charge pin
  [fail]
  right mule pinch cell
  [fail]
  accurate energy ass probe
  [fail - locked out]
  
  Quite why people think that 'correct horse battery staple' is more memorable, in particular because of the visual imagery it evokes, than something that isn't 4 simple words, I will never understand. You have a fashion, that's all, but you will grow out of it.
  
  --
  Also FatPhil on SoylentNews, id 863
7. Re:useless for strong passwords by solardiz · 2012-07-04 12:01 · Score: 4, Informative
  
  I've been using passphrases for about 12 years (and more than that if we count those passphrases on PGP and SSH keys as well), and I'm not growing out of it yet. I often use mixed-character-type passwords as well, and my phrases often use weird word separators, misspelled and/or partial words (less typing, same or better security if you do it right), different languages, etc. The number of words also varies (but with too few words other bits of complexity have to be introduced). For me, what is easier or harder to memorize varies depending on what kind of suitable idea I happen to have at a given time. Besides, the variety in password/phrase types buys me a few extra bits of entropy. Even an attacker who has read this comment or cracked a few of my passwords somewhere doesn't come up with one single pattern on password type that I use - because there are many. Thus, let your users choose between short but complicated passwords and longer but less complicated phrases. Similarly, let them choose between server-generated strings and user-chosen ones (the latter may be subject to policy enforcement). Our passwdqc tool set (PAM module, library, program for use from scripts) gives all of these options by default (but they can be disabled in any combination...) For server-generated strings, passwdqc uses 3-word phrase-like ones, with non-whitespace separators (out of a set of 8) and random word capitalization by default - that's 47 bits, which is currently sufficient in most user authentication contexts when used along with bcrypt hashes. With 4 words and the same approach, it's 64 bits ("pwqgen random=64" will do that) - but that is rarely needed with a decent password hash. (It is reasonable for data encryption keys, though - plus some 20 bits of stretching with a decent KDF.)
8. Re:useless for strong passwords by Anonymous Coward · 2012-07-04 12:07 · Score: 1
  
  Guide the user to select an arbitrary separator unique to the pass phrase in question. Memorable separators have meaning to the selecting person.
9. Re:useless for strong passwords by solardiz · 2012-07-04 12:21 · Score: 3, Informative
  
  On a serious note, entropy grows with length less than linearly, and you've provided a good example of that. This means that there's little point in using a passphrase this long. A replacement for yours could be: "cannon to R,L,F of them Volley'd and thunder'd" - perhaps about as easy (or as difficult) to memorize and recall reliably, likely roughly the same guessing entropy, but much shorter to type.
10. Re:useless for strong passwords by Jane+Q.+Public · 2012-07-04 12:35 · Score: 1
  
  "Quite why people think that 'correct horse battery staple' is more memorable, in particular because of the visual imagery it evokes, than something that isn't 4 simple words, I will never understand. You have a fashion, that's all, but you will grow out of it."
  People think it because studies have repeatedly and clearly shown it. It's the way the typical human brain operates.
  
  If yours operates differently, you are not typical. That is all.
11. Re:useless for strong passwords by Anonymous Coward · 2012-07-04 12:42 · Score: 0
  
  easier still: c2RlfV&t
12. Re:useless for strong passwords by solardiz · 2012-07-04 13:03 · Score: 2
  
  Sure, but fully going from a passphrase to a phrase-derived short password likely reduces guessing entropy (not the same thing as Shannon entropy, by the way; the latter is even more obviously reduced, but is less relevant). In fact, I think some of the passwords that JtR cracks in its incremental mode (which considers character frequencies) are actually built using the first-letter-of-each-word method. Indeed, many of those passwords will happen to use a subset of possible characters only - those that are more common as first letters of words. In your example, this is defeated by the use of non-letters and capital letters (which may be less frequent than even the least frequent lowercase letters at these character positions), but still. Overall, I think c2RlfV&t would be a decent password for many kinds of uses (if you did not post it, indeed), but it would not provide equivalent security to that of the original passphrase (if that one were not posted as well).
13. Re:useless for strong passwords by Burz · 2012-07-04 13:07 · Score: 1
  
  Why not just require a password of a minimum size (say 25 char) and a couple of punctuation chars, and a certain minimum entropy... and call it a 'passphrase'? Whether or not dictionary words are allowed, what matters is overall complexity (i.e. char sequences aren't repeated) and you don't need to reference a dictionary.
14. Re:useless for strong passwords by JoeMerchant · 2012-07-04 13:12 · Score: 2
  
  I have started non-reusing my passwords since I have implemented a "shared vault" - the user names/passwords are encrypted and hidden in a file that is shared across my various machines using a cloud mirroring service (e.g. Dropbox).
  Dropbox security by itself is not terribly comforting, but the combination of my own memory-hard crypto inside the Dropbox system at least feels better. Having the "important" file shared means I have access to my secrets wherever I am, and it's harder to accidentally wipe out the file.
  Perfectly secure? No - especially if I talk about it like this. Better than reusing the same password everywhere? I think definitely.
15. Re:useless for strong passwords by JoeMerchant · 2012-07-04 13:17 · Score: 1
  
  Shameless plug: The crypto in StegaMail isn't unbreakable, but it is memory hard (you have to process the entire image to brute force guess passwords - encode in a big image and lots of memory is required), and I liken steganography to hiding your money in a false soda can in the fridge - hide in plain sight. Breakable? Sure. Likely to be broken in a mass trawl of data? Not.
  Other than "playing spy" - hiding passwords is the best use I have found for steganography.
16. Re:useless for strong passwords by solardiz · 2012-07-04 13:21 · Score: 1
  
  Yes, you don't need to reference a dictionary when you approve something as a passphrase. passwdqc does not reference a dictionary for that. However, you mentioned requiring "a couple of punctuation chars" - and this almost ensures at least 3 words (well, it could also be e.g. a single word mangled by inserting/replacing characters, which is why I said "almost"). passwdqc has a similar requirement, although it does not insist on punctuation specifically. For non-repeats, passwdqc insists on there being enough different characters for the required minimum length (not for the actual length - there's no problem with some repetition if the minimum would be reached without those portions anyway).
17. Re:useless for strong passwords by Anonymous Coward · 2012-07-04 13:37 · Score: 0
  
  Can you translate what you just said to English?
18. Re:useless for strong passwords by Anonymous Coward · 2012-07-04 13:47 · Score: 0
  
  Frankly I think this is bad advice A 24 character password is OK, but 36 characters or more should be used for highest security.
19. Re:useless for strong passwords by Fjandr · 2012-07-04 15:31 · Score: 1
  
  http://xkcd.com/936/ fails.
  No, this is not a judgment on my part, just an exact translation of what the GP said.
20. Re:useless for strong passwords by fatphil · 2012-07-04 21:00 · Score: 1
  
  I'm not sure I've seen any independent study which investigates such questions satisfactorily. (You may interpret that as [citation needed].) And looking in from the opposite direction, I've also yet to see someone build a 4-simple-english-word rainbow table to directly attack the claim of security. Given that rainbow tables have made password recovery over much larger saerch-spaces possible, I think it's a worthwhile attack, even if purely from the theoretical standpoint (I mean, nobody actually uses 4 moderately common words as their password, do they?).
  
  Certainly, in the field of memory, I am prepared to believe I am far from the norm. I have an exceptionally poor memory for almost everything. During my academic career I could never remember high level theories or identities, and had to repeatedly derive them from basic principles before using them. Yet I have eidetic memory for several senses (but not the visual one). The brain is a funny thing.
  
  --
  Also FatPhil on SoylentNews, id 863
21. Re:useless for strong passwords by fatphil · 2012-07-04 21:17 · Score: 1
  
  Given that you commend only schemes which are not the one recommended by xkcd, I do not see any disagreement between us. In fact, given that you say "let them chose", we are in strong agreement. Different people will be most comfortable with different types of password, and a password that they're not comfortable with and is stored in a record in their cell phone, or is on a piece of paper in their wallet, is nowhere near as strong as one they can keep in their head.
  
  Most of my passwords have had a several-unconnected-words base for well over 20 years now, but always decorated so baroquely that most of the entropy's been in the decoration.
  
  --
  Also FatPhil on SoylentNews, id 863
22. Re:useless for strong passwords by Ginger+Unicorn · 2012-07-04 22:25 · Score: 1
  
  What's wrong with XKCD one? (geniunely curious)
  
  --
  (1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
23. Re:useless for strong passwords by Anonymous Coward · 2012-07-05 02:15 · Score: 0
  
  The fact that not every password is likely to be cracked is precisely what makes password security audits with John the Ripper useful. If every password would be getting cracked, there would be fewer legitimate uses for the tool. ;-)
  I know not everyone will agree, in some ways it's like the endless debate over gun control in the US, but...
  I don't care if there's a legitimate use for cracking tools -- it's still better to have them in the open where anyone can download and use them. Because if the only good cracking tools for a given crypto/hash are in elite blackhats' private toolboxes, then only reasonably high-value targets (which means very few targets) are at practical risk, so it seems safe, and everyone uses that crypto/hash. When every script kiddie can download high-end tools, and use them en masse for griefing web BBSes and such, instead of just the targeted attacks that are worth a pro's efforts, then the danger becomes apparent, and everyone (including the high value targets) will end up using better crypto/hash.
  Once the weapon exists, it's better to have it widely distributed than not. (Though, to be sure, legitimate password auditing probably helps justify to "helpful" government why they shouldn't just ban teh evil cracking tools...)
24. Re:useless for strong passwords by Sneftel · 2012-07-05 02:29 · Score: 1
  
  I'm not sure I've seen any independent study which investigates such questions satisfactorily. (You may interpret that as [citation needed].)
  Bessner and Davelaar, 1982. "Basic processes in reading: Two phonological codes."
  
  And looking in from the opposite direction, I've also yet to see someone build a 4-simple-english-word rainbow table to directly attack the claim of security.
  You don't need to count to 10^5^4 to know that it's a big number, far greater than the search spaces currently achievable with rainbow tables. Barring a monumental flaw in the hash function, the decreased per-character entropy shouldn't make a difference. (Though I guess it depends on how many "simple english words" you consider there to be.)
  
  Certainly, in the field of memory, I am prepared to believe I am far from the norm. I have an exceptionally poor memory for almost everything. During my academic career I could never remember high level theories or identities, and had to repeatedly derive them from basic principles before using them.
  With you on that one.
  
  --
  The opinions stated herein do not necessarily represent those of anybody at all. Deal with it.
25. Re:useless for strong passwords by fatphil · 2012-07-05 03:04 · Score: 1
  
  I see a 136GB rainbow table that claims to cover 99% of a 2^48 gamut..
  
  An alphabet of 100000 symbols is *waaay* bigger than what I consider "simple english words". 12 bits per word (4000 words) seems reasonable, and that comes in at 2^48 again. IIRC, xkcd itself quoted 2^44 from 4 simple words (so 2048 simple english words).
  
  I would argue from that data, which as you say might be based on an unsupportable premise, that we should not consider the xkcd recommendation as being clearly safe. I don't believe I'm stretching credibility too far by making that claim.
  
  The more words you throw in the dictionary, the more likely you are to (mis-)remember a synonym, I'm sure. Alas I can't find a readable copy of the paper you recommend (firefox/googlebooks give me nothing but blank pages currently), perhaps they address that, but I shall keep looking.
  
  --
  Also FatPhil on SoylentNews, id 863
26. Re:useless for strong passwords by fatphil · 2012-07-05 03:31 · Score: 1
  
  Expanded in another of my posts just a few minutes back - xkcd recommends 2^44 difficulty, but hackers are claiming they can crack 2^48 difficulty. (Some even more than that, it seems)
  
  --
  Also FatPhil on SoylentNews, id 863
27. Re:useless for strong passwords by TheTrueScotsman · 2012-07-05 04:35 · Score: 1
  
  It's not the words that are memorable, but the picture it creates. The human brain is very good at remembering (especially odd) pictures.
  The technique is well used by people that perform feats of memory. See http://en.wikipedia.org/wiki/Method_of_loci
28. Re:useless for strong passwords by fatphil · 2012-07-05 08:21 · Score: 1
  
  Your phrase evokes an image for you to remember. The image then later evokes a sequence of words.
  
  If you're lucky, they're the words in your phrase, in the right order. However, images do not distinguish synonyms.
  
  I can't prove it, but I bet that for the first few times you (y'all, not you personally) wanted to make reference to the xkcd phrase, you ran off and reminded yourself of it by doing a google search for "xkcd password" or similar. I know I did.
  
  I don't have it visible in front of me as I type this, and even though I've seen it recently, and the image, and I've even had to wrack my brains for other sequences of works that could be related to an image like the xkcd one, and even now I can only narrow it down to two options, not one - is it "staple battery" or "battery staple"? The "you remember it already!" (or whatever it says on the cartoon - have I even got that bit right?) is false for at least the segment of the population I am part of. (Then again, when I sing along to some of my favourite songs, that I've heard, and sung along to, dozens to hundreds of times, I still occasionally replace words with synonyms providing equal or better scansion. It's entirely possible my memory is just truly truly shit.)
  
  --
  Also FatPhil on SoylentNews, id 863
29. Re:useless for strong passwords by WuphonsReach · 2012-07-05 23:52 · Score: 1
  
  The unimportant accounts (forum logins, shopping carts), just let your browser store them and protect them with a master password. Firefox is okay in this, Internet Explorer is not (as it doesn't have a master password). Give those accounts a 10-20 randomized mix of letters/numbers. I use a tool called EPG (Extended Password Generator) to do quick random generation of passwords. But there are also linux shell tricks you can do to generate stuff.
  
  As a backup, store those login details in GPG/PGP encrypted text files in your documents folder and include that folder in your backups. I suggest 1 file per site. Then, as long as you have your PGP/GPG keys, you can retrieve your passwords for those accounts. Since the content is ASCII armored and encrypted, you could even print those blocks of text out, or email them to friends to store, or email them to yourself at various services. As regular files, they can be trivially included in a backup along with the rest of your documents (mine get stuffed into a version control system, which lets me synchronize the files across multiple machines easily).
  
  For the more important accounts, you can extend the above scheme, but don't let your web browser remember the passwords. You'll either have to memorize the passwords or fire up GPG/PGP every time you need to login to those important accounts. For the really important, gotta have it while away from your computer, jot the passwords down on a slip of paper, fold it over and tuck it in your wallet. Which is still safer then having a trivial password.
  
  Note that the weak point in the above is your GPG/PGP key's passphrase. Make sure you choose a very good passphrase. Make sure that you backup your keys and keychain regularly (you can even print out your GPG keys as an ASCII armored block on a sheet of paper).
  
  --
  Wolde you bothe eate your cake, and have your cake?
Inferior products always hit the news. by Anonymous Coward · 2012-07-04 09:54 · Score: 0

But hashcat still does it faster.
1. Re:Inferior products always hit the news. by solardiz · 2012-07-04 10:46 · Score: 3, Interesting
  
  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. :-)
Secure Remote Password verifier by Anonymous Coward · 2012-07-04 10:01 · Score: 0

If you really need to store password hashes securely, just store 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 you 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).
http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
1. Re:Secure Remote Password verifier by solardiz · 2012-07-04 11:32 · Score: 0
  
  This comment about SRP is duplicate. I've replied to the other instance of it in detail, up in the thread. In short: SRP is great, but, no, it is not an alternative to better password hashing.
2. Re:Secure Remote Password verifier by Anonymous Coward · 2012-07-04 19:36 · Score: 0
  
  FWIW, timestamp-wise this one is the original.
Hopeless situation by Kergan · 2012-07-04 13:09 · Score: 4, Insightful

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.
1. Re:Hopeless situation by kantos · 2012-07-05 00:55 · Score: 1
  
  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 or better algorithm designed to be slower HMACSHA512 etc. If you're really really lucky they'll be a professional and use a third party module for authentication that implements PBKDF2/PKCS#5 using a really slow hash.
  But lets be honest folks... security is always priority number 2, just like it's Safety Second in a dangerous workplace
  
  --
  Any and all content posted above may be ignored, considered irrelevant, or otherwise dismissed.
why not adapt by Anonymous Coward · 2012-07-04 13:23 · Score: 0

If the cracking software uses the GPU to brute force the hashes, why not compute and compare hashes using the GPU too? level the playing field out.
1. Re:why not adapt by solardiz · 2012-07-04 14:12 · Score: 4, Interesting
  
  The existing password hashing methods won't run on GPU well for user authentication, even when they do run well for cracking passwords. They lack sufficient parallelism within one hash computation. This is an issue I first raised in 1998, in pre-GPU context (it applies to recent CPUs as well, and the problem is getting worse with time).
  A solution is to define a new password hashing method with sufficient (configurable) parallelism within one instance. We could then consider running it on GPU, unless it is GPU-unfriendly by other criteria. Do we really want to, though? GPUs in servers are not yet common, except in computing clusters. Their reliability may be lower than that of other typical server components. The drivers are currently relatively unreliable as well (although they may be reliable enough if running the same code, with no upgrades). Sure, computing clusters use them anyway, and get them to run reliably enough for their needs, but the extra hurdle and/or risk is there. Will we get embedded GPUs in typical servers soon? Will they be similar to current gamers' or HPC GPUs or not? This is not clear. Then there's Intel MIC, which delivers GPU-like performance, but is a lot closer to a CPU - it will require a lot of parallelism in the algorithm too, but it may run certain types of otherwise GPU-unfriendly code. Is this possibly a better target?
  For current GPUs, a better strategy might be to make them inefficient - by using GPU-unfriendly hashes (for cracking, and for validation as well - as a side-effect).
  We had a project last summer to research this kind of possibilities, focusing on use of FPGA boards in authentication servers. This could optionally buy us GPU-unfriendliness (if we want to make things more difficult for attackers with GPUs, but not FPGAs, and for botnets, which almost surely will lack FPGAs). We even considered some moderate CPU-unfriendliness of the component that we'd put on FPGA. Specifically, we experimented with bcrypt on FPGA, as well as with much smaller Blowfish-like "non-crypto" cores (not actual Blowfish), so that we could hopefully fit hundreds or thousands of those per chip (and have them somewhat CPU-unfriendly as well). Yuri, our GSoC 2011 student working on this project, did have some of this implemented in an experimental fashion, and some of it even worked (on FPGA boards kindly provided by Pico Computing), but an outcome of the summer project was that this would be time-consuming to bring to desired levels of performance and reliability. At that point, the project was put on hold.
  A simpler and cheaper alternative (if there are only a handful of customers for this) may be to use dedicated servers, existing HSMs, or microcontrollers for just the password hashing. Indeed, microcontrollers are super slow, so their only function would be to hold and apply a local parameter, with the rest of the hashing method implemented on the host's CPU and RAM. If dedicated servers are used, they would need to be separate from authentication servers - that is, they won't know usernames, won't have access to any database, won't have any persistent storage except for the local parameter, and the OS and software indeed. They will accept password, salt, and parameters (such as the configurable per-hash processing and memory cost settings), and provide the hash. Thus, their attack surface would be minimal and they'd provide an extra layer of security against network-based attacks. We'd do this with FPGA boards as well, and we'd also have the greater/unusual computational complexity as a security layer (in case the local parameter or its backup copy is leaked/stolen), but well - using typical and pre-existing server hardware, drivers, etc. is just simpler and cheaper unless we start a new business and expect to have plenty of customers (although that might be possible).
2. Re:why not adapt by ps_inkling · 2012-07-05 08:41 · Score: 1
  
  Reading your proposal for having an FPGA hold a critical part of the encryption process, I was reminded of the many places we have seen this idea before: dongles (parallel port and USB), arcade games (slapstic from Atari, the CPS-2 "suicide batteries", and NAOMI to name a few), SmartCards, and others.
  Instead of using FPGA, I would use a cheaper PIC or Atmel device -- the security is in the algorithm implemented in the device. Having a copy of the hardware in the hand of an attacker, whether cheap or expensive, nullifies the extra security it provides. Notice for the devices above, they were all compromised after diligent work over time.
  For a out-of-band verification system, I can see this working pretty well -- for an individual user or server. Making sure that the device does the calculation and not holding a "shared secret" is the key. Having to carry around a physical device to decrypt your data would be inconvenient; having only one device that can authenticate users is ideal (and a spare device for Murphy).
  I just find it curious that the wheel of progress is rotating back to using separate hardware to implement hashing or security instead of just relying on algorithm complexity.
I've got a question about this by Ollabelle · 2012-07-05 02:08 · Score: 1

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.

--
Ibid.
1. Re:I've got a question about this by WuphonsReach · 2012-07-05 23:44 · Score: 1
  
  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
  b32aced0e8ccc1bfd8ee327455af67e196590371 -
  
  --
  Wolde you bothe eate your cake, and have your cake?
2. Re:I've got a question about this by Anonymous Coward · 2012-07-06 06:46 · Score: 0
  
  Consider: you evaluate a hash algorithm based on the "apparent randomness" of mappings inputs to outputs. The hash output MUST NOT leak any information about the input. Thus, if the hash output length has ANY correlation to the input length, that is a leak and thus exploitable. Thus, a hash output length must either be apparently random (unworkable in practice), or a fixed size. Nothing in between.
Bcrypt is to PBKDF2 as Blowfish is to SHA-512 by Anonymous Coward · 2012-07-05 03:38 · Score: 0

Yet again, we see the conflation of an algorithm based on a number of rounds of a cryptographic function (Bcrypt, Scrypt, PBKDF2) with the cryptographic function itself (Blowfish, SHA-1, SHA-512).
Bcrypt is a number of Blowfish rounds.
PBKDF2 is a number of HMAC rounds.
Comparing N rounds of Bcrypt against 1 round of SHA-512 is an entirely invalid and almost pointless* argument. Now, determining how many rounds of Bcrypt is equivalent to N rounds of PBKDF2-HMAC-SHA-512 on a given platform would be valuable.
*I acknowledge that some developers would use only one round of a hash to store passwords... on the other hand, they might also pass Bcrypt a minimum number of rounds, too.
The real news is that JtR is adding GPU cracking functionality that has been the domain of software like Elcomsoft's products (many hashes), Pyrit (WPA(2)-PSK), Hashcat (many hashes), and a few others. If JtR provides a more extensible framework, and I believe it does, this will allow for more competition, more new ideas, and more algorithms to be able to be tested against GPU cracking, which will allow all of us to try to increase our security.
Close to the wake of the LinkedIn password leak, this is particularly good timing - password security is still on people's minds.
Mod parent up. by bussdriver · 2012-07-05 09:35 · Score: 1

bcrypt rules. Algorithm design wins against brute force.

--
Democracy Now! - uncensored, anti-establishment news