They wanted the cache entry to be invalidated when the password changed. Just using username as the key and storing the bcrypt password inside the cache entry and checking the password on load seems like a better solution if it was possible.
According to the security advisory this cache was for AD/LDAP delegated authentication, so they don't have their own password database with a version field or similar for sensible invalidation.
I guess the requirements could be something like:
- different username/password combinations must have separately cached results
- mitigate a potential data leak by putting all the entropy we have available together with the password material and using a slow password hashing function