Okta – Username Above 52 Characters Security Advisory
trust.okta.com
Okta – Username Above 52 Characters Security Advisory
1–10 of 78 posts
Re: Okta – Username Above 52 Characters Security Advisory
#2Concise 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.
Re: Okta – Username Above 52 Characters Security Advisory
#3I'm really sick of companies disclosing this shit late Friday afternoon.
Go fuck yourselves.
Sincerely, Everyone in the industry
Re: Okta – Username Above 52 Characters Security Advisory
#4I'm really sick of companies disclosing this shit late Friday afternoon. Go fuck yourselves. Sincerely, Everyone in the industry
It's the second time they do that in a few weeks too, _and_ it's not on their security page [1] which promises transparency.
Re: Okta – Username Above 52 Characters Security Advisory
#5>
>
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.
Re: Okta – Username Above 52 Characters Security Advisory
#6> 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.
> You aren’t supposed to put more than the salt and the password into trad unix password hashes.
To be fair, they're basically salting with the userid and username. Still unorthodox to be sure.
Re: Okta – Username Above 52 Characters Security Advisory
#7> 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.
I mean yes overall, but why would put delimeters into hash? you just smash bytes together.
Re: Okta – Username Above 52 Characters Security Advisory
#8I'm really sick of companies disclosing this shit late Friday afternoon. Go fuck yourselves. Sincerely, Everyone in the industry
Thank you for your feedback. Next time, we'll disclose it on Saturday evening.
-- With Love, Okta.
Re: Okta – Username Above 52 Characters Security Advisory
#9> 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.
Potentially ignorant question, why would they go for bcrypt over say HKDF[1], especially since they mix in public data like the username and potentially userid?
Re: Okta – Username Above 52 Characters Security Advisory
#10> 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.
Potentially ignorant question, why would they go for bcrypt over say HKDF[1], especially since they mix in public data like the username and potentially userid? [1]: https://datatracker.ietf.org/doc/html/rfc5869
Why do we need a KDF for a cache key? Won't a normal cryptographic hash function (or its HMAC variant) suffice?