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"
Dan Anderson (talk | contribs) |
|||
| (11 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | 1) It is not clear that the slow hash is preferred over an HMAC storage format and why you would choose HMAC over slow hash. | |
| − | + | 2) Ideally, some mention should be made of the bcrypt-style storage format where cost, salt and hash are all stored together, which permits a very easy way to increase cost over time without breaking existing hashes. I am unsure of the scrypt format and I don't think PBKDF2 stores it this way by default. The format should be recommended since it then allows the contingency work mentioned further down. | |
| + | --[[User:Lbriner|Luke Briner]] ([[User talk:LBriner|talk]]) 11:22, 16 November 2015 (UTC) | ||
---- | ---- | ||
| − | + | Suggest take in account planned/actual scale of a system to protect. Bigger systems probably need more layers of defense, like additional authN server + secret salt (local parameters) + traditional KDF for storage. See Solar Designer's [http://openwall.com/presentations/YaC2012-Password-Hashing-At-Scale/ slides] from Yac 2012 (unfortunately, there is no English video). | |
| − | + | --[[User:Adedov|Adedov]] ([[User talk:Adedov|talk]]) 07:28, 13 November 2015 (CST) | |
| + | ---- | ||
| − | + | 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/ | |
| − | or even | + | --[[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. | ||
| + | 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 | + | 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) |
Latest revision as of 11:22, 16 November 2015
1) It is not clear that the slow hash is preferred over an HMAC storage format and why you would choose HMAC over slow hash. 2) Ideally, some mention should be made of the bcrypt-style storage format where cost, salt and hash are all stored together, which permits a very easy way to increase cost over time without breaking existing hashes. I am unsure of the scrypt format and I don't think PBKDF2 stores it this way by default. The format should be recommended since it then allows the contingency work mentioned further down.
--Luke Briner (talk) 11:22, 16 November 2015 (UTC)
Suggest take in account planned/actual scale of a system to protect. Bigger systems probably need more layers of defense, like additional authN server + secret salt (local parameters) + traditional KDF for storage. See Solar Designer's slides from Yac 2012 (unfortunately, there is no English video).
--Adedov (talk) 07:28, 13 November 2015 (CST)
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)
