You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Collecting here all the info about passwords and how we manage them. This should be closed when we are satisfied with our level of password security and management procedures.
I'll only combine all of them in this initial text.
About password algorithms
AFAIK "argon2 + salt + pepper" is the last word in password hashing. bcrypt is practically legacy by now. Giving it a quick search just1 in2 case3, I see no problems. I would encourage to read the OWASP cheatsheet1 in particular.
If we really want to get into it, we could try to follow NIST guidelines4. Document B says you SHOULD salt and lists a few recommended options for hashing:
Examples of suitable key derivation functions include Password-based Key Derivation Function 2 (PBKDF2) [SP 800-132] and Balloon [BALLOON]. A memory-hard function SHOULD be used because it increases the cost of an attack. The key derivation function SHALL use an approved one-way function such as Keyed Hash Message Authentication Code (HMAC) [FIPS 198-1], any approved hash function in SP 800-107, Secure Hash Algorithm 3 (SHA-3) [FIPS 202], CMAC [SP 800-38B] or Keccak Message Authentication Code (KMAC), Customizable SHAKE (cSHAKE), or ParallelHash [SP 800-185].
But if we don't need FIPS-1405 compliance, I don't think we need to strictly follow that.
About password strength
About proper passwords and stuff, I think we should research this later and come up with a better algo to determine the strength of a password. 8+ chars and at least one uppercase+digit+special is ok, but I want to accommodate for more diverse password styles. Like long_phrase_passwords with no digits or uppercase letters, etc.
As some inspiration, take a look at password entropy with https://xkpasswd.net/s/
Some6 more7 inspiration8. Especially the first6 one.
funny and true (spoiler)
About password peppering
Consider adding peppering. Since argon2 (as an algo) even supports it with it's "secret"9, and argon2 (the lib) implements it10. Notes on how to properly do peppering from OWASP Password Cheat Sheet11, my beloved.
Also check out counter-points to pepper12 (and the two13 links14 from that answer are also interesting), even if most of them don't apply to our case because we are using argon2 as intended, it has the "secret" param for a reason. However, secret rotation should be considered, as OWASP11 also mentions.
Participation
I am willing to submit a pull request to implement this
Peppering is annoying to work with and also does not really do much. Since peppering means we have to introduce state (we have to store the pepper) and if an attacker somehow manages to breach into our system, its very likely that they will have the pepper too.
It just becomes annoying to work with since we then have to know about the pepper here. perhaps we can add it but I am not sure if it actually does anything extra. Argon2 is already impossible to crack using any means, adding peppering means we have to keep track of a state all for it to be impossible * 2?
Collecting here all the info about passwords and how we manage them. This should be closed when we are satisfied with our level of password security and management procedures.
This is a collection from 3 posts by me:
I'll only combine all of them in this initial text.
About password algorithms
AFAIK "argon2 + salt + pepper" is the last word in password hashing. bcrypt is practically legacy by now. Giving it a quick search just1 in2 case3, I see no problems. I would encourage to read the OWASP cheatsheet1 in particular.
If we really want to get into it, we could try to follow NIST guidelines4. Document B says you SHOULD salt and lists a few recommended options for hashing:
But if we don't need FIPS-1405 compliance, I don't think we need to strictly follow that.
About password strength
About proper passwords and stuff, I think we should research this later and come up with a better algo to determine the strength of a password. 8+ chars and at least one uppercase+digit+special is ok, but I want to accommodate for more diverse password styles. Like
long_phrase_passwords
with no digits or uppercase letters, etc.As some inspiration, take a look at password entropy with https://xkpasswd.net/s/
Some6 more7 inspiration8. Especially the first6 one.
funny and true (spoiler)
About password peppering
Consider adding peppering. Since argon2 (as an algo) even supports it with it's "secret"9, and
argon2
(the lib) implements it10. Notes on how to properly do peppering from OWASP Password Cheat Sheet11, my beloved.Also check out counter-points to pepper12 (and the two13 links14 from that answer are also interesting), even if most of them don't apply to our case because we are using argon2 as intended, it has the "secret" param for a reason. However, secret rotation should be considered, as OWASP11 also mentions.
Participation
Disclaimer
Footnotes
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html (archived 2023-03-03) ↩ ↩2
https://developer.okta.com/blog/2019/07/29/hashing-techniques-for-password-storage ↩
https://codesigningstore.com/what-is-the-best-hashing-algorithm (archived 2023-03-03) ↩
https://pages.nist.gov/800-63-3/ ↩
https://en.wikipedia.org/wiki/FIPS_140 ↩
https://www.grc.com/haystack.htm ↩ ↩2
https://bitwarden.com/password-strength/ ↩
https://password.kaspersky.com/ ↩
https://security.stackexchange.com/a/206177 ↩
https://docs.rs/argon2/0.5.0/argon2/struct.Argon2.html (method) ↩
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#peppering ↩ ↩2
https://stackoverflow.com/a/16896216 ↩
https://stackoverflow.com/a/16597402 ↩
http://blog.ircmaxell.com/2012/04/properly-salting-passwords-case-against.html ↩
The text was updated successfully, but these errors were encountered: