7 ms·

So? Use a properly salted sha256. Don’t use scrypt.

frankpf 9y ago
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.
endymi0n 9y ago
sha256 hashing rate on a modern graphics card is about 23GH/s: https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40 https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27... Not too good advice if you ask me IMHO. Here's better advice: https://codahale.com/how-to-safely-store-a-password/ https://codahale.com/how-to-safely-store-a-password/ s/bcrypt/scrypt/g if you prefer.
- LaGrange 9y ago
  It's 2017, use libsodium: https://download.libsodium.org/doc/password_hashing/ https://download.libsodium.org/doc/password_hashing/.
  - jedisct1 9y ago
    It's almost 2018, use libhydrogen: https://github.com/jedisct1/libhydrogen/wiki/Password-hashing https://github.com/jedisct1/libhydrogen/wiki/Password-hashin...
    - LaGrange 9y ago
      Hm, seems less active, and in the non-goals: "Replacing libsodium. Libhydrogen focuses on being small and is for environments where libsodium cannot be used."
      - marcosdumay 9y ago
        > libsodium ... libhydrogen ... seems less active I imagine the later author wanted things this way.
        SAI_Peregrinus 9y ago
        They're from the same author (jedisct1).
        garmaine 9y ago
adrianN 9y ago
For less than $3k you can buy hardware that can do ~13 terahashes per second, thanks to Bitcoin. That lets you brute force ten letter passwords with a 64 symbol alphabet in about a day.
- wahern 9y ago
  And? When RSA 768 came within reach of brute forcing, everybody moved to RSA 2048 and RSA 4096. To make a similar leap in attacker cost for iterative hashing solutions, your login prompt would force users to sit idly for minutes, hours, or maybe even days. And making this change systemically is still underway, taking years. Because the cost function of iterative hashing is identical between defender and attacker, you cannot pad your security in a way that is robust and generalizable against attacker capabilities in a reasonable future timeframe. How many solutions that use PBKDF, scrypt, etc, have gone back and changed their cost function (i.e. iteration count) after a year? After 3 years? After 5 years?[1] Do they tune their cost function to 8-character passwords? 10-character passwords? And no amount of iteration within a reasonable time frame is going to prevent an attacker from cracking prototypically insecure passwords. Bitcoin becomes exponentially more difficult to mine over time. As a practical matter there's no limit to the number of bad passwords in a websites database, no matter the length. Once you've implemented password salting, removing an attacker's ability to exponentially decrease his cost function for the next password cracking attempt, you're just putting lipstick on a pig. For people who care about good passwords, iterative hashing is irrelevant--a few extra random characters adds more cost than the authenticator would ever achieve with an increased iteration count. For all practical purposes, an authenticator's duty to attend to low-level algorithmic details ends at salting. After that, he maximizes security by redirecting all available effort to securing his infrastructure, catching bad passwords, and supplementing or replacing authentication with a passwordless mechanism. The emphasis on specific hardware is misguided. Real-world attackers don't use FPGAs, they use public clouds and botnets. Perhaps some governments use bespoke hardware, but even then the real gains in performance still come largely from the clustering of commodity hardware. Look at supercomputers--they moved away from bespoke hardware decades ago. Password hashing solutions that tout memory hardness and the inability to easily create bespoke hardware crackers are something dangerously close to snake oil. The features are technically legitimate but largely irrelevant in the context of real-world security. Like most snake oil, it's not that they don't add any absolute value whatsoever, but rather the magnitude of the benefit is greatly exaggerated, while the opportunity cost in misdirected resources greatly underestimated. Quibbling over a few ephemeral bits of additional attacker complexity is not a place you want to find yourself. [1] OpenBSD was one of the first, if not the first, to both add a memory hardness aspect to their hashing algorithm and a dynamic cost function with iteration, with iterated Blowfish. But they went years, if not over a decade, before updating the default iteration count. And Blowfish is of course no longer really considered memory-hard. It's more or less an abandoned idea in OpenBSD.

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.

