5 ms·

> The answer should have been immediately -- "you don't encrypt passwords, you hash passwords using a well known, established, and tested cryptographic hashing

> The answer should have been immediately -- "you don't encrypt passwords, you hash passwords using a well known, established, and tested cryptographic hashing algorithm + a salt, damnit!" Your answer is as wrong as anything posted on that discussion. The correct answer is that you don't encrypt passwords. You also don't hash passwords with a salt. Instead, you use a key derivation function such as PBKDF2, bcrypt, or scrypt.

sarciszewski 12y ago
https://github.com/defuse/password-hashing/issues/39#issuecomment-52799173 https://github.com/defuse/password-hashing/issues/39#issueco... "Therefore all KDF functions are cryptographic hash functions. All hash functions are not KDFs, due to speed."
- owenmarshall 12y ago
  "Cryptographic hash" has been used to refer to non-invertable hash functions since the late 70s. Using that term to refer to a KDF is exceptionally misleading and foolish. If you gave that answer to those PHP developers, they'd come out thinking MD5 and a salt would Work Just Fine.
  - sarciszewski 12y ago
    Point of order: The post you replied to was not "as wrong" as the participants in that forum ;)
    - owenmarshall 12y ago
      A KDF, as your link notes, meets all the properties of a cryptographic hash. The important property it has that other non-cryptographic hashes do not have is speed (actually, a lack thereof) and (typically) the ability to tune that speed. If we want "technically correct" points I won't grant them (;-)) because KDFs have a property (slowness) cryptographic hashes do not. It would be technically correct to state that KDFs are strict supersets of cryptographic hashes. Practically speaking, calling a KDF a cryptographic hash is very harmful because the average programmer doesn't have the understanding to make the distinction. It's important to give them two very clearly separated categories - cryptographic hashes are {SHA1, RIPEMD160, ...} and are FAST, KDFs are {scrypt, bcrypt, ...} and are SLOW - and a clear rule that "you MUST always use a KDF to store passwords". If you blur the lines between the two, the average programmer will misunderstand and use the wrong tool for the job.
      - TheLoneWolfling 12y ago
        Alright, so, question. Why would the speed of the hash function make any difference, assuming it's a cryptographic hash? If it's faster, run it for more iterations - if it's slower, run it for less. You pick a maximum time, figure out how many iterations can be run in that time, and go from there. I would have thought that a fast hash function would be better, if anything - as it's potentially already more optimized for current hardware, which means that it's less likely that it will get faster on better hardware. I always thought it was the memory complexity of the hash function that was the difference, not speed. Makes it harder to run on GPUs / ASICs.
        derefr 12y ago
        If you’re iterating the hash function until it’s “sufficiently slow", the result is a (one-off, badly-designed) key-derivation function. That’s how they work.
Buttons840 12y ago
You should hash passwords with a long random salt. You advocate using bcrypt, and bcrypt requires a salt. If you are not using a salt, then you are vulnerable to rainbow tables which contain a few hundred thousand of the most common passwords. Even if your hashing algorithm is slow and complex, there are still rudimentary rainbow tables for them. If you haven't used a salt then with one quick scan at least of few of your passwords will be revealed. The effect of a long random salt is to make every password appear to longer to the hashing algorithm. What's being hashed is the users password plus 20 random characters, and nobody has a rainbow table that contain those 20 random characters. If your hashing algorithm, like bcrypt, accepts the salt as an argument, then that makes things all the easier.
- owenmarshall 12y ago
  > You should hash passwords (...) You should not hash passwords. You should never hash a password. You should use an appropriate key derivation function (bcrypt, scrypt, PBKDF2). Key derivation functions are designed to address the issues you note and many more. Now, let me give a few choice tptacek quotes on this: >The socialbookmarkosphere is abuzz with talk of “rainbow tables”(...) This really freaks me out. If the “advanced” pole of your threat model is “rainbow tables”, stop working on your social shopping cart calendar application right now: I can’t trust you with my Reddit karma score, let alone my credit card number. > Rainbow tables are easy to beat. For each password, generate a random number [... and do what you said to do ...] Cool, huh? Yeah, and Unix crypt —- almost the lowest common denominator in security systems —- has had this feature since 1976. If this is news to you, you shouldn’t be designing password systems. Use someone else’s good one. --- I'm banging on this drum for a very simple reason: even if you are smart enough to know that salt+general purpose cryptographic hash function isn't good enough, when you say "hash" programmers that aren't smart enough are getting the wrong message. And if you do believe a "hashing algorithm with a long random salt" (which I translate to "general-purpose cryptographic hash function, such as SHA/RIPEMD + a nonce") is sufficient to store a password... well, let's hope you don't.

sarciszewski 12y ago

https://github.com/defuse/password-hashing/issues/39#issuecomment-52799173 https://github.com/defuse/password-hashing/issues/39#issueco... "Therefore all KDF functions are cryptographic hash functions. All hash functions are not KDFs, due to speed."

owenmarshall 12y ago
"Cryptographic hash" has been used to refer to non-invertable hash functions since the late 70s. Using that term to refer to a KDF is exceptionally misleading and foolish. If you gave that answer to those PHP developers, they'd come out thinking MD5 and a salt would Work Just Fine.
- sarciszewski 12y ago
  Point of order: The post you replied to was not "as wrong" as the participants in that forum ;)
  - owenmarshall 12y ago
    A KDF, as your link notes, meets all the properties of a cryptographic hash. The important property it has that other non-cryptographic hashes do not have is speed (actually, a lack thereof) and (typically) the ability to tune that speed. If we want "technically correct" points I won't grant them (;-)) because KDFs have a property (slowness) cryptographic hashes do not. It would be technically correct to state that KDFs are strict supersets of cryptographic hashes. Practically speaking, calling a KDF a cryptographic hash is very harmful because the average programmer doesn't have the understanding to make the distinction. It's important to give them two very clearly separated categories - cryptographic hashes are {SHA1, RIPEMD160, ...} and are FAST, KDFs are {scrypt, bcrypt, ...} and are SLOW - and a clear rule that "you MUST always use a KDF to store passwords". If you blur the lines between the two, the average programmer will misunderstand and use the wrong tool for the job.
    - TheLoneWolfling 12y ago
      Alright, so, question. Why would the speed of the hash function make any difference, assuming it's a cryptographic hash? If it's faster, run it for more iterations - if it's slower, run it for less. You pick a maximum time, figure out how many iterations can be run in that time, and go from there. I would have thought that a fast hash function would be better, if anything - as it's potentially already more optimized for current hardware, which means that it's less likely that it will get faster on better hardware. I always thought it was the memory complexity of the hash function that was the difference, not speed. Makes it harder to run on GPUs / ASICs.
      - derefr 12y ago
        If you’re iterating the hash function until it’s “sufficiently slow", the result is a (one-off, badly-designed) key-derivation function. That’s how they work.

Buttons840 12y ago

You should hash passwords with a long random salt. You advocate using bcrypt, and bcrypt requires a salt. If you are not using a salt, then you are vulnerable to rainbow tables which contain a few hundred thousand of the most common passwords. Even if your hashing algorithm is slow and complex, there are still rudimentary rainbow tables for them. If you haven't used a salt then with one quick scan at least of few of your passwords will be revealed. The effect of a long random salt is to make every password appear to longer to the hashing algorithm. What's being hashed is the users password plus 20 random characters, and nobody has a rainbow table that contain those 20 random characters. If your hashing algorithm, like bcrypt, accepts the salt as an argument, then that makes things all the easier.

owenmarshall 12y ago
> You should hash passwords (...) You should not hash passwords. You should never hash a password. You should use an appropriate key derivation function (bcrypt, scrypt, PBKDF2). Key derivation functions are designed to address the issues you note and many more. Now, let me give a few choice tptacek quotes on this: >The socialbookmarkosphere is abuzz with talk of “rainbow tables”(...) This really freaks me out. If the “advanced” pole of your threat model is “rainbow tables”, stop working on your social shopping cart calendar application right now: I can’t trust you with my Reddit karma score, let alone my credit card number. > Rainbow tables are easy to beat. For each password, generate a random number [... and do what you said to do ...] Cool, huh? Yeah, and Unix crypt —- almost the lowest common denominator in security systems —- has had this feature since 1976. If this is news to you, you shouldn’t be designing password systems. Use someone else’s good one. --- I'm banging on this drum for a very simple reason: even if you are smart enough to know that salt+general purpose cryptographic hash function isn't good enough, when you say "hash" programmers that aren't smart enough are getting the wrong message. And if you do believe a "hashing algorithm with a long random salt" (which I translate to "general-purpose cryptographic hash function, such as SHA/RIPEMD + a nonce") is sufficient to store a password... well, let's hope you don't.