20 ms·

SHA-256 is still secure for plenty of applications, but for awhile it's been regarded as a suboptimal choice for password hashing. SHA512 is probably overkill.

eadan 6y ago
Not only sub-optimal, but unsuitable. Use algorithms specifically designed for password hashing: argon2 / scrypt etc. SHA256, SHA512 and Blake* algorithms are suitable for secure checksums and HMACs, but not password hashing
- dependenttypes 6y ago
  I disagree, I would argue that they are optimal for passwords with sufficient entropy (which includes passwords generated by a password manager) > argon2 It uses BLAKE2 internally
  - willcipriano 6y ago
    If you have two solutions and the first solution requires humans behave in a certain manner (getting them to use high entropy passwords) and the second does not. The second is more secure.
    - dependenttypes 6y ago
      I do not see how this is relevant to what I said.
      - willcipriano 6y ago
        The method you purpose is less secure as humans often use low entropy passwords even when you ask them not to. If you are building a system only for humans that use high entropy passwords (are you really willing to bet the farm on that just to save a couple clock cycles) or other machines it might work but I also see no benefit to that approach so you might as well just bcrypt it and call it a day anyway.
        dependenttypes 6y ago
        I proposed no method. I simply made the statement that typical cryptographic hash functions are optimal (and better than the alternatives) for high entropy passwords. I said nothing regarding low-entropy passwords. > I also see no benefit to that approach - less primitives - faster - less memory usage - no concern regarding cycles
  - 0x0 6y ago
    Secure checksums should have high performance. Password hashing should have low performance (ie high cost).
    - dependenttypes 6y ago
      Please justify why hashing a high entropy password should have a high cost. I can't see any benefit arising from this. If anything you lose entropy if you use something like pbkdf due to cycles.
      - 0x0 6y ago
        Because it slows down anyone looking to crack/reverse the passwords? The only thing protecting your high entropy password is the cost of the hash. If you could run infinite attempts in 2 seconds then even your high entropy password would fail. Anyways, most people don't use high entropy passwords, so there's little point in arguing against this IMHO.
        dependenttypes 6y ago
        > Because it slows down anyone looking to crack/reverse the passwords? Good luck brute-forcing through 2^256 passwords. The speed of the hash function should not matter. If you still want a slow hash function though then just use more rounds. > The only thing protecting your high entropy password is the cost of the hash No, not really. It is the fact that the password is high entropy, combined with the preimage resistance of the hash. > If you could run infinite attempts in 2 seconds then even your high entropy password would fail. So would your pkdf.
zenhack 6y ago
"for a while" suggests that this was ever a recommended choice, which is not the case. As others have pointed out, for password hashing you want a specialized algorithm, not a general purpose cryptographic hash function. This is true regardless of whether the hash function is "compromised;" it just wasn't designed for that application in the first place. Algorithms designed for password hashing are intentionally both compute and memory intensive, to make guessing slower, whereas general cryptographic hash functions are by contrast intended to be fast, as most applications will want that. The idea is that password hashing algorithms should be fast enough to keep up with a human and no faster; if you already know he password the performance is not a hindrance but if you have to guess it makes doing so impractical.
- easterncalculus 6y ago
  That's a fair point, I didn't want to come off like it was ever a great choice. I definitely would argue that people are more aware now than they used to be, so thanks for clarifying that.

eadan 6y ago

Not only sub-optimal, but unsuitable. Use algorithms specifically designed for password hashing: argon2 / scrypt etc. SHA256, SHA512 and Blake* algorithms are suitable for secure checksums and HMACs, but not password hashing

dependenttypes 6y ago
I disagree, I would argue that they are optimal for passwords with sufficient entropy (which includes passwords generated by a password manager) > argon2 It uses BLAKE2 internally
- willcipriano 6y ago
  If you have two solutions and the first solution requires humans behave in a certain manner (getting them to use high entropy passwords) and the second does not. The second is more secure.
  - dependenttypes 6y ago
    I do not see how this is relevant to what I said.
    - willcipriano 6y ago
      The method you purpose is less secure as humans often use low entropy passwords even when you ask them not to. If you are building a system only for humans that use high entropy passwords (are you really willing to bet the farm on that just to save a couple clock cycles) or other machines it might work but I also see no benefit to that approach so you might as well just bcrypt it and call it a day anyway.
      - dependenttypes 6y ago
        I proposed no method. I simply made the statement that typical cryptographic hash functions are optimal (and better than the alternatives) for high entropy passwords. I said nothing regarding low-entropy passwords. > I also see no benefit to that approach - less primitives - faster - less memory usage - no concern regarding cycles
- 0x0 6y ago
  Secure checksums should have high performance. Password hashing should have low performance (ie high cost).
  - dependenttypes 6y ago
    Please justify why hashing a high entropy password should have a high cost. I can't see any benefit arising from this. If anything you lose entropy if you use something like pbkdf due to cycles.
    - 0x0 6y ago
      Because it slows down anyone looking to crack/reverse the passwords? The only thing protecting your high entropy password is the cost of the hash. If you could run infinite attempts in 2 seconds then even your high entropy password would fail. Anyways, most people don't use high entropy passwords, so there's little point in arguing against this IMHO.
      - dependenttypes 6y ago
        > Because it slows down anyone looking to crack/reverse the passwords? Good luck brute-forcing through 2^256 passwords. The speed of the hash function should not matter. If you still want a slow hash function though then just use more rounds. > The only thing protecting your high entropy password is the cost of the hash No, not really. It is the fact that the password is high entropy, combined with the preimage resistance of the hash. > If you could run infinite attempts in 2 seconds then even your high entropy password would fail. So would your pkdf.

zenhack 6y ago

"for a while" suggests that this was ever a recommended choice, which is not the case. As others have pointed out, for password hashing you want a specialized algorithm, not a general purpose cryptographic hash function. This is true regardless of whether the hash function is "compromised;" it just wasn't designed for that application in the first place. Algorithms designed for password hashing are intentionally both compute and memory intensive, to make guessing slower, whereas general cryptographic hash functions are by contrast intended to be fast, as most applications will want that. The idea is that password hashing algorithms should be fast enough to keep up with a human and no faster; if you already know he password the performance is not a hindrance but if you have to guess it makes doing so impractical.

easterncalculus 6y ago
That's a fair point, I didn't want to come off like it was ever a great choice. I definitely would argue that people are more aware now than they used to be, so thanks for clarifying that.