This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Talk:Password Storage Cheat Sheet"
Abbas Naderi (talk | contribs) (typo) |
Dan Anderson (talk | contribs) |
||
Line 1: | Line 1: | ||
+ | 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. | ||
+ | |||
Since the community is focusing more on this page, I think we need a discussion. | 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 : | A few of the points mentioned on this page are dubious to me : | ||
− | |||
==Recommendation: Make it hard to steal the salt== | ==Recommendation: Make it hard to steal the salt== | ||
Line 18: | Line 19: | ||
or even less (can be exploited somehow). | 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. | I strongly suggest that this page be modified and fixed. If other members approve, please let me know. |
Revision as of 17:19, 8 June 2012
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.
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.