4 ms·
I am curious why bcrypt was used for hashing in the first place and not something like sha-512 Is there a reason I might be missing?
by coolgoose 2y ago
I am curious why bcrypt was used for hashing in the first place and not something like sha-512
Is there a reason I might be missing?
- stavros 2y agoYes, the hashed payload contained a password, so presumably they didn't want to just SHA it.
- coolgoose 2y agoBut why not bcrypt the password, but sha the cache key on top?
- stavros 2y agoI guess because they didn't anticipate this flaw.
- masklinn 2y agoAlso 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.
- Dylan16807 2y agoIt's astounding how bad the default API for Bcrypt is.
- coolgoose 2y agoThank you
- tptacek 2y agoBegs the question of why the payload contained a password, right?
- benmmurphy 2y agoThey 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.
- tveita 2y agoStoring 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
- n0rdy 2y agoThere is a discussion about that on the security stackexchange (https://security.stackexchange.com/questions/133239/what-is-the-specific-reason-to-prefer-bcrypt-or-pbkdf2-over-sha256-crypt-in-pass 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.
- progmetaldev 2y agoYes, and you can increase the work factor to make it slower to generate, specifically to fight against brute-force.
- Zamicol 2y agoPassword 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.