On Friday evening, Okta posted an odd update to its list of security advisories. The latest entry reveals that under specific circumstances, someone could’ve logged in by entering anything for a password, but only if the account’s username had over 52 characters.

According to the note people reported receiving, other requirements to exploit the vulnerability included Okta checking the cache from a previous successful login, and that an organization’s authentication policy didn’t add extra conditions like requiring multi-factor authentication (MFA).

Here are the details that are currently available:

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. During specific conditions, this could allow users to authenticate by only providing the username with the stored cache key of a previous successful authentication.

The vulnerability can be exploited if the agent is down and cannot be reached OR there is high traffic. This will result in the DelAuth hitting the cache first.

According to the note, the flaw has been present since an update on July 23rd until it was resolved by switching the cryptographic algorithm from Bcrypt to PBKDF2 after the vulnerability was internally identified. Okta didn’t immediately respond to a request for additional details but says customers whose setups meet the necessary conditions should check those three months of system logs.

Source link

On Friday evening, Okta posted an odd update to its list of security advisories. The latest entry reveals that under specific circumstances, someone could’ve logged in by entering anything for a password, but only if the account’s username had over 52 characters.

According to the note people reported receiving, other requirements to exploit the vulnerability included Okta checking the cache from a previous successful login, and that an organization’s authentication policy didn’t add extra conditions like requiring multi-factor authentication (MFA).

Here are the details that are currently available:

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. During specific conditions, this could allow users to authenticate by only providing the username with the stored cache key of a previous successful authentication.

The vulnerability can be exploited if the agent is down and cannot be reached OR there is high traffic. This will result in the DelAuth hitting the cache first.

According to the note, the flaw has been present since an update on July 23rd until it was resolved by switching the cryptographic algorithm from Bcrypt to PBKDF2 after the vulnerability was internally identified. Okta didn’t immediately respond to a request for additional details but says customers whose setups meet the necessary conditions should check those three months of system logs.

Source link