Talk:Password Storage Cheat Sheet

I was considering adding bcrypt to the article. I checked previous versions and noticed it was in it on January, but it was taken out during editions in March. From my knowledge, bcrypt is still a widely recommended adaptative hashing function. While it has limitations (particularly, a 55 bytes limitation) and doesn't protect to all hardware accelerated attacks, it does protect against GPU and works as good as PBKDF2 for most cases. Also, scrypt hasn't existed for nearly as much as bcrypt, and thus it isn't as widely tested or supported by platforms.

Would it be ok to add a table making a comparison between PBKDF2, bcrypt and scrypt, with suggestions on when to use (and clarifying that the three are valid options)? --Manuel Aude Morales 17:33, 8 June 2012 (UTC)

I think, for this cheat-sheet, we should begin by identifying and describing the minimum acceptable mechanisms for password storage (IMO, this is probably still salt+hash) first. Then, describe the additional controls that can be applied to further enhance the protection. --Dan Anderson 17:33, 8 June 2012 (UTC)

IMO, this is a good example: |Let’s talk about password storage --Dan Anderson 20:58, 8 June 2012 (UTC)

Since the community is focusing more on this page, I think we need a discussion.

A few of the points mentioned on this page are dubious to me :

Recommendation: Make it hard to steal the salt
As far as I know salts are salts, not secrets. They are supposed to be known (in a cryptographic point of view).

but does not increase system security since when concatenated with random salts, its just one long salt with less randomness.
 * Fixed system salt is a fine practice followed by many,
 * Embedding a portion of the salt on source code, is not much different from the configuration file. Same scenario.
 * Generate new salt everytime password changes. That is true, and somehow required. But not to make salt gathering harder.
 * Salt in different location: same old

Multiple hashes
Oddly many open source software follow this paradigm, but it's totally irrelevant. As in Merkle's TIme-Memory tradeoff and Rainbow algorithms it is obvious that multiple hashes result in the same chain or another chain of the rainbow, thus don't add a single bit of security. I believe it must be mentioned that this practice is wrong. I have seen numerous OSS use

hash(salt.hash(user.hash(pass)).salt) which is as secure as hash(salt.pass)

or even less (can be exploited somehow).

I strongly suggest that this page be modified and fixed. If other members approve, please let me know.