When Cache Keys Outlast Authentication Keys: A Glimpse into Okta’s Latest “Oops”

PureID

Srishti Chaubey

November 7, 2024

When Cache Keys Outlast Auth Keys : Okta's latest oops!!

In the security world, where precision is everything, Okta recently provided us with an example of how a single overlooked detail can shake up the user experience, especially if that “user” is a bad actor.

On October 30, 2024, Okta admitted to a vulnerability with a very unassuming title in its AD/LDAP Delegated Authentication (DelAuth) mechanism, which was fine until a username got a little too long. The key was a clever blend of Bcrypt-hashed elements: user ID, username, and password. However, if a username was 52 characters or longer, and the right cached key from a prior login was available, voilà—no password needed. Just enter the username, and you're in.

Okta: 52 Character Username Fiasco
Credit - BornSec

Security at Okta: It’s All About the Details… Or Is It?

As you might guess, these conditions weren't common at all but still a little too close for comfort. To bypass the DelAuth system, the following criteria had to be met:

  • You were authenticating using Okta's AD/LDAP DelAuth.
  • MFA was not turned on.
  • Your username was at least 52 characters long.
  • Authentication was cached by an earlier successful login and the network was unable to make it back to the actual AD/LDAP agent in real time.

This "free authentication" period ran from July 23 to October 30, 2024—a good three months where lucky 52-character usernames could breeze past password checks.

While most usernames aren’t likely to exceed 52 characters, and many systems don’t even allow usernames that long, the fact that Okta overlooking this detail in their hashing process is... noteworthy. After all, how many times are we going to expect security software companies to forget some basic boundary conditions?

Okta’s Recommendations, and the Reality

Okta quickly patched the vulnerability by switching from BCrypt to PBKDF2 for cache key generation. They asked affected customers to review system logs for suspicious logins from July 23 to October 30. That too under the assumption that customers knew about the 52-character username limit in the first place.

Okta's advice is straightforward: enable MFA and use phishing-resistant authenticators—basic but effective security practices that still aren't defaults. Okta emphasizes that these basics help mitigate risks, advising security-focused customers to double-check. Nothing quite says "proactive security" like asking your customers to pick up the slack caused by a missed code line.

Conclusion

A good piece of irony on top of a 52-character vulnerability from Okta is the use of passwords and BCrypt. BCrypt eats rainbow tables like cake but Its length limit problem is well known. Leaving cached keys in the middle with passwords so apparently involved in the process isn't so much of that promised "passwordless," is it? We also wonder the number of users and accounts that slipped through the gaps in Okta’s cache key handling.

In contrast, PureAuth offers a true passwordless experience. Our zero-trust model eliminates passwords, meaning no PII or customer data are on our server. We have no passwords, no caching issues, just genuine security. PureID’s proactive security isn’t just a promise; it’s our foundation, sparing you from tomorrow’s vulnerability headlines and ensuring robust defenses without compromise. #gopasswordless

Read Also

Okta Password Bypass – Cryptography Done by Non-experts

Okta Warns Customers of Credential Stuffing Attacks

Unpacking Okta’s Recent Security Breach

Okta Breach Part 2: Unveiling the Full Scope and Impact

Share this article    

Connect with Us!

Subscribe to receive new blog post from PureID in your mail box