View source for Talk:Password Storage Cheat Sheet

Setting a unlimited length for passwords can be an easy DOS vector. http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

--[[User:jmanico]] , 16 Sept 2013 (UTC)
----

More on the previous dicussions on secret salts. They are usually referred to as pepper on practice. The advantage of having a pepper for the passwords is that you can keep them on the web server. Thus, if the hacker has access to the database data and he has access to all hashed passwords (doesn't matter if they are created using PBKDF2, bcrypt or scrypt, or even simple salt+sha2), he still needs to also hack the web server to obtain the pepper, or fixed salt. It isn't cryptographically significant, but it adds yet another layer to the information the hacker has to obtain before starting to do the brute force.
I think it would be nice if it was possible to add it to the cheat sheet.

--[[User:Manuel Aude Morales|Manuel Aude Morales]] , 18 March 2013 (UTC)
----

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)?
--[[User:Manuel Aude Morales|Manuel Aude Morales]] , 18 March 2013 (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.
--[[User:Dan Anderson|Dan Anderson]] 17:33, 8 June 2012 (UTC)


IMO, this is a good example: [http://fredericiana.com/2012/06/08/lets-talk-about-password-storage/|Let’s talk about password storage]
--[[User:Dan Anderson|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). 

* Fixed system salt is a fine practice followed by many,
but does not increase system security since when concatenated with random salts, its just one long salt with less randomness.
* 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.