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).
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.
Read Also
When Cache Keys Outlast Authentication Keys: A Glimpse into Okta’s Latest “Oops”
Okta Warns Customers of Credential Stuffing Attacks