6 ms·

There's nothing unlikely with such scenario. See MD5, SHA1 and so on. See current research on SHA256 https://en.wikipedia.org/wiki/SHA-2#Cryptanalysis_and_val

There's nothing unlikely with such scenario. See MD5, SHA1 and so on. See current research on SHA256 https://en.wikipedia.org/wiki/SHA-2#Cryptanalysis_and_validation https://en.wikipedia.org/wiki/SHA-2#Cryptanalysis_and_valida... https://dusted.codes/sha-256-is-not-a-secure-password-hashing-algorithm https://dusted.codes/sha-256-is-not-a-secure-password-hashin... https://security.stackexchange.com/questions/34256/sha256-security-what-does-it-mean-that-attacks-have-broken-46-of-the-60-rounds https://security.stackexchange.com/questions/34256/sha256-se...

hannob 5y ago
The Wikipedia link is very reassuring regarding the security of SHA256. All attacks are very far away from going anywhere close to attacking full SHA256 and no major progress has been made lately. The password hashing remark is correct, but irrelevant. SHA256 is not a good password hash, because it's not made to be a password hash. Don't use it for passwords. The weaknesses that broke MD5/SHA1 were known since 1994. No similar weakness is known for SHA256.
- alophawen 5y ago
  If you want to be reassured then sure. My take from reading that is in 2016 there was practical collision attacks demonstrated, which would be amplified with specialized hardware (compare to bitcoin mining). Btw cheers! I recall you from correspondence years ago regarding fuzz testing linux packages.
  - hannob 5y ago
    > My take from reading that is in 2016 there was practical collision attacks demonstrated No such thing happened. You're likely referring to this paper quoted in Wikipedia: https://eprint.iacr.org/2016/374.pdf https://eprint.iacr.org/2016/374.pdf This is 1. not about SHA256, but about the truncated sha2 algorithms and, more important, 2. it's an attack on reduced-round versions of these algorithms. That's a common thing in cryptoanalysis to do. You're basically saying "we have no way of attacking the full algorithm, so let's build a version which is much less secure and try to attack that". That's a valid thing to do for research purposes, but it needs to be interpreted correctly. "I can break this massively weaker version of the algorithm" is very different from "I have shown a practical attack on the real algorithm".
    - alophawen 5y ago
      Absolutely, you are correct - the papers does not describe SHA256 as broken, but it is one step of many on the path for SHA256 to become broken in the future - which is in reply to your earlier comment: > You're proposing to add extra complexity for some hypothetical scenario that is unlikely to happen
      - ttybird2 5y ago
        I do not believe that the practical demonstration of a sha1 collision by google contributed at all to any potential future break of sha256.
      - SAI_Peregrinus 5y ago
        > but it is one step of many on the path for SHA256 to become broken in the future I disagree. It's evidence that the given path is not fruitful for breaking SHA256 in the future. When numerous researchers worldwide have attacked a function, and only broken X out of N rounds, for X << N, and future research hasn't been able to improve X for years, that's pretty good evidence that the technique used isn't going to continue to apply for more rounds. The existence of a multi-billion dollar bug bounty for breaking SHA256 (Bitcoin) that's gone unclaimed for years is further evidence that it's quite strong.
