Hacker News Reader

Comment by ronsor | Hacker News Reader

Do we need to put the password in the cache key?

Can't believe the answers you're getting. The answer's a big fat NO. If you find yourself in that situation, there's something very incorrect with your design.

So how would you design it instead?

    key = anyhash(uuid+username)
    if (result := cache.get(uuid+username)):
        if hash_and_equality(password, result.password_hash):
            return result.the_other_stuff
    # try login or else fail

Some insight into why this is good and why including the password as input in the derivation of the cache key is terrible would be appreciated.

With no password in key: mildly cleaner to drop entries on password change, even if the cache didn't get the command to drop the key, the next login would override the old key's value anyhow, instead of potentially a key per password that was valid in the short period around a password change

Of course, if you have any validness of old sessions / passwords around a password change, you are doing something wrong.

My personal wondering is, considering KDF is meant to be expensive, why is IO more expensive to the point it needs a cache?

Thanks, good points.

> why is IO more expensive to the point it needs a cache

The advisory mentions it's only exploitable if the upstream auth server is unresponsive. So it seems to be mainly for resilience.

If you want to validate a username/password authn attempt against a cache, then yes the username and password have to be someone in the mix.

If the user changes password it invalidates the cache entries automatically, so you avoid stale credentials exploiting the cache

At least that's my immediate thought, could be wrong.

Reply on news.ycombinator.com