endymi0n 9y ago

sha256 hashing rate on a modern graphics card is about 23GH/s: https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40 https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27... Not too good advice if you ask me IMHO. Here's better advice: https://codahale.com/how-to-safely-store-a-password/ https://codahale.com/how-to-safely-store-a-password/ s/bcrypt/scrypt/g if you prefer.

LaGrange 9y ago
It's 2017, use libsodium: https://download.libsodium.org/doc/password_hashing/ https://download.libsodium.org/doc/password_hashing/.
- jedisct1 9y ago
  It's almost 2018, use libhydrogen: https://github.com/jedisct1/libhydrogen/wiki/Password-hashing https://github.com/jedisct1/libhydrogen/wiki/Password-hashin...
  - LaGrange 9y ago
    Hm, seems less active, and in the non-goals: "Replacing libsodium. Libhydrogen focuses on being small and is for environments where libsodium cannot be used."
    - marcosdumay 9y ago
      > libsodium ... libhydrogen ... seems less active I imagine the later author wanted things this way.
      - SAI_Peregrinus 9y ago
        They're from the same author (jedisct1).
        garmaine 9y ago

adrianN 9y ago

For less than $3k you can buy hardware that can do ~13 terahashes per second, thanks to Bitcoin. That lets you brute force ten letter passwords with a 64 symbol alphabet in about a day.

wahern 9y ago
And? When RSA 768 came within reach of brute forcing, everybody moved to RSA 2048 and RSA 4096. To make a similar leap in attacker cost for iterative hashing solutions, your login prompt would force users to sit idly for minutes, hours, or maybe even days. And making this change systemically is still underway, taking years. Because the cost function of iterative hashing is identical between defender and attacker, you cannot pad your security in a way that is robust and generalizable against attacker capabilities in a reasonable future timeframe. How many solutions that use PBKDF, scrypt, etc, have gone back and changed their cost function (i.e. iteration count) after a year? After 3 years? After 5 years?[1] Do they tune their cost function to 8-character passwords? 10-character passwords? And no amount of iteration within a reasonable time frame is going to prevent an attacker from cracking prototypically insecure passwords. Bitcoin becomes exponentially more difficult to mine over time. As a practical matter there's no limit to the number of bad passwords in a websites database, no matter the length. Once you've implemented password salting, removing an attacker's ability to exponentially decrease his cost function for the next password cracking attempt, you're just putting lipstick on a pig. For people who care about good passwords, iterative hashing is irrelevant--a few extra random characters adds more cost than the authenticator would ever achieve with an increased iteration count. For all practical purposes, an authenticator's duty to attend to low-level algorithmic details ends at salting. After that, he maximizes security by redirecting all available effort to securing his infrastructure, catching bad passwords, and supplementing or replacing authentication with a passwordless mechanism. The emphasis on specific hardware is misguided. Real-world attackers don't use FPGAs, they use public clouds and botnets. Perhaps some governments use bespoke hardware, but even then the real gains in performance still come largely from the clustering of commodity hardware. Look at supercomputers--they moved away from bespoke hardware decades ago. Password hashing solutions that tout memory hardness and the inability to easily create bespoke hardware crackers are something dangerously close to snake oil. The features are technically legitimate but largely irrelevant in the context of real-world security. Like most snake oil, it's not that they don't add any absolute value whatsoever, but rather the magnitude of the benefit is greatly exaggerated, while the opportunity cost in misdirected resources greatly underestimated. Quibbling over a few ephemeral bits of additional attacker complexity is not a place you want to find yourself. [1] OpenBSD was one of the first, if not the first, to both add a memory hardness aspect to their hashing algorithm and a dynamic cost function with iteration, with iterated Blowfish. But they went years, if not over a decade, before updating the default iteration count. And Blowfish is of course no longer really considered memory-hard. It's more or less an abandoned idea in OpenBSD.