- otterley 5y ago
  I’m not a cryptographer. Why isn’t SHA256 good as a password hash? Can you explain? And what’s a better alternative, and why?
  - xblau 5y ago
    > Why isn’t SHA256 good as a password hash? Because it wasn't designed for it. For password hashing you want a hash that has a salt (so that the same password on two accounts doesn't have the same hash on the database) and is as slow as possible (that is, fast enough to validate on logins) to increase brute-force time. Historically Bcrypt was a good option, but I think Argon2[0] is the current best option. [0] https://en.wikipedia.org/wiki/Argon2 https://en.wikipedia.org/wiki/Argon2
    - otterley 5y ago
      I thought adding a salt to a password before hashing it was standard practice, regardless of the hashing function. At least that's how UNIX derivatives have done it for the past 25+ years. Point taken about hash calculation speed, though.
  - black_knight 5y ago
    Because SHA256 is fast to compute. This means that an attacker can quickly try many passwords, either from a dictionary of common passwords or simply brute forcing a short password. Also, if you use SHA256 bare without salt you are vulnerable to precomputed dictionaries. There is a fascinating way to make these dictionaries shorter called Rainbow Tables. Better key derivation functions take a lot of time and memory to make it costly for the attacker to a lot of guesses at the password and they have built in salt. Examples would be SCrypt or Argon2.
  - SAI_Peregrinus 5y ago
    To add to what others have already said: A password hash is a function with 3 inputs: the password, the difficulty factor, and a customization structure (most often just a salt, sometimes more). A cryptographic hash is a function with 1 input: the message. Password hashing functions have variable performance in time and usually memory and cache use, controlled by the difficulty factor. Cryptographic hashes have fixed performance. Password hashing functions take a salt and possibly other customization data (a secret "pepper", a fixed domain-separation string if it's also a key derivation function, etc). It's possible to build password hashes from cryptographic hashes. One must be very careful about encoding the multiple inputs into a single "message" for the cryptographic hash, to avoid cannonicalization attacks. Argon2id is a good password hashing function.

hannob 5y ago

The Wikipedia link is very reassuring regarding the security of SHA256. All attacks are very far away from going anywhere close to attacking full SHA256 and no major progress has been made lately. The password hashing remark is correct, but irrelevant. SHA256 is not a good password hash, because it's not made to be a password hash. Don't use it for passwords. The weaknesses that broke MD5/SHA1 were known since 1994. No similar weakness is known for SHA256.

alophawen 5y ago
If you want to be reassured then sure. My take from reading that is in 2016 there was practical collision attacks demonstrated, which would be amplified with specialized hardware (compare to bitcoin mining). Btw cheers! I recall you from correspondence years ago regarding fuzz testing linux packages.
- hannob 5y ago
  > My take from reading that is in 2016 there was practical collision attacks demonstrated No such thing happened. You're likely referring to this paper quoted in Wikipedia: https://eprint.iacr.org/2016/374.pdf https://eprint.iacr.org/2016/374.pdf This is 1. not about SHA256, but about the truncated sha2 algorithms and, more important, 2. it's an attack on reduced-round versions of these algorithms. That's a common thing in cryptoanalysis to do. You're basically saying "we have no way of attacking the full algorithm, so let's build a version which is much less secure and try to attack that". That's a valid thing to do for research purposes, but it needs to be interpreted correctly. "I can break this massively weaker version of the algorithm" is very different from "I have shown a practical attack on the real algorithm".
  - alophawen 5y ago
    Absolutely, you are correct - the papers does not describe SHA256 as broken, but it is one step of many on the path for SHA256 to become broken in the future - which is in reply to your earlier comment: > You're proposing to add extra complexity for some hypothetical scenario that is unlikely to happen
    - ttybird2 5y ago
      I do not believe that the practical demonstration of a sha1 collision by google contributed at all to any potential future break of sha256.
    - SAI_Peregrinus 5y ago
      > but it is one step of many on the path for SHA256 to become broken in the future I disagree. It's evidence that the given path is not fruitful for breaking SHA256 in the future. When numerous researchers worldwide have attacked a function, and only broken X out of N rounds, for X << N, and future research hasn't been able to improve X for years, that's pretty good evidence that the technique used isn't going to continue to apply for more rounds. The existence of a multi-billion dollar bug bounty for breaking SHA256 (Bitcoin) that's gone unclaimed for years is further evidence that it's quite strong.
otterley 5y ago
I’m not a cryptographer. Why isn’t SHA256 good as a password hash? Can you explain? And what’s a better alternative, and why?
- xblau 5y ago
  > Why isn’t SHA256 good as a password hash? Because it wasn't designed for it. For password hashing you want a hash that has a salt (so that the same password on two accounts doesn't have the same hash on the database) and is as slow as possible (that is, fast enough to validate on logins) to increase brute-force time. Historically Bcrypt was a good option, but I think Argon2[0] is the current best option. [0] https://en.wikipedia.org/wiki/Argon2 https://en.wikipedia.org/wiki/Argon2
  - otterley 5y ago
    I thought adding a salt to a password before hashing it was standard practice, regardless of the hashing function. At least that's how UNIX derivatives have done it for the past 25+ years. Point taken about hash calculation speed, though.
- black_knight 5y ago
  Because SHA256 is fast to compute. This means that an attacker can quickly try many passwords, either from a dictionary of common passwords or simply brute forcing a short password. Also, if you use SHA256 bare without salt you are vulnerable to precomputed dictionaries. There is a fascinating way to make these dictionaries shorter called Rainbow Tables. Better key derivation functions take a lot of time and memory to make it costly for the attacker to a lot of guesses at the password and they have built in salt. Examples would be SCrypt or Argon2.
- SAI_Peregrinus 5y ago
  To add to what others have already said: A password hash is a function with 3 inputs: the password, the difficulty factor, and a customization structure (most often just a salt, sometimes more). A cryptographic hash is a function with 1 input: the message. Password hashing functions have variable performance in time and usually memory and cache use, controlled by the difficulty factor. Cryptographic hashes have fixed performance. Password hashing functions take a salt and possibly other customization data (a secret "pepper", a fixed domain-separation string if it's also a key derivation function, etc). It's possible to build password hashes from cryptographic hashes. One must be very careful about encoding the multiple inputs into a single "message" for the cryptographic hash, to avoid cannonicalization attacks. Argon2id is a good password hashing function.