6 ms·
Not only sub-optimal, but unsuitable. Use algorithms specifically designed for password hashing: argon2 / scrypt etc. SHA256, SHA512 and Blake* algorithms are
by 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 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.