5 ms·
They didn't want a KDF, as far as I know, but they wanted a hash function with unlimited input size. Including the username in the hash input gives you guarant
by pclmulqdq 2y ago
They didn't want a KDF, as far as I know, but they wanted a hash function with unlimited input size.
Including the username in the hash input gives you guaranteed domain separation between users that you don't get from salts/nonces. Its a generally good idea if you have a hash function with unlimited input size (all modern cryptographic hash functions except bcrypt have unlimited input size).
- masklinn 2y agoThey clearly wanted something stronger than "a hash function" or they'd have reached for weaker cryptographic hashes.
- pclmulqdq 2y agoThey wanted a hard-to-compute cryptographic hash function. Today, that means bcrypt or something with a KDF construction. However, they needed one with unlimited input size, which rules out bcrypt.
- tptacek 2y agoOr just a hash of the bcrypt hash, for the password! I don't like using thought-stopping cliches any more than anybody else does, but this design feels a little cargo-culted. All this stuff follows the more fundamental question of "why is the password mixed into a cache key"?
- pclmulqdq 2y agoYeah, I think both of the following would have worked if they wanted the password involved in a cache key and they wanted bcrypt to be used: * bcrypt(SHA-512(PW || stuff)) * SHA(stuff || bcrypt(PW)) Disclaimer: Not cryptography advice. It's still unclear to me why the password is in there.
- Vecr 2y agoFor 'unlimited' input size it should be SHA-3-512. Maybe too slow, but Bcrypt is slower, right? Less things to go wrong too.
- pclmulqdq 2y agoAll of the SHA functions allow unlimited input size. And yes, bcrypt computation time dwarfs that of SHA-3. The SHA-3 family has "extendable-output functions," which can ostensibly be used to generate unlimited numbers of bits (albeit with only a given security level). These are new to SHA-3.
- Vecr 2y agoSHA-3 has more internal state, it really is plausibly better at handling very large data. If 'unlimited' is really less than a gigabyte, there's no problem. It's mostly the preimage series of attacks and length extension at that point. SHA-3 is better on those. SHA-512 has zero length extension attack resistance.
- pclmulqdq 2y agoInternal state length may be a bit of a red herring (note that SHA-3 makes up for that longer internal state by ingesting more data per round), but SHA-3 probably has a higher security margin than the SHA-2 construction mostly because we have had sponge constructions for less time than we have had Merkle-Damgard constructions. NIST basically forced a higher security margin on SHA-3. You are correct about the length extension attacks (although these are mitigated by using SHA-2-512/256 for example), but I don't think that matters here.
- tptacek 2y agoEw. Just HMAC. Don't use truncated SHA2.
- 2y ago
- jedisct1 2y agobcrypt-pbkdf (used in OpenSSH) exists for that purpose.
- nyclounge 2y agoWould scrypt solve this problem? Or is it same as bcrypt? Or is scrypt depending on the hardware?
- taurknaut 2y ago> but they wanted a hash function with unlimited input size I'm kind of baffled how they came to use bcrypt for this. Bcrypt is not exactly subtle about only supporting 72 bytes of input. And this is at a company who provides auth as a service; I've got to imagine they had multiple engineers who knew this (I guess not working on that code). Hell, I know this and I've only used bcrypt twice and I'm nowhere near a security/crypto guy.
- bufferoverflow 2y agoBCrypt should loudly fail if more than 72 bytes are sent to its input.
- taurknaut 2y agoMaybe it should. Discarding the rest of the bytes works fine for passwords, though. I guess that's just not sufficient.
- pclmulqdq 2y agoIn my book, discarding entropy is a generally dumb thing to do. Passwords are usually under 72 chars, but a lot of people use concatenations of usernames and passwords in their hash to get guaranteed domain separation between users.