* 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.
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.
(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.
>The user previously authenticated creating a cache of the authentication
Maybe, it's a password encrypted secret token.
An authentication company should have known this...
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.
