Hacker News Reader

Comment by rlpb | Hacker News Reader

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.

View on HN

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

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

There 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

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

It'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.

Link 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).

Sorry 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

Search for the word "weaker"

Thanks - 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).

Indeed. This article is much longer than the docs for some bcrypt library in $LANGUAGE.

Reply on news.ycombinator.com