Hacker News Reader

Comment by ww520 | Hacker News Reader

How safe is SHA-256 now? Or Is SHA-512 needed in the near future?

Well, there's already a SHA-512.

But none of the SHA family of hashes have ever been recommended for passwords, not because they are weak, but because they are too fast.

For other purposes, the logical successor to SHA-256/512 is SHA-3:

https://en.wikipedia.org/wiki/SHA-3

But this is far from the only choice. Hashing algorithms are trendy right now, and there's plenty to choose from.

I am not sure why you mentioned passwords. Collision attacks do not affect the use of hash functions for password hashing.

For collision avoidance, not for cryptographic hashing.

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.

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

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

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.

I do not see how this is relevant to what I said.

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.

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

Secure checksums should have high performance. Password hashing should have low performance (ie high cost).

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.

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.

> 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.

"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.

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.

Safe enough, but why not use a modern hash function instead?

What are some of the modern hashing alternative for uniqueness? Mainly for speed, bit distribution, and collision risk while having small hash size. Not for cryptographic purpose.

Depends on what you want to do. For hash tables and macs there is siphash. There is also Chaskey (although this is optimised for embedded systems I think).

Also in the super fast, but not designed to be cryptographically secure category:

xxhash (https://github.com/Cyan4973/xxHash) with 32/64 bit output. The latest version, xxh3, supports up to 128 bit output.

meow hash (https://github.com/cmuratori/meow_hash)

The recently released Blake3 which is designed to be cryptographically secure is very fast also (https://github.com/BLAKE3-team/BLAKE3)

Reply on news.ycombinator.com