5 ms·

For the vast majority of developers, bcrypt, scrypt, argon and PBKDF2 provide functionally equivalent security. It's not generally productive to nitpick betwee

For the vast majority of developers, bcrypt, scrypt, argon and PBKDF2 provide functionally equivalent security. It's not generally productive to nitpick between secure password hashing/key derivation functions. Unless you specifically know you can't use one of these in particular, you should just pick whichever one has a safe implementation in a secure cryptographic library that you can use. Basically, just don't use MD5, SHA1, SHA2, SHA3 (including Keccak and the other contenders) or some non-cryptographic hash function.

lanecwagner 6y ago
Author here - and I agree with this wholeheartedly. I've done articles of Bcrypt and Scrypt and while Scrypt seems better theoretically, it can be harder to find a battle tested implementation
luizfelberti 6y ago
While I agree with the sentiment of what you're saying, I take issue with this part specifically: > For the vast majority of developers, bcrypt, scrypt, argon and PBKDF2 provide functionally equivalent security 1) The "vast majority of developers" should not be implementing login systems, period. The chances most people have of not falling for any OWASP gotcha, making sound security choices, and implementing them correctly, is pretty much nil. Leveling the argument to this makes many things that should not be done sound passable. 2) They do not, categorically, provide "functionally equivalent security" (especially not for bare PBKDF2). This is a myth people believe in because they normalize their perception of deviant behaviour[0], and frame the situation as "if my database never gets pwned, any one of these is fine", which is just an argument based on wishful thinking, akin to "I can drive recklessly as long as I don't crash", but we don't use this reasoning to nullify seat-belts: the choice of algorithm is important precisely, and perhaps exclusively, for when all your other security mechanisms failed. The reality though, is that more often than not, when databases gets pwned you never find out about it because monitoring and security practices is often lackluster, and then you keep believing that these things don't matter. [0] https://en.wikipedia.org/wiki/Normalization_of_deviance https://en.wikipedia.org/wiki/Normalization_of_deviance As a general rule for their security properties: Scrypt > Argon2 > Bcrypt, and PBKDF2 should be avoided. You should prefer the first one of these you can find with a robust implementation (which as @lanecwagner pointed out may not always be Scrypt, and that's fine, as is Bcrypt if you have implementation constraints)
- hinkley 6y ago
  I wonder if it’s a category error: Because password may be thought of as a first line of defense, folks have trouble with the notion of your password encryption being the last line of defense. There are quite a few things we do that “bookend” other operations. I’ve certainly seen my fair share of people getting those wrong too (eg, teardown should often happen in the reverse order of setup, FILO)
- fractionalhare 6y ago
  > The "vast majority of developers" should not be implementing login systems, period. Yep, agree. This also supports the idea that you shouldn't get too hung up on which to use, because hopefully that decision was made for you and one of these was selected. > They do not, categorically, provide "functionally equivalent security" Eh, disagree, if your database is breached and your digests are salted, any of these is fine. Of course there are technical differences because these are literally different algorithms, the actual difference in security provided by each is one of degree, not category. Unhashed vs hashed, and SHA2 vs bcrypt are what I'd call differences of category.
  - luizfelberti 6y ago
    I originally used categorically to mean "unambiguously explicit and direct", but adding to what you said (with which I mostly agree), Scrypt actually does provide a categorical increment to security by being ASIC-resilient. There are differences among them between classes of attacks they're susceptible to, provable security properties, and how paranoid should you should be in respect to advances cryptanalysis. I tend to weigh these as significant factors given that the dynamics of password-based auth can very well lead to a database leak screwing someone over 20 years into the future, although I admit that you can't get too picky nowadays and I'd be very glad if we, as a species, could have what you described as a lower-bound (with the exception of PBKDF2, of course :P)
- tialaramex 6y ago
  No. Your parent was right, it doesn't really matter. The password hashes buy you an improvement for the narrow range of passwords that are bad but not that bad against adversaries who are powerful but not that powerful. It's pretty much the definition of a marginal win. Which hash you choose slightly tweaks the margin. It's essentially impossible that this is the lowest hanging fruit for your system security and so "use a different password hash" ought to be nowhere near close enough to the top of the TODO pile to get done if you're already using any of these decent password hashes listed such as PBKDF2. If your users have strong passwords (e.g. a 20 alphanumeric random password from a typical password manager) it makes no difference at all. Even plain MD5() of such a password is as safe for the user and for you as Scrypt or Argon2 or other choices. If your users have very weak passwords then once again it makes no difference. Your heavily tuned Scrypt password hashing doesn't prevent me guessing that Steevo412's password on your site might be something obvious like "letmein" - on a lowly mid-range laptop before I get bored. So all this work is to achieve a marginal improvement in the middle. Maybe if Steevo412 has picked "LetMeInNOW" and maybe the script kiddies who stole the database ran out of stolen Amazon credits, they don't "crack" his password this time. Maybe. And none of this makes you any safer from inadvertently leaking the plaintext passwords, which your system unavoidably needs to know during authentication, or numerous other pitfalls that have nothing to do with dick-measuring contests about which hash is better. OR if security actually is important you could deploy something that's actually a clear improvement such as WebAuthn and stop trying to sweep the problems with password storage under increasingly complicated rugs.

