-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Update: Password_Storage_Cheat_Sheet #601
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I addressed this at 544ec25 and if you want anything else added please just comment here, email me, tweet - as you like - and I'll get it added in |
"Consider raising the work factor to 12 or more if performance considerations do not negatively impact your system." If you are going to add this for bcrypt it should be added to the other algorithms to match the strength of bcrypt cost 12:
|
I should mention that back when it said "The default work factor for Bcrypt is 10, and this should generally be raised to 12 unless operating on older or lower-powered systems." that IETF draft used it to say use cost 12. It now says basically the same thing. |
Here is the change I just made considering your work below.
I need to remove my foolish double-negatives and will so in a future push. (i.e., "do not negatively" needs to go, my bad)
0871f1d
I am moving away from direct commits to main and am now using the PR process properly.
If you want anything changed let me know.
I hope you are more happy vs. frustrated with the changes so far.
Aloha Steve,
- Jim
|
Can I get a "max" value for scrypt as well, Steve?
|
I gave those numbers so you would notice how crazy high bcrypt cost 12 is, not to add them to the others. But I guess if people see consider bcrypt cost 12 along with the others, then some might figure it out. Just let me be clear I don't think any should have these. Also you should benchmark the defender speeds.
|
Crap. I hear you. I'll make this change later today. I don't do subtle well, I often need the hammer. :)
|
I dropped the bcrypt 12 suggestion and the other "maximums" I surrender to reality |
I don't think I completely followed the argument here for not recommending a work factor of 12. Based on some non-definitive tests, a work factor of 10 is quite fast these days. What factors go into deciding that the minimum OWASP recommendation should be 10 instead of 12? I ask because Spring Security is considered bumping its default 12 in its next major release towards the end of 2022. Historically, it's set its default to match the OWASP minimum recommendation. |
These settings are minimums vs some random project's defaults. Defaults can and should be higher than the bare minimum. The minimum settings are to cause an attacker's speed to be <10 kH/s/GPU (GPU benchmark). Wait cost 10? Oh yeah I forgot I lost the battle for cost 9. I think it had something to do with FPGAs. Note that bcrypt cost 9 is almost twice as strong as all the other minimums because the true minimum is cost ~8.1 but it must be an integer. Anyway if bcrypt's minimum is set to cost 12 then the others should be increase by ~15x to match strength. |
There is your answer. Do not use the bare minimum for Spring, please set it at 12! :) |
So I had a look at the other defaults and none of them meet the minimums. So setting bcrypt to 12 is stupid compared to fixing the others. Hell there's a bug in the PBKDF2 default settings: SHA1 with 256 bits of output. This causes the defender to waste time calculating the last 96 bits of output which an attacker will just ignore. |
What defaults are wrong?
|
Their Argon2 (m=4 MiB, t=3, p=1), scrypt (N=2^14, r=8, p=1), and PBKDF2 (SHA1, 185k iterations, 256 bits of output). |
I guess my ask is, can you kindly read this and is there anything else I need to fix? https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html |
addressing comment OWASP/CheatSheetSeries#601
removing minimums OWASP/CheatSheetSeries#601
What is missing or needs to be updated?
It is unclear which is the key and which is the data in the HMAC: "
bcrypt(base64(hmac-sha256($password, $pepper)), $salt, $cost)
"How should this be resolved?
It should be "
bcrypt(base64(hmac-sha256(data:$password, key:$pepper)), $salt, $cost)
" or similar. Anyway if the password is used as the key and the password is longer than 64 bytes you can shuck the HMAC and bcrypt.The text was updated successfully, but these errors were encountered: