Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Okta – Username Above 52 Characters Security Advisory

trust.okta.com

Post reply on HN
Print view View original

11–20 of 78 posts

Re: Okta – Username Above 52 Characters Security Advisory

#11

Post by fanf2 »

marginalia_nu wrote: post #6
fanf2 wrote: post #5

> 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.

The salt is a separate input to the algorithm that is used differently and usually more restricted than the password.

Re: Okta – Username Above 52 Characters Security Advisory

#12

Post by fanf2 »

ronsor wrote: post #10
magicalhippo wrote: post #9

Earlier quoted context omitted.

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?

If the cache gets leaked, you don’t want any miscreants to be able to bruteforce passwords from the cache keys.

Re: Okta – Username Above 52 Characters Security Advisory

#13

Post by jrockway »

0x457 wrote: post #7
fanf2 wrote: post #5

> 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.

Username: x@example.xyz Password: .com/!@#$% Concatenated: x@example.xyz.com/!@#$%

Username: x@example.xyz.com Password: /!@#$% Concatenated: x@example.xyz.com/!@#$%

Re: Okta – Username Above 52 Characters Security Advisory

#14

Post by ronsor »

fanf2 wrote: post #12
ronsor wrote: post #10

Earlier quoted context omitted.

Why do we need a KDF for a cache key? Won't a normal cryptographic hash function (or its HMAC variant) suffice?

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?

Re: Okta – Username Above 52 Characters Security Advisory

#15

Post by njtransit »

fanf2 wrote: post #11
marginalia_nu wrote: post #6

Earlier quoted context omitted.

> 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.

The salt is a separate input to the algorithm that is used differently and usually more restricted than the password.

The goal of a salt is to prevent lookup attacks. Since the user id is unique to each user, it prevents the use of pre-computed lookup tables like a salt would.

Re: Okta – Username Above 52 Characters Security Advisory

#17

Post by slama »

pluc wrote: post #4
Forbo wrote: post #3

I'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. [1] https://trust.okta.com/

It is listed on their security advisories page, which you can navigate to from that link:

https://trust.okta.com/security-advisories/

Re: Okta – Username Above 52 Characters Security Advisory

#18

Post by magicalhippo »

ronsor wrote: post #14
fanf2 wrote: post #12

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?

If the user changes password it invalidates the cache entries automatically, so you avoid stale credentials exploiting the cache

At least that's my immediate thought, could be wrong.

Re: Okta – Username Above 52 Characters Security Advisory

#19

Post by marginalia_nu »

fanf2 wrote: post #11
marginalia_nu wrote: post #6

Earlier quoted context omitted.

> 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.

The salt is a separate input to the algorithm that is used differently and usually more restricted than the password.

That's fair.

Though you can salt a hash using a function that does not take a distinct salt input by just concatenating the salt with the value. This is a relatively common practice, but of course only works if there is no truncation of the salted input.

Re: Okta – Username Above 52 Characters Security Advisory

#20

Post by a-dub »

fanf2 wrote: post #5

> 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?
Post reply on HN