21–30 of 78 posts
I'm really sick of companies disclosing this shit late Friday afternoon. Go fuck yourselves. Sincerely, Everyone in the industry
Earlier quoted context omitted.
I mean yes overall, but why would put delimeters into hash? you just smash bytes together.
Username: x@example.xyz Password: .com/!@#$% Concatenated: x@example.xyz.com/!@#$% Username: x@example.xyz.com Password: /!@#$% Concatenated: x@example.xyz.com/!@#$%
Earlier quoted context omitted.
I mean yes overall, but why would put delimeters into hash? you just smash bytes together.
Username: x@example.xyz Password: .com/!@#$% Concatenated: x@example.xyz.com/!@#$% Username: x@example.xyz.com Password: /!@#$% Concatenated: x@example.xyz.com/!@#$%
This is written in C, right?
> https://man.openbsd.org/crypt > So if the userid is 18 digits, the username is 52 characters, and the delimiters are 1 character each, then the total length of the non-secret prefix is 72, and bcrypt will drop the secret suffix. You aren’t supposed to put more than the salt and the password into trad unix password hashes.
why would someone in 2024 reach for bcrypt for building a secure hash key?
> https://man.openbsd.org/crypt > So if the userid is 18 digits, the username is 52 characters, and the delimiters are 1 character each, then the total length of the non-secret prefix is 72, and bcrypt will drop the secret suffix. You aren’t supposed to put more than the salt and the password into trad unix password hashes.
Core issue (okta's approach):
* They concatenated userId + username + password for a cache key
* Used BCrypt (which has a 72-byte limit)
* The concatenation could exceed 72 bytes, causing the password portion to be truncated
* BCrypt is designed for password hashing, not cache key generation
* Mixing identifiers (userId, username) with secrets (password) in the same hash
* Truncation risk due to BCrypt's limits
This is written in C, right?
Earlier quoted context omitted.
Username: x@example.xyz Password: .com/!@#$% Concatenated: x@example.xyz.com/!@#$% Username: x@example.xyz.com Password: /!@#$% Concatenated: x@example.xyz.com/!@#$%
A delimiter fixes the problem if you're sure the delimiter character can never be inside the username and password. Better would be to prefix the length of each field. Better still would be separately hashing each field and concatenating the results.
Earlier quoted context omitted.
If the cache gets leaked, you don’t want any miscreants to be able to bruteforce passwords from the cache keys.
Do we need to put the password in the cache key?
Concise write up; not surprising that cache played a part. Can't tell if it's issue with BCrypt or with the state-data going into the key, or combo-cache lookup tho.