6 ms·
This article looks great for anybody who wants to know the details. But "doing it right" is much simpler, and doesn't really need an article: "Use an accepted
by rlpb 13y ago
This article looks great for anybody who wants to know the details. But "doing it right" is much simpler, and doesn't really need an article:
"Use an accepted key derivation function, such as PBKDF2, bcrypt or scrypt".
All the work described is encapsulated into the concept of a key derivation function. Telling people to go into the details is like telling people how to do encryption by describing how to implement AES and Twofish. Don't go there. Find a library that implements a key derivation function, and use it. PBKDF2, bcrypt and scrypt are all fine.
- thirsteh 13y agoYou might want to add "with a high number of iterations or work factor," at least. PBKDF2-HMAC-SHA-256 is just as useless as 2xSHA-256 if you just do one iteration.
- rlpb 13y agoYes - this is reasonable. I'd generalise this to: "Use an accepted key derivation function, such as PBKDF2, bcrypt or scrypt, with accepted parameters". What is "accepted" changes over time, of course.
- anonymoushn 13y agoIndeed. This article is much longer than the docs for some bcrypt library in $LANGUAGE.
- anaphor 13y agoThere is some use in this article though, because it gives some good examples of terrible crypto. Oddly enough the "combine different hash functions!" meme isn't just limited to amateurs: "An Secure Hash Algorithim (SHA) hash of the received challenge string, the peer challenge string, the session identifier, and the MD4-hashed version of the user's password." http://technet.microsoft.com/en-us/library/cc957983.aspx http://technet.microsoft.com/en-us/library/cc957983.aspx
- kibibu 13y agoI worked with a group once that stored both MD5 and SHA1 hashes of passwords. Their reasoning was that it was WAY harder to get a collision with TWO hash functions.
- leigh_t 13y agoIt's a little premature to be recommending scrypt. There have been some posts on openwall suggesting it may be weaker than bcrypt, although it is also still a work-in-progress. I'd hold off until it is more battle-hardened before either recommending it or using it.
- deleted 13y ago[deleted]
- Freaky 13y agoLink for that? All I find is mentions of its weakness when used with very small amounts of memory (like Litecoin's silly decision to go with 128KB).
- leigh_t 13y agoSorry for late reply, the post I was thinking off (and didn't revise before posting) is http://www.openwall.com/lists/crypt-dev/2012/09/02/1 http://www.openwall.com/lists/crypt-dev/2012/09/02/1 Search for the word "weaker"
- Freaky 13y agoThanks - that's actually the post I was thinking of. Considering on most modern machines scrypt will likely tune itself to use 512MB, a 1MB buffer's pretty small, but it would be interesting to know where the cutoff for significantly-better-than-bcrypt might be. I expect most sites could throw 16MB at logins without much difficulty (as suggested further in that thread).