5 ms·

> These functions belong to a family of functions known as key derivation functions: they use hashing to produce a digest which is suitable for use as a passwor

> These functions belong to a family of functions known as key derivation functions: they use hashing to produce a digest which is suitable for use as a password hash. KDFs are not for storing password hashes, they are for key derivation. This is a subtle point, the main thing is to use KDFs as KDFs (to derive keys that are then used to encrypt data). Details in the first link here (the second is about common mistakes when using scrypt): - http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scryp... (bad title, he's referring to pass storage, not KDF usage) - http://vnhacker.blogspot.com/2014/04/fairy-tales-in-password-hashing-with.html http://vnhacker.blogspot.com/2014/04/fairy-tales-in-password... Another consideration is plausible deniability (PD) for situations where you're compelled to disclose your password(s). Our company writes Mac encryption software that specializes in this (and it uses scrypt). Here's a list of tools that offer PD (ours is called Espionage): https://en.wikipedia.org/wiki/Deniable_encryption#Software https://en.wikipedia.org/wiki/Deniable_encryption#Software I compared Espionage's PD to TrueCrypt's on reddit: http://www.reddit.com/r/security/comments/2b5icu/major_advancements_in_deniable_encryption_arrive/cj24a1n http://www.reddit.com/r/security/comments/2b5icu/major_advan...

ShaneWilton 12y ago
You're right, there's some ambiguous wording on my part. I'll be sure to make that section more precise right now. Looking back on that section, I should also be talking about work factors and such.
- itistoday2 12y ago
  My apologies, I wasn't right. Please see this reply chain: https://news.ycombinator.com/item?id=8088208 https://news.ycombinator.com/item?id=8088208
  - ShaneWilton 12y ago
    You're right about parts of the post being unclear. I'll be rewriting that paragraph to be more precise regardless.
tptacek 12y ago
The first of these two source suggests that with typical settings, due to a quirk with the way scrypt works, it's less secure than bcrypt. The second criticizes an API design with the scrypt code. Neither makes a case that password-based KDFs are "not for storing password hashes". Using a good password KDF as a password authenticator is a fine decision.
- itistoday2 12y ago
  > 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.

ShaneWilton 12y ago

You're right, there's some ambiguous wording on my part. I'll be sure to make that section more precise right now. Looking back on that section, I should also be talking about work factors and such.

itistoday2 12y ago
My apologies, I wasn't right. Please see this reply chain: https://news.ycombinator.com/item?id=8088208 https://news.ycombinator.com/item?id=8088208
- ShaneWilton 12y ago
  You're right about parts of the post being unclear. I'll be rewriting that paragraph to be more precise regardless.

tptacek 12y ago

The first of these two source suggests that with typical settings, due to a quirk with the way scrypt works, it's less secure than bcrypt. The second criticizes an API design with the scrypt code. Neither makes a case that password-based KDFs are "not for storing password hashes". Using a good password KDF as a password authenticator is a fine decision.

itistoday2 12y ago
> 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.