Long username? Okta says: no password needed!
authentik is an open source Identity Provider that unifies your identity needs into a single platform, replacing Okta and Auth0, Ping, and Entra ID. Authentik Security is a public benefit company building on top of the open source project.
Late last Friday, Okta released a security advisory: accounts with a username of 52 or more characters could authenticate with only the username under some conditions.
From their own description:
"The Bcrypt algorithm was used to generate the cache key where we hash a combined string of userId + username + password."
THIS IS CRAZY!
Bcrypt is a hashing algorithm. The way it is intended to be used is by concatenating a password with a random salt. Concatenating a user ID with a username with a password - this phrase alone should raise the hackles of any security professional - is definitely not a standard usage of Bcrypt.
At best, Bcrypt is a (now not-so-frequently chosen) password hashing algorithm, not a method for generating cache keys by throwing a bunch of user info into one big string. Passwords shouldn't go in cache keys. Public/guessable data like usernames shouldn't go in password hashes. This is more than a weird corner-case vulnerability; this is TERRIBLE security design.
Bcrypt has a maximum input length of 72 bytes. You can probably guess the rest of the issue from here: start with a user ID, then add a username, ...then a password, if there's room left. No room left? Guess we don't need to check if the password matches at all!
Yes, the chance of an organization implementing Okta and then having many accounts that are not protected by a second factor is somewhat unlikely. Hopefully. And yes, the practical likelihood of having very long usernames (52+ characters) is also fairly small.
The point is not in uncovering the exact likelihood of this specific vulnerability affecting specific customers. It's that Okta has shown, once again, that it does not prioritize security by design. Using and abusing Bcrypt to throw usernames and passwords into cache keys is madness, and we only get to know about this particular bad choice because it was disclosed after being identified as the cause of a now-patched vulnerability.
As Okta's CEO, Todd McKinnon, put it in last year's earnings call:
“Remember, Okta started as a -- it was -- our focus was enabling technology and making it easy to adopt the cloud. It wasn't necessarily started 15 years ago as a cyber company. Now, that changed a few years into the company, and it's very clear to us now that -- and has been for the last few years that the bar is the most secure company in the world, full stop. [...] It's kind of clear to everyone that we're short of where we need to be now, and we will fix that."
This is why, in November 2023, they had a quarter-long feature freeze after their last major breach, to focus entirely on security and training up employees. This was "Program Bedrock" that had them following a "hyper-focused security action plan."
Okta's been around since 2009, so maybe this weird Bcrypt issue was just the result of some legacy code that never got updated? Oh, wait:
2024-07-23 - Vulnerability introduced as part of a standard Okta release
This misuse of a password hashing function from 1999 was introduced just a few months ago, after promising that their "top priority" is "becoming one of the most secure companies in the world."
Frankly, I suggest they start over. You cannot build a secure company or a secure product on top of two proprietary codebases (both Okta and Auth0) that have already been breached and leaked on the dark web.
What initially attracted me to authentik as a solution in the identity provider space was its open source and source available nature; of course you want to be able to look under the hood of a product as critical to your security as an identity provider. Otherwise, who's to say how they are securing your sensitive data? It would be like choosing to use a cryptographic library that only attackers could examine, instead of one that the wider community has tested and can vouch for.
As it turns out, Okta can't even get that choice correct. We got to learn about this particular design flaw because it resulted in a vulnerability. Given their track record of breaches followed by lack of transparency (1, 2, 3, 4, ...), how many other fundamental flaws will simply never come to light? We wrote about exactly this a year ago.
If you're one of the thousands of organizations who have been stuck in an expensive, toxic relationship with Okta, get in touch. We make it easy and seamless to escape.