Okta Archives - PureID

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

Okta Warns Customers of Credential Stuffing Attacks

Unpacking Okta’s Recent Security Breach

Okta Breach Part 2: Unveiling the Full Scope and Impact

Okta recently disclosed a vulnerability in its AD/LDAP Delegated Authentication system with critical severity. The vulnerability was attributed to the use of the BCrypt hashing algorithm for generating and verifying cache keys.

From previous breaches, it’s known that Okta stores user passwords in plain text for delegated authentication, which have been exposed on multiple occasions.

Best practice suggests storing a hash of a password instead of the password itself. However, this is insufficient given the vast number of hashed passwords available on various internet crackstations, allowing easy lookup (or rainbow tables).

okta-password-bypass-BCrypt — Credit – Forbes

It is further recommended to use a randomly generated salt as an additional parameter when hashing a password.

Developers are required to generate, use, and maintain the salt along with the hash for all future verification operations. While this approach significantly reduces the risk of leaking passwords, there remains a lower risk of exposing salted-hashed passwords, which are harder to crack.

However, standard cryptographic hashing algorithms like SHA1 and SHA256 are faster and are optimized for speed and computational efficiency. As a result, brute-forcing these hashes can become feasible if the salt is known.

With this possibility in mind, Okta developers chose the BCrypt() algorithm to generate what they call a “cache key.”

About BCrypt()

The BCrypt hashing scheme is an adaptive function: over time, the iteration count can be increased to make it slower, so it remains resistant to brute-force search attacks even with increasing computational power.

BCrypt takes only the first 72 characters as input. Anything over that is ignored. Out of 72 bytes, only 56-byte blocks are used by the Blowfish algorithm, and the first 4 bytes are reserved for denoting the version of the BCrypt algorithm. This effectively leaves 52 characters for the user’s input. Anything over that will be ignored.

How Okta Generates the ‘Cache Key’

Okta takes a bcrypt() hash of (userId + userName + passwd) values. If the userId + userName value exceeds 52 characters, the password field is automatically truncated, and the hash generated has no consideration for the passwords.

This also means that for a username longer than 52 characters, no matter what password is given, the hash value remains unchanged, resulting in a password bypass vulnerability.

Is BCrypt a Bad Choice?

BCrypt is a non-standard hashing algorithm, and the OpenSSL group has denied providing support for it. Since cryptographers are well aware of this fact, they will always recommend using standard cryptographic hash functions like SHA256() for key derivation or password storage.

A professional with decent knowledge of cryptography would have chosen something better than BCrypt().

Moving from Insecure to Insecure?

Okta’s recent move from BCrypt to PBKDF2 suggests that, when its initial choice proved insecure, they chose which they thought was insecure to begin with.This choice positions Okta as insecure both by design and by default, neither of which aligns with the security standards expected from Okta.

Conclusion

Regardless of which hashing algorithm Okta employs, it remains vulnerable as long as it relies on password-based security. For enhanced security and resilience, it’s time to #GoPasswordless with PureAUTH.

Okta Warns Customers of Credential Stuffing Attacks

Unpacking Okta’s Recent Security Breach

Okta Breach Part 2: Unveiling the Full Scope and Impact

Category: Okta

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

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

Okta’s Recommendations, and the Reality

Conclusion

Read Also

Okta Password Bypass – Cryptography Done by Non-experts

About BCrypt()

How Okta Generates the ‘Cache Key’

Is BCrypt a Bad Choice?

Moving from Insecure to Insecure?

Conclusion

Read Also