3 ms·

Definitely do not use SHA256, it's designed to be fast. That's the opposite of what you want when storing passwords. I don't understand what's the problem with

Definitely do not use SHA256, it's designed to be fast. That's the opposite of what you want when storing passwords. I don't understand what's the problem with scrypt, but if you don't want to use it there's also bcrypt and argon2i.

garmaine 9y ago
Read the grand parent post for the context of my post.. fast is good. Slowing down the key derivation function, as scrypt et al does, has a linear cost to both the verifier and the attacker. Using scrypt with standard parameters for an authentication KDF adds about 15 bits of work to each guess attempt. That's approximately equivalent to adding 6 random characters to your password. Making your password that much longer is just as good, while not requiring you to burn a half second of CPU time and thrash memory every time you authenticate. Besides slowing down attackers, the other claimed reason for using scrypt is that it is more secure against determined attackers that implement accelerated password crackers because it is a "memory-hard" key derivation function. In fact, the experience with scrypt crypto currency hashing has proven this assumption to be false. Compared with a salted hash function, scrypt like algorithms have a lower energy density when implemented in silicon and therefore actually get higher gain multiples from various levels of hardware acceleration than you observe with straight hash functions like sha256. So a determined attacker would have an even greater edge than the scrypt parameters would lead you to believe.
- brians 9y ago
  Can you expand on what you see as the y-intercept for those cost functions? I think you’re assuming zero for attacker and defender. I can imagine arguments that the defender has a small positive y-intercept, and that makes all the difference.
- wahern 9y ago
  > KDF adds about 15 bits of work to each guess attempt. > That's approximately equivalent to adding 6 random > characters to your password. A better way of putting it is that it's equivalent to adding 15 bits of entropy to your users' passwords, which in the grand scheme of isn't actually much of a marginal improvement in overall security. Adding 15 bits to an already strong password provides a small, largely irrelevant marginal gain. Adding 15 bits to a bad password has more marginal benefit, but you're typically still in the window where brute-force cracking is tolerable, especially considering typical attack models--in most scenarios attackers only need to crack the weakest password among an often large set of passwords. Fancy hashing schemes optimize for scenarios that are both relatively rare and fleeting. If you're in a position where they seem defensible, you've already lost the game. Unless your purpose is to check-off some boxes, similar to how until recently IT departments required frequent password resets to check-off NIST's antiquated guidelines. There is a way to substantially improve the overall security of a password-based system: use a keyed HMAC on a cryptographic HSM for validating passwords. With an HSM (from which we assume the attacker can't actually recover the secret key), you can precisely, reliably, and meaningfully throttle brute-force recovery times without being contingent on any hand-wavy, snake-oily, bike-sheddy hashing scheme with dubious parameters.

garmaine 9y ago

Read the grand parent post for the context of my post.. fast is good. Slowing down the key derivation function, as scrypt et al does, has a linear cost to both the verifier and the attacker. Using scrypt with standard parameters for an authentication KDF adds about 15 bits of work to each guess attempt. That's approximately equivalent to adding 6 random characters to your password. Making your password that much longer is just as good, while not requiring you to burn a half second of CPU time and thrash memory every time you authenticate. Besides slowing down attackers, the other claimed reason for using scrypt is that it is more secure against determined attackers that implement accelerated password crackers because it is a "memory-hard" key derivation function. In fact, the experience with scrypt crypto currency hashing has proven this assumption to be false. Compared with a salted hash function, scrypt like algorithms have a lower energy density when implemented in silicon and therefore actually get higher gain multiples from various levels of hardware acceleration than you observe with straight hash functions like sha256. So a determined attacker would have an even greater edge than the scrypt parameters would lead you to believe.

brians 9y ago
Can you expand on what you see as the y-intercept for those cost functions? I think you’re assuming zero for attacker and defender. I can imagine arguments that the defender has a small positive y-intercept, and that makes all the difference.
wahern 9y ago
> KDF adds about 15 bits of work to each guess attempt. > That's approximately equivalent to adding 6 random > characters to your password. A better way of putting it is that it's equivalent to adding 15 bits of entropy to your users' passwords, which in the grand scheme of isn't actually much of a marginal improvement in overall security. Adding 15 bits to an already strong password provides a small, largely irrelevant marginal gain. Adding 15 bits to a bad password has more marginal benefit, but you're typically still in the window where brute-force cracking is tolerable, especially considering typical attack models--in most scenarios attackers only need to crack the weakest password among an often large set of passwords. Fancy hashing schemes optimize for scenarios that are both relatively rare and fleeting. If you're in a position where they seem defensible, you've already lost the game. Unless your purpose is to check-off some boxes, similar to how until recently IT departments required frequent password resets to check-off NIST's antiquated guidelines. There is a way to substantially improve the overall security of a password-based system: use a keyed HMAC on a cryptographic HSM for validating passwords. With an HSM (from which we assume the attacker can't actually recover the secret key), you can precisely, reliably, and meaningfully throttle brute-force recovery times without being contingent on any hand-wavy, snake-oily, bike-sheddy hashing scheme with dubious parameters.