Yes, the hashed payload contained a password, so presumably they didn't want to just SHA it.

Begs the question of why the payload contained a password, right?

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.

Storing the bcrypt password in the entry would make a dump of the cache almost as good as a dump of the password database. At least this way a dump of the cache makes the key opaque and requires you to guess both the username/id and password together, assuming they're not repeated in the cache value.

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

But why not bcrypt the password, but sha the cache key on top?

I guess because they didn't anticipate this flaw.

Also prehashing opens you up to an other bcrypt flaw you need to be aware of: it stops at the first NUL byte, so you need to use some sort of binary-to-text encoding on top of the hash to ensure you don't have any of those in the data you ultimately hand off to bcrypt.

It's astounding how bad the default API for Bcrypt is.

Thank you

There is a discussion about that on the security stackexchange (https://security.stackexchange.com/questions/133239/what-is-...). The TLDR:

> SHA-2 family of hashes was designed to be fast. BCrypt was designed to be slow.

Slow == harder to brute-force == more secure.

Yes, and you can increase the work factor to make it slower to generate, specifically to fight against brute-force.

Password hash functions are designed to be slow, are designed to be use with salts, and may have low entropy inputs.

Hash functions themselves are general purpose and don't protect against low entropy inputs (low entropy passwords). They also don't protect against rainbow tables (pre-calculated digests for common or popular passwords). For password hashing you want something slow and something with unique entropy for each user's password to prevent rainbow attacks.

It doesn't solve the problem of weak passwords, but it's the best that can be done with weak passwords. The only improvement is to enforce strong passwords.