Okta – Username Above 52 Characters Security Advisory

[fanf2]

<< The Bcrypt algorithm was used to generate the cache key where we hash a combined string of userId + username + password. During specific conditions, this could allow users to authenticate by only providing the username with the stored cache key of a previous successful authentication. >>

https://man.openbsd.org/crypt

<< The maximum password length is 72. >>

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.

[gzer0]

Here's how I see it:

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

Why this is problematic:

  * 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

Password storage should be separate from cache key generation. Use a random salt + appropriate hash function and for cache keys - use HMAC or KDF w/appropriate inputs

[3np]

That should also mean that ca 50-52 character usernames are likely easily bruteforcable. Which makes the preconditions wider than those stated in the publication.

[magicalhippo]

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

[a-dub]

why would someone in 2024 reach for bcrypt for building a secure hash key?

[marginalia_nu]

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

[0x457]

I mean yes overall, but why would put delimeters into hash? you just smash bytes together.

[jadengis]

This is obviously a huge mistake by Okta (for the love of God understand how your crypto functions work before you apply them) but at the same time, a crypto function with a maximum input length that also auto-truncates the data sounds like bad API design. You are basically asking for someone to goof up and make a mistake. It's much better to implement these things defensively so that the caller doesn't inadvertently make a mistake. Especially with a hashing algorithm, because there is no way to verify that the result is correct.

[sebastialonso]

Agree with the spirit of the argument, but I disagree about the bad design. BCrypt has its trade-offs, you are expected to know how to use it when using it, specially if by choice.

It's like complaining about how dangerous an axe is because it's super sharp. You don't complain, you just don't grab the blade section, you grab it by the handle. And

[mplewis]

Passing something that isn’t a password + salt into bcrypt is the mistake here.

[djbusby]

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.

[ptcrash]

I think it's more of a logic problem. I suspect the engineers made a false assumption that bcrypt can hash a trivial amount of data like some other hashing algos.

[Forbo]

I'm really sick of companies disclosing this shit late Friday afternoon.

Go fuck yourselves.

Sincerely, Everyone in the industry

[pluc]

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/

[cyberax]

Thank you for your feedback. Next time, we'll disclose it on Saturday evening.

-- With Love, Okta.

[chanux]

Also, are there any repercussions for this kind of stuff? I don't know, fines from the organizations they get compliance certifications from or something.

[hoffs]

geee, nobody is targeting you

[err4nt]

They had literally 1 job: secure authentication. This isn't the first time Okta has had a gaffe on a level that should cause any customer to reconsider. What's that saying, "Fool me once, shame on thee, fool me twice, shame on me". Don't get fooled by Okta a second, third, or fourth time.

[_hyn3]

Why is anyone actually using Okta for anything these days?

IMO, better to choose point solutions and combine them.

[demarq]

Wasn’t there a project posted here that can spot this things automatically.

It’s was a fuzzer of some sort

[Animats]

This is written in C, right?

[tedunangst]

Your rewrite of bcrypt in not C is unlikely to support longer passwords.

[lanstin]

Probably Java. This is not a memory vulnerability but a protocol vulnerability.

[lelanthran]

> This is written in C, right?

What's your point? That rewriting `bcrypt` in something else magically fixes this?

AIUI, the issue is that `bcrypt` only uses the first 72 bytes of the input to create a hash.