3 ms·
They wanted a hard-to-compute cryptographic hash function. Today, that means bcrypt or something with a KDF construction. However, they needed one with unlimite
by pclmulqdq 2y ago
They 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.
- hn_go_brrrrr 2y agoWhy?
- jedisct1 2y agohmac-bcrypt solves that problem very well, and should replace plain bcrypt: https://github.com/epixoip/hmac-bcrypt https://github.com/epixoip/hmac-bcrypt
- tptacek 2y agoI don't think it's a good idea for people to adopt new bcrypt constructions so that they can use it to generate cache keys (or, worse, other keys). (I need that "man standing up in the town hall meeting" meme for this.) Just use a real KDF, if that's really what you want. I'm still confused what password-derived material is doing in a Redis key.
- petedoyle 2y agoMaybe they wanted some cached data to get invalidated if users change their passwords?
- duskwuff 2y agoThen use some other data which can act as a proxy for that, like the date of the last credential change. Using the password itself is a terrible security smell.
- GoblinSlayer 2y agoBy cache they mean cached credentials. >The user previously authenticated creating a cache of the authentication Maybe, it's a password encrypted secret token.
- GoblinSlayer 2y agoOn the other hand Redis on the server side makes more sense as an LDAP backup, but then mapping should be user id -> bcrypt hash.
- earnestinger 2y agoCould you give an example of real KDF?
- riffraff 2y agoPerhaps the password is used as part of the cache Key so that a password update implicitly invalidates the cache?
- dspillett 2y ago> It's still unclear to me why the password is in there. Perhaps they did not want to apply cache invalidation purely by the passage of time, or want that passage of time to be long, but wanted to treat a credentials update as a cache invalidating event. A safer way to implement that would perhaps be to have a concept of a version of an account, incremented when authentication options or other significant properties change, and including that in the cache key. I'm not sure why it would matter though: even if a credentials change does invalidate the cache from the PoV of the user looking up information, the information is potentially still in the cache so could still be referred to by someone else who has gained knowledge of the old credentials.
- 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?