Difference between revisions of "Talk:Password Storage Cheat Sheet"

From OWASP
Jump to: navigation, search
(reviving discussion on peppers ("secret salts"))
(Start discussion on credential data included in hashes)
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
Increasing work factor with PBKDF2 etc. can result in an application-level DoS vector. This can be abused in a passively distributed manner by inducing CSRF authentication attempts and hence standard CSRF mitigation should be applied to authentication systems too. Mitigating automated DoS attacks on this vector can be achieved with CAPTCHA but which users should be required to complete a CAPTCHA isn't as simple; linking it to a session and failed authentication attempts will not work as an automated attack can simply request a new session token. Perhaps it should be linked to IP or subnet?
 +
 +
--[[User:Arran Schlosberg|Arran Schlosberg]] , 19 Feb 2014 (UTC)
 +
----
 +
 +
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|Jim Manico]] , 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.
 
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.
 
I think it would be nice if it was possible to add it to the cheat sheet.
Line 11: Line 21:
 
----
 
----
  
 
+
Is there any utility in incuding credential data in the input to the protective function? I don't understand what it adds, given a sufficiently random salt. [[User:James Sanderson|James Sanderson]] ([[User talk:James Sanderson|talk]]) 17:25, 2 July 2014 (CDT)
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.
+

Latest revision as of 17:25, 2 July 2014

Increasing work factor with PBKDF2 etc. can result in an application-level DoS vector. This can be abused in a passively distributed manner by inducing CSRF authentication attempts and hence standard CSRF mitigation should be applied to authentication systems too. Mitigating automated DoS attacks on this vector can be achieved with CAPTCHA but which users should be required to complete a CAPTCHA isn't as simple; linking it to a session and failed authentication attempts will not work as an automated attack can simply request a new session token. Perhaps it should be linked to IP or subnet?

--Arran Schlosberg , 19 Feb 2014 (UTC)


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/

--Jim Manico , 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.

--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)? --Manuel Aude Morales , 18 March 2013 (UTC)


Is there any utility in incuding credential data in the input to the protective function? I don't understand what it adds, given a sufficiently random salt. James Sanderson (talk) 17:25, 2 July 2014 (CDT)