lanecwagner 6y ago

Author here - and I agree with this wholeheartedly. I've done articles of Bcrypt and Scrypt and while Scrypt seems better theoretically, it can be harder to find a battle tested implementation

luizfelberti 6y ago

While I agree with the sentiment of what you're saying, I take issue with this part specifically: > For the vast majority of developers, bcrypt, scrypt, argon and PBKDF2 provide functionally equivalent security 1) The "vast majority of developers" should not be implementing login systems, period. The chances most people have of not falling for any OWASP gotcha, making sound security choices, and implementing them correctly, is pretty much nil. Leveling the argument to this makes many things that should not be done sound passable. 2) They do not, categorically, provide "functionally equivalent security" (especially not for bare PBKDF2). This is a myth people believe in because they normalize their perception of deviant behaviour[0], and frame the situation as "if my database never gets pwned, any one of these is fine", which is just an argument based on wishful thinking, akin to "I can drive recklessly as long as I don't crash", but we don't use this reasoning to nullify seat-belts: the choice of algorithm is important precisely, and perhaps exclusively, for when all your other security mechanisms failed. The reality though, is that more often than not, when databases gets pwned you never find out about it because monitoring and security practices is often lackluster, and then you keep believing that these things don't matter. [0] https://en.wikipedia.org/wiki/Normalization_of_deviance https://en.wikipedia.org/wiki/Normalization_of_deviance As a general rule for their security properties: Scrypt > Argon2 > Bcrypt, and PBKDF2 should be avoided. You should prefer the first one of these you can find with a robust implementation (which as @lanecwagner pointed out may not always be Scrypt, and that's fine, as is Bcrypt if you have implementation constraints)

hinkley 6y ago
I wonder if it’s a category error: Because password may be thought of as a first line of defense, folks have trouble with the notion of your password encryption being the last line of defense. There are quite a few things we do that “bookend” other operations. I’ve certainly seen my fair share of people getting those wrong too (eg, teardown should often happen in the reverse order of setup, FILO)
fractionalhare 6y ago
> The "vast majority of developers" should not be implementing login systems, period. Yep, agree. This also supports the idea that you shouldn't get too hung up on which to use, because hopefully that decision was made for you and one of these was selected. > They do not, categorically, provide "functionally equivalent security" Eh, disagree, if your database is breached and your digests are salted, any of these is fine. Of course there are technical differences because these are literally different algorithms, the actual difference in security provided by each is one of degree, not category. Unhashed vs hashed, and SHA2 vs bcrypt are what I'd call differences of category.
- luizfelberti 6y ago
  I originally used categorically to mean "unambiguously explicit and direct", but adding to what you said (with which I mostly agree), Scrypt actually does provide a categorical increment to security by being ASIC-resilient. There are differences among them between classes of attacks they're susceptible to, provable security properties, and how paranoid should you should be in respect to advances cryptanalysis. I tend to weigh these as significant factors given that the dynamics of password-based auth can very well lead to a database leak screwing someone over 20 years into the future, although I admit that you can't get too picky nowadays and I'd be very glad if we, as a species, could have what you described as a lower-bound (with the exception of PBKDF2, of course :P)
tialaramex 6y ago
No. Your parent was right, it doesn't really matter. The password hashes buy you an improvement for the narrow range of passwords that are bad but not that bad against adversaries who are powerful but not that powerful. It's pretty much the definition of a marginal win. Which hash you choose slightly tweaks the margin. It's essentially impossible that this is the lowest hanging fruit for your system security and so "use a different password hash" ought to be nowhere near close enough to the top of the TODO pile to get done if you're already using any of these decent password hashes listed such as PBKDF2. If your users have strong passwords (e.g. a 20 alphanumeric random password from a typical password manager) it makes no difference at all. Even plain MD5() of such a password is as safe for the user and for you as Scrypt or Argon2 or other choices. If your users have very weak passwords then once again it makes no difference. Your heavily tuned Scrypt password hashing doesn't prevent me guessing that Steevo412's password on your site might be something obvious like "letmein" - on a lowly mid-range laptop before I get bored. So all this work is to achieve a marginal improvement in the middle. Maybe if Steevo412 has picked "LetMeInNOW" and maybe the script kiddies who stole the database ran out of stolen Amazon credits, they don't "crack" his password this time. Maybe. And none of this makes you any safer from inadvertently leaking the plaintext passwords, which your system unavoidably needs to know during authentication, or numerous other pitfalls that have nothing to do with dick-measuring contests about which hash is better. OR if security actually is important you could deploy something that's actually a clear improvement such as WebAuthn and stop trying to sweep the problems with password storage under increasingly complicated rugs.