4 ms·
How safe is SHA-256 now? Or Is SHA-512 needed in the near future?
by ww520 6y ago
How safe is SHA-256 now? Or Is SHA-512 needed in the near future?
- easterncalculus 6y agoSHA-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 agoNot 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 agoI 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 agoIf 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 agoI do not see how this is relevant to what I said.
- willcipriano 6y agoThe 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 agoI 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 agoSecure checksums should have high performance. Password hashing should have low performance (ie high cost).
- dependenttypes 6y agoPlease 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 agoBecause 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 agoThat'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.
- LeoPanthera 6y agoWell, 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 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.
- dependenttypes 6y agoI am not sure why you mentioned passwords. Collision attacks do not affect the use of hash functions for password hashing.
- ww520 6y agoFor collision avoidance, not for cryptographic hashing.
- dependenttypes 6y agoSafe enough, but why not use a modern hash function instead?
- ww520 6y agoWhat 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.
- dependenttypes 6y agoDepends 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).
- eadan 6y agoAlso in the super fast, but not designed to be cryptographically secure category: xxhash (https://github.com/Cyan4973/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 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 https://github.com/BLAKE3-team/BLAKE3)