Category: Okta

Google Salesforce Breach: ShinyHunters, OAuth Token Compromise, and Data Theft via Drift

Posted on by Srishti Chaubey

Last month, Google issued an advisory, a little bit for your well-being, more for saving their own… face. They declared that their Salesforce instances got breached by a threat actor by the name of UNC6040, who is also known by the alias ShinyHunters.  Contact details of small and medium businesses were stolen, though Google insists no passwords were taken.

A few days later, the scope widened. Google warned that OAuth tokens tied to the Drift platform were also compromised, including the Drift Email integration. OAuth tokens allow apps to connect without passwords, so if stolen, attackers can access connected services until revoked.

In response, Google revoked all OAuth tokens granted to Drift Email and disabled the integration between Google Workspace and Salesloft Drift pending further investigation.

Credit: Google

Attack Technique

The breach wasn’t just a simple data grab. Attackers used:

  • A fake Okta Phishing Panel to steal credentials.
  • Vishing (voice phishing) calls to trick users into giving MFA codes.
  • Salesforce Data Loader abuse– Once authenticated, they linked actor-controlled apps through Salesforce’s “Connected Apps” functionality. Victims were told to enter a “connection code,” giving attackers full access to extract large volumes of data.

What’s Next for Victims

According to Google, ShinyHunters is likely to:

  • Demand ransom payments in Bitcoin.
  • Launch a data leak site (DLS) to pressure victims into compliance.

Links to Other Groups

ShinyHunters is no stranger to large-scale breaches. Past victims include PowerSchool, Oracle Cloud, the Snowflake data-theft campaign, AT&T, NitroPDF, Wattpad, and MathWay.

We are also noticing a partnership between Shinyhunters and Scattered Spider in recent years. Additionally, a new alias, Sp1d3rHunters, has been surfacing.

We have to start wondering whether this new partnership will also play a role in the doomsday for Google users in the coming days. Additionally, Google has discovered links to the infamous “The Com” group.

Whether these alliances will escalate into broader attacks against Google’s user base remains to be seen, but defenders should be prepared.

Recommendation

Google also issued a Mitigation list:

  • Adhere to the Principle of Least Privilege, Especially for Data Access Tools
  • Manage Access to Connected Applications Rigorously
  • Enforce IP-Based Access Restrictions
  • Leverage Advanced Security Monitoring and Policy Enforcement
  • Revoke and Rotate Credentials
  • Harden Access Controls
  • Investigate for Compromise and Scan for Exposed Secrets

Speaking of being prepared, I’d recommend getting PureAUTH and avoiding the whole phishing, vishing, social engineering fiasco altogether, but you do you. Keep entering those passwords and MFA, only to get scammed and phished. Your choice 🙂

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

Posted on by Srishti Chaubey

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

Okta Password Bypass – Cryptography Done by Non-experts

Posted on by Ajit Hatti

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.

Read Also

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

Okta Warns Customers of Credential Stuffing Attacks

Unpacking Okta’s Recent Security Breach

Okta Breach Part 2: Unveiling the Full Scope and Impact

© 2025 | PureID. All Rights Reserved

Privacy & Terms | Licenses