4 ms·

Step 1) Use Scrypt instead Step 2) There is no step 2

by luizfelberti 6y ago

LunaSea 6y ago
I think you meant Argon
- brobinson 6y ago
  Argon2 in data independent or hybrid mode, specifically.
cj 6y ago
https://github.com/Tarsnap/scrypt https://github.com/Tarsnap/scrypt Side note, I've seen a number of places (including the Scrypt repo) compare bcrypt brute-force benchmarks without specifying the bcrypt work factor. It's very frustrating to see this, considering the time to compute a single bcrypt hash can be < 0.01 seconds (ie. work factor 7 or 8), or more than 1 minute (ie. work factor 20). I'm not familiar with scrypt, but it looks like instead of providing a work factor, you can provide inputs like "max time to compute hash" and "max percent of ram to use computing hash" which presumably scales up as hardware becomes more powerful?
- cperciva 6y ago
  I've seen a number of places (including the Scrypt repo) compare bcrypt brute-force benchmarks without specifying the bcrypt work factor. It's specified implicitly in the scrypt README file: "if 5 seconds are spent computing a derived key". It's explicit in the conference paper (cost = 16).
- gperciva 6y ago
  The algorithm itself takes three cost&memory values N, r, p, and if you're calling the `crypto_scrypt()` function in C or C++ as a KDF you need to specify those. The command-line binary generally takes "max time" and "max ram" (as percent and/or raw value) and estimates appropriate cost values. As of version 1.3.1, you can manually specify cost values for the binary if you want.
kevin_thibedeau 6y ago
Scrypt isn't an option on memory constrained devices.
- luizfelberti 6y ago
  Password hashing is done server side, the client only needs to worry about TLS. Are you thinking about some specific use case? Also, it's not a good idea to base your security parameters on the compute power of the most underpowered device in the chain.
  - kevin_thibedeau 6y ago
    Devices that need access restrictions without network connectivity have to use something to protect credentials. You can't hand wave your way out of that.
    - luizfelberti 6y ago
      lol in what way am I being hand wavy? It was a sincere question, and the use case you're pointing to is very different than what the post was discussing That being said, for these cases you could use Argon2 which is mostly (entirely?) based on ARX constructs and will work well on embedded/underpowered devices There are also some symmetric encryption shenanigans that can be done, but if you can use something other than password-based auth you're free from pretty much all of these problems, with probably much better security
fractionalhare 6y ago
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)
lanecwagner 6y ago
Assuming you can find a battle testing implementation
- luizfelberti 6y ago
  Agreed, one is not always easily available, and for those cases any of Scrypt, Argon2, and Bcrypt are fine (but preferrably in that order :) If you're on Golang, Rust, or C though: leverage your options!
gperciva 6y ago
BTW, we released scrypt 1.3.1 yesterday: http://mail.tarsnap.com/scrypt/msg00268.html http://mail.tarsnap.com/scrypt/msg00268.html Main page, including the signed tarball: http://www.tarsnap.com/scrypt.html http://www.tarsnap.com/scrypt.html

Step 1) Use Scrypt instead Step 2) There is no step 2

LunaSea 6y ago

I think you meant Argon

brobinson 6y ago
Argon2 in data independent or hybrid mode, specifically.

cj 6y ago

https://github.com/Tarsnap/scrypt https://github.com/Tarsnap/scrypt Side note, I've seen a number of places (including the Scrypt repo) compare bcrypt brute-force benchmarks without specifying the bcrypt work factor. It's very frustrating to see this, considering the time to compute a single bcrypt hash can be < 0.01 seconds (ie. work factor 7 or 8), or more than 1 minute (ie. work factor 20). I'm not familiar with scrypt, but it looks like instead of providing a work factor, you can provide inputs like "max time to compute hash" and "max percent of ram to use computing hash" which presumably scales up as hardware becomes more powerful?

cperciva 6y ago
I've seen a number of places (including the Scrypt repo) compare bcrypt brute-force benchmarks without specifying the bcrypt work factor. It's specified implicitly in the scrypt README file: "if 5 seconds are spent computing a derived key". It's explicit in the conference paper (cost = 16).
gperciva 6y ago
The algorithm itself takes three cost&memory values N, r, p, and if you're calling the `crypto_scrypt()` function in C or C++ as a KDF you need to specify those. The command-line binary generally takes "max time" and "max ram" (as percent and/or raw value) and estimates appropriate cost values. As of version 1.3.1, you can manually specify cost values for the binary if you want.

kevin_thibedeau 6y ago

Scrypt isn't an option on memory constrained devices.

luizfelberti 6y ago
Password hashing is done server side, the client only needs to worry about TLS. Are you thinking about some specific use case? Also, it's not a good idea to base your security parameters on the compute power of the most underpowered device in the chain.
- kevin_thibedeau 6y ago
  Devices that need access restrictions without network connectivity have to use something to protect credentials. You can't hand wave your way out of that.
  - luizfelberti 6y ago
    lol in what way am I being hand wavy? It was a sincere question, and the use case you're pointing to is very different than what the post was discussing That being said, for these cases you could use Argon2 which is mostly (entirely?) based on ARX constructs and will work well on embedded/underpowered devices There are also some symmetric encryption shenanigans that can be done, but if you can use something other than password-based auth you're free from pretty much all of these problems, with probably much better security

fractionalhare 6y ago

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)

lanecwagner 6y ago

Assuming you can find a battle testing implementation

luizfelberti 6y ago
Agreed, one is not always easily available, and for those cases any of Scrypt, Argon2, and Bcrypt are fine (but preferrably in that order :) If you're on Golang, Rust, or C though: leverage your options!

gperciva 6y ago

BTW, we released scrypt 1.3.1 yesterday: http://mail.tarsnap.com/scrypt/msg00268.html http://mail.tarsnap.com/scrypt/msg00268.html Main page, including the signed tarball: http://www.tarsnap.com/scrypt.html http://www.tarsnap.com/scrypt.html