Why would you need to index it by the clear-text password? You don't need to retrieve the clear-text password, it doesn't have to be stored in the cache at all.
The cache itself would be in the memory of a process which had access to cleartext passwords anyway, so presumably an exploit which allowed you to read the cache would be damning no matter what.
The parent commenter possibly meant: with an incoming request, sending a password in clear-text, how do you cache it? You hash it, then store the fact that authentication was valid with some expiry.
Once the next request, again with clear-text password, comes in you need to look up its validity. You want to check without hashing, that's the entire point. If you look up whether the hash is validly cached, you gained nothing. Hashing was required. To look up without hashing, you will need to use the clear-text password somehow. Hence it has to be part of the cache somehow, i.e. its index.
If that's all in memory in a memory-safe language, I guess it can be argued that's not unsafer than before, but I'm no expert.
> You want to check without hashing, that's the entire point.
It's not the point. There is no attempt to avoid hashing.
At this moment I'd like to be careful and distinguish between ordinary cryptographic hash functions (SHA-2, BLAKE2, etc) and key derivation functions (PBKDF2, Argon2, etc), even though both are often referred to as "hashing" in this context.
The thing about key derivation functions is that they make brute force attacks harder, because the computational cost of verifying the password is higher. They are typically parameterized so you can adjust verification cost. This is the cost we want to avoid.
However, just because you are not using your ordinary key derivation function with the parameters you normally use, it does not mean the only other option is to store passwords in plain text. You could use a key derivation function with different parameters, an HMAC with an ephemeral secret, or an ordinary cryptographic hash. These are all options, with different security tradeoffs.
Part of the evaluation of key derivation functions and their parameters is the evaluation of the risk that the hashed value is compromised. These values are stored in files or in databases, and there is a correspondingly higher risk of compromise... e.g. through backups. Your conclusions would be different for an in-memory cache which is harder to compromise and contains fewer entries, so you would naturally choose a different way of storing the passwords. Different algorithms or different parameters.
(There are also other interesting solutions around... like using an HSM to MAC the passwords.)
> At this moment I'd like to be careful and distinguish between
between a technicality (that I'm not even sure I agree with, hashing is still hashing also if you do it a million times) and what the people you're replying to were talking about. Sure, if you ignore what the topic was above then you can indeed say that nobody was trying to avoid doing hashing.
No idea what point you are trying to make here. Do you not agree with what I’m saying about hashing? Or do you just disagree with the way I said it?
You can cache password validation without storing the clear text password. That’s what I’m saying. If you don’t understand what a key stretching function is, the whole concept makes no sense, so I put a short explanation in.
