• A routine update in July introduced an odd vulnerability for Okta.
• The company says that under a specific set of circumstances, a user with a 52-character username could log in without a password.
• The vulnerability was fixed on 30th October.

Last week access management company Okta whose clients include HP Enterprise, Zoom, jetBlue and others, reported it had fixed one of the more bizarre issues we’ve heard of.

On 30th October the company identified a bug which would appear under a very specific set of circumstances in Okta AD/LDAP DelAuth. If those criteria were met, a user wouldn’t need to input a password in order to be authenticated.

The criteria that needed to be met was:

• Okta AD/LDAP delegated authentication is used
• MFA [multi-factor authentication] is not applied
• The username is 52 characters or longer
• The user previously authenticated creating a cache of the authentication
• The cache was used first, which can occur if the AD/LDAP agent was down or cannot be reached, for example, due to high network traffic

The headline that has been grabbing attention is that if a user’s username was 52 characters long attackers could log into their account without a password. As we see above however, there was more to it than simply keying in a long user name. Granted, the fact that logging in would be as easy as inputting a username if the above criteria was met sure is terrible.

However, the fact that if that criteria was met a user could bypass the need for a password is nonetheless concerning and so the vulnerability has now been addressed. Okta says that the vulnerability was introduced as part of a standard release in July.

“Customers meeting the pre-conditions should investigate their Okta System Log for unexpected authentications from usernames greater than 52 characters between the period of July 23rd, 2024 to October 30th, 2024,” the company wrote.

“On October 30, 2024, a vulnerability was internally identified in generating the cache key for AD/LDAP DelAuth. The Bcrypt algorithm was used to generate the cache key where we hash a combined string of userId + username + password, Okta explained.

The company says that it has switched from a Bcrypt cryptographic algorithm to PBKDF2 to correct the issue.

With a lack of MFA listed as one of the criteria of this vulnerability, the company has urged its customers to implement MFA at a minimum.

“We also strongly encourage customers to enroll users in phishing resistant authenticators (such as Okta Verify FastPass, FIDO2 WebAuthn, or PIV/CAC Smart Cards) and to enforce phishing resistance for access to all applications,” Okta added.