5 ms·

> The second criticizes an API design with the scrypt code. Yes, I didn't claim otherwise. > Neither makes a case that password-based KDFs are "not for storin

> The second criticizes an API design with the scrypt code. Yes, I didn't claim otherwise. > Neither makes a case that password-based KDFs are "not for storing password hashes". The first one did quite explicitly for scrypt: "And that's why I don't recommend it for password storage." > Using a good password KDF as a password authenticator is a fine decision. Apparently not so for scrypt, and scrypt is the best KDF I'm aware of (heard something about yescrypt being better but haven't had a chance to look into it). I don't see why a KDF is needed for password storage. What's wrong with SHA256 + random salt? If for some reason you want a slow hash function, use the salt MOD some constant to do several rounds of SHA256 (though I don't see why that would be necessary).

tptacek 12y ago
The last sentence of this comment is exactly why I called it out. If "for some reason" you want a slow hash function? You must have a slow hash function to store a password authenticator. The salt provides virtually no protection; it blocks a single corner-case exploit.
- itistoday2 12y ago
  > You must have a slow hash function to store a password authenticator. The salt provides virtually no protection; it blocks a single corner-case exploit. You're referring to simple dictionary attacks on a large database of passwords? Even bcrypt won't help much with a password from the top 10k list. I wouldn't say that stopping rainbow tables is "virtually no protection". Please explain what you're referring to.
  - itistoday2 12y ago
    Don't understand reason for the downvote. If I'm incorrect, an explanation would be appreciated.
  - aidenn0 12y ago
    SHA256+random salt goes at about 10e9 hashes per second on a workstation with a good GPU. That's enough to do a permuted dictionary attack that will get the overwhelming majority of passwords in a system. [edit] Does anyone know if the bitcoin ASICS have been repurposed as SHA256 crackers? md5 and sha-1 are more common in password storage, but if you use what the parent suggests, then it could be worse since there is so much specialized SHA256 hardware out there.
    - gwillen 12y ago
      The bitcoin ASICs I'm aware of can't be used for cracking SHA256, because the function they compute is SHA256(SHA256(f(params)), where f is a function that stuffs some parameters into a bitcoin-specific block template before hashing.
  - chacham15 12y ago
    The reason you are being downvoted is because you apparently dont agree with the entire purpose of password hashes. The reason you cant use a hash like the sha family is because they are too fast and prone to dictionary attacks. The solution is to slow them down. That is one of the primary functions of a password hash: to provide the ability to slow down the hash computation. This is usually done with a "work factor" which translates roughly to how many times you iterate with the hashing function. This repetition allows you to make the password hash to take arbitrarily long. With a work factor of 14 (2 ^ 14 rounds), bcrypt takes about a second to compute a hash on my machine. There are approximately 100k words in the english language and add one number and you are already at 1 million seconds to reverse a single hash. Compare this to the sha family where you take fractions of a second to hash a password.
    - itistoday2 12y ago
      > The reason you are being downvoted is because you apparently dont agree with the entire purpose of password hashes. The reason you cant use a hash like the sha family is because they are too fast and prone to dictionary attacks. The solution is to slow them down. You misunderstand me. Please have a look at my reply to pbsd, I think it addresses your comments there too: https://news.ycombinator.com/item?id=8087975 https://news.ycombinator.com/item?id=8087975 I did say there: "I stand corrected about KDFs not being OK for password storage".
      - tptacek 12y ago
        I've read all your comments on this thread. I'm still unclear on why you think the problem of stretching a low-entropy secret into the high-entropy secret needed for strong cryptography is somehow different from the problem of safely storing a password so that disclosure of the authenticator doesn't directly compromise the password. At this point, given the content on this thread, it seems that it's been explained clearly enough why salted SHAx is inadequate to that task. Do you still not understand why that is? Until Windows finally got plugged into the Internet and the weak LANMAN hash became relevant to hackers, nobody used "rainbow tables" to break passwords (classic Unix crypt passwords aren't particularly vulnerable to them, since they're salted). But --- and this is crucial --- everyone cracked Unix password files. All of the original password cracking tools, from Crack through JtR, were designed to quickly crack salted hashes.
pbsd 12y ago
You mention yescrypt as an example of a good KDF, but its main design goal is to be a password hashing function! The main difference between a password-based KDF and a password hashing function is that the KDF usually needs to support variable-length output. Otherwise they perform the same task: take a secret string of low-entropy s, and stretch the cost of breaking it to 2^(s + w) for some work factor w. In other words, a KDF is a superset of a password hashing function, and it's OK to use it as one.
- itistoday2 12y ago
  > You mention yescrypt as an example of a good KDF, but its main design goal is to be a password hashing function! I mentioned I'd heard it was a good KDF (not a good password storage function). I didn't know that was its main purpose. Thanks, will need to read more about it. Still, there's marginal returns on how much w can be increased while keeping the KDF useful, right? There's only so much magic they can do for a weak password. The article on scrypt being a poor candidate for password storage stuck out in my memory. I haven't seen or heard of the practice of strong hash function + random salt for password storage falling out of favor, so I didn't look into using other KDFs for that purpose. EDIT: it does seem like a trade off. This article seems to have a good explanation of it: https://crackstation.net/hashing-security.htm https://crackstation.net/hashing-security.htm If you use a key stretching hash in a web application, be aware that you will need extra computational resources to process large volumes of authentication requests, and that key stretching may make it easier to run a Denial of Service (DoS) attack on your website. I still recommend using key stretching, but with a lower iteration count. You should calculate the iteration count based on your computational resources and the expected maximum authentication request rate. The denial of service threat can be eliminated by making the user solve a CAPTCHA every time they log in. Always design your system so that the iteration count can be increased or decreased in the future. I do stand corrected about KDFs not being OK for password storage. Seems like they can be overkill in some situations, but in general do a good job of protecting passwords.
  - pbsd 12y ago
    Yes, realistically you can only add at most ~30 bits of security to a password. This does not save very poor passwords, but can save decent ones. 'Strong' means different things in different contexts. SHA-256, for example, is a strong hash function: it has good preimage and collision resistance. However, a function is evaluated by its weakest point: when given a low-entropy secret (which is not the assumption in a strong hash function) and a strong hash function, the easiest attack is to bruteforce it by sampling its distribution (e.g., the most common password patterns). Since SHA-256 is fast, bruteforce is naturally also fast: the average time-to-break for a string of entropy s is 2^(s-1) times the cost of a SHA-256 evaluation. You can build on this by, say, iterating on SHA-256: def pwdhash(input, salt, w): h = sha256(salt + input).digest() for i in range(2**w): h = sha256(h).digest() return h But once you get into these ad hoc schemes to make the password hash less amenable to bruteforce, you're basically reinventing PBKDF2. scrypt (and bcrypt, to some extent) is like the above, but also uses random memory accesses on a large buffer to make things harder for specialized hardware (think GPUs, FPGAs, etc).

tptacek 12y ago

The last sentence of this comment is exactly why I called it out. If "for some reason" you want a slow hash function? You must have a slow hash function to store a password authenticator. The salt provides virtually no protection; it blocks a single corner-case exploit.

itistoday2 12y ago
> You must have a slow hash function to store a password authenticator. The salt provides virtually no protection; it blocks a single corner-case exploit. You're referring to simple dictionary attacks on a large database of passwords? Even bcrypt won't help much with a password from the top 10k list. I wouldn't say that stopping rainbow tables is "virtually no protection". Please explain what you're referring to.
- itistoday2 12y ago
  Don't understand reason for the downvote. If I'm incorrect, an explanation would be appreciated.
- aidenn0 12y ago
  SHA256+random salt goes at about 10e9 hashes per second on a workstation with a good GPU. That's enough to do a permuted dictionary attack that will get the overwhelming majority of passwords in a system. [edit] Does anyone know if the bitcoin ASICS have been repurposed as SHA256 crackers? md5 and sha-1 are more common in password storage, but if you use what the parent suggests, then it could be worse since there is so much specialized SHA256 hardware out there.
  - gwillen 12y ago
    The bitcoin ASICs I'm aware of can't be used for cracking SHA256, because the function they compute is SHA256(SHA256(f(params)), where f is a function that stuffs some parameters into a bitcoin-specific block template before hashing.
- chacham15 12y ago
  The reason you are being downvoted is because you apparently dont agree with the entire purpose of password hashes. The reason you cant use a hash like the sha family is because they are too fast and prone to dictionary attacks. The solution is to slow them down. That is one of the primary functions of a password hash: to provide the ability to slow down the hash computation. This is usually done with a "work factor" which translates roughly to how many times you iterate with the hashing function. This repetition allows you to make the password hash to take arbitrarily long. With a work factor of 14 (2 ^ 14 rounds), bcrypt takes about a second to compute a hash on my machine. There are approximately 100k words in the english language and add one number and you are already at 1 million seconds to reverse a single hash. Compare this to the sha family where you take fractions of a second to hash a password.
  - itistoday2 12y ago
    > The reason you are being downvoted is because you apparently dont agree with the entire purpose of password hashes. The reason you cant use a hash like the sha family is because they are too fast and prone to dictionary attacks. The solution is to slow them down. You misunderstand me. Please have a look at my reply to pbsd, I think it addresses your comments there too: https://news.ycombinator.com/item?id=8087975 https://news.ycombinator.com/item?id=8087975 I did say there: "I stand corrected about KDFs not being OK for password storage".
    - tptacek 12y ago
      I've read all your comments on this thread. I'm still unclear on why you think the problem of stretching a low-entropy secret into the high-entropy secret needed for strong cryptography is somehow different from the problem of safely storing a password so that disclosure of the authenticator doesn't directly compromise the password. At this point, given the content on this thread, it seems that it's been explained clearly enough why salted SHAx is inadequate to that task. Do you still not understand why that is? Until Windows finally got plugged into the Internet and the weak LANMAN hash became relevant to hackers, nobody used "rainbow tables" to break passwords (classic Unix crypt passwords aren't particularly vulnerable to them, since they're salted). But --- and this is crucial --- everyone cracked Unix password files. All of the original password cracking tools, from Crack through JtR, were designed to quickly crack salted hashes.

pbsd 12y ago

You mention yescrypt as an example of a good KDF, but its main design goal is to be a password hashing function! The main difference between a password-based KDF and a password hashing function is that the KDF usually needs to support variable-length output. Otherwise they perform the same task: take a secret string of low-entropy s, and stretch the cost of breaking it to 2^(s + w) for some work factor w. In other words, a KDF is a superset of a password hashing function, and it's OK to use it as one.

itistoday2 12y ago
> You mention yescrypt as an example of a good KDF, but its main design goal is to be a password hashing function! I mentioned I'd heard it was a good KDF (not a good password storage function). I didn't know that was its main purpose. Thanks, will need to read more about it. Still, there's marginal returns on how much w can be increased while keeping the KDF useful, right? There's only so much magic they can do for a weak password. The article on scrypt being a poor candidate for password storage stuck out in my memory. I haven't seen or heard of the practice of strong hash function + random salt for password storage falling out of favor, so I didn't look into using other KDFs for that purpose. EDIT: it does seem like a trade off. This article seems to have a good explanation of it: https://crackstation.net/hashing-security.htm https://crackstation.net/hashing-security.htm If you use a key stretching hash in a web application, be aware that you will need extra computational resources to process large volumes of authentication requests, and that key stretching may make it easier to run a Denial of Service (DoS) attack on your website. I still recommend using key stretching, but with a lower iteration count. You should calculate the iteration count based on your computational resources and the expected maximum authentication request rate. The denial of service threat can be eliminated by making the user solve a CAPTCHA every time they log in. Always design your system so that the iteration count can be increased or decreased in the future. I do stand corrected about KDFs not being OK for password storage. Seems like they can be overkill in some situations, but in general do a good job of protecting passwords.
- pbsd 12y ago
  Yes, realistically you can only add at most ~30 bits of security to a password. This does not save very poor passwords, but can save decent ones. 'Strong' means different things in different contexts. SHA-256, for example, is a strong hash function: it has good preimage and collision resistance. However, a function is evaluated by its weakest point: when given a low-entropy secret (which is not the assumption in a strong hash function) and a strong hash function, the easiest attack is to bruteforce it by sampling its distribution (e.g., the most common password patterns). Since SHA-256 is fast, bruteforce is naturally also fast: the average time-to-break for a string of entropy s is 2^(s-1) times the cost of a SHA-256 evaluation. You can build on this by, say, iterating on SHA-256: def pwdhash(input, salt, w): h = sha256(salt + input).digest() for i in range(2**w): h = sha256(h).digest() return h But once you get into these ad hoc schemes to make the password hash less amenable to bruteforce, you're basically reinventing PBKDF2. scrypt (and bcrypt, to some extent) is like the above, but also uses random memory accesses on a large buffer to make things harder for specialized hardware (think GPUs, FPGAs, etc).