Hacker News Reader

Comment by sebastialonso | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com