What's the reason behind bcrypt(userId + username + password) rather than just bcrypt(password) ?
What if two different users have the same password?
Why would that matter though?
Okta Bcrypt incident lessons for designing better APIs
121–130 of 169 posts
Re: Okta Bcrypt incident lessons for designing better APIs
#122Earlier quoted context omitted.
Bcrypt is salted[1], so that shouldn't matter? [1]: https://en.wikipedia.org/wiki/Bcrypt#Description
Are you sure? bcrypt stores the salt and retrieves it for comparison - otherwise you wouldn't be able to generate a matching hash. Consider the case where a user has a very long username and sets their password to their userId + username + password thus recreating the scenario which lead to the incident.
That was not my point. My point was there wouldn't be a hash collision just by two users with the same password due to the salting.
Re: Okta Bcrypt incident lessons for designing better APIs
#123Can someone explain, in clear layman terms, what the difference is between a password hash and a KDF? I have went through this whole thread and tried to look around online but I still don't understand.
Password hash is designed for matching: take the salt, add it to the password, run it through the hash, compare it to the stored hash. The important properties are: - MUST be non-reversible, including against tricks like "rainbow tables" - should be somewhat expensive to discourage just trying all possible passwords against a (leaked) hash KDF is a key derivation function. The value will be used as a key in, say, AES…
I still have no idea now haha. Your answer and Fabbari's are total opposites. If I am understanding right, you are saying that Password Hash is how a password should be stored while a KDF is not meant for storing passwords.
Fabbari is saying the opposite of this, that KDF should be used for storing passwords while password hashes should not.
Re: Okta Bcrypt incident lessons for designing better APIs
#124Earlier quoted context omitted.
Are you sure? bcrypt stores the salt and retrieves it for comparison - otherwise you wouldn't be able to generate a matching hash. Consider the case where a user has a very long username and sets their password to their userId + username + password thus recreating the scenario which lead to the incident.
That was not my point. My point was there wouldn't be a hash collision just by two users with the same password due to the salting.
There's no hash collision here, just two different hashes, each with its own salt, matching the same original phrase.
If you use only the password to generate the cache key, then this password will match regardless of salt, so users with the same password will generate a cache key matching that password.
Re: Okta Bcrypt incident lessons for designing better APIs
#125Earlier quoted context omitted.
Password hash is designed for matching: take the salt, add it to the password, run it through the hash, compare it to the stored hash. The important properties are: - MUST be non-reversible, including against tricks like "rainbow tables" - should be somewhat expensive to discourage just trying all possible passwords against a (leaked) hash KDF is a key derivation function. The value will be used as a key in, say, AES…
I still have no idea now haha. Your answer and Fabbari's are total opposites. If I am understanding right, you are saying that Password Hash is how a password should be stored while a KDF is not meant for storing passwords. Fabbari is saying the opposite of this, that KDF should be used for storing passwords while password hashes should not.
Further discussion upthread under https://news.ycombinator.com/item?id=42957300
Re: Okta Bcrypt incident lessons for designing better APIs
#126> was used to generate the cache key where we hash a combined string of userId + username + password. Don't conceive your own cryptographic hacks. Use existing KDF designed by professionals.
I would bet that if you surveyed working programmers 9 out of 10 would say that they thought bcrypt() was a “KDF designed by professionals”. The treacherous API is not as well known as it should be.
Re: Okta Bcrypt incident lessons for designing better APIs
#127Earlier quoted context omitted.
Internal state length may be a bit of a red herring (note that SHA-3 makes up for that longer internal state by ingesting more data per round), but SHA-3 probably has a higher security margin than the SHA-2 construction mostly because we have had sponge constructions for less time than we have had Merkle-Damgard constructions. NIST basically forced a higher security margin on SHA-3. You are correct about the length e…
Ew. Just HMAC. Don't use truncated SHA2.
Why?
Re: Okta Bcrypt incident lessons for designing better APIs
#128I enjoyed the article and the detailed analysis for different languages. The conclusion is probably the part where most of the disagreement lies. API design is is not really at fault here if we consider the purpose of the API and the intended output. The API was designed to generate a hash for a password (knowledge factor) and for performance and practical reasons a limit has been picked up (72). The chances that som…
Ohhh, it's scrollable... I wondered why this small article gained so much attention...
Re: Okta Bcrypt incident lessons for designing better APIs
#129Earlier quoted context omitted.
That was not my point. My point was there wouldn't be a hash collision just by two users with the same password due to the salting.
There's no hash collision here, just two different hashes, each with its own salt, matching the same original phrase. If you use only the password to generate the cache key, then this password will match regardless of salt, so users with the same password will generate a cache key matching that password.
Yes, that's what I pointed out when you suggested there would be a problem with two different users having the same password.
Re: Okta Bcrypt incident lessons for designing better APIs
#130Earlier quoted context omitted.
There's no hash collision here, just two different hashes, each with its own salt, matching the same original phrase. If you use only the password to generate the cache key, then this password will match regardless of salt, so users with the same password will generate a cache key matching that password.
Yes, that's what I pointed out when you suggested there would be a problem with two different users having the same password.
I'm getting the feeling that there's some kind of miscommunication here.
If only the password is used to generate the hash then that password, when used to match against a previously stored hash(cache key here), will also match it, thus producing the exact same vulnerability, but worse because it's enough to have the same password as someone else.
Salting does not help here at all.