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

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

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

Cisco VPNs Suffer Brute Force Attacks : Here’s Your Shield!

Cisco recently issued a warning about large-scale brute-force attacks targeting VPN and SSH services on Cisco and other devices worldwide. These attacks pose significant risks to enterprise security, necessitating immediate action.

Hacker can login to VPN with stolen credentials

Cisco Warning and Compromised Services

Cisco Talos reports a surge in brute force attacks since March 18, 2024, targeting VPN services. These assaults exploit vulnerabilities in traditional password-based authentication, compromising network integrity. The known affected services are following:

  • Cisco Secure Firewall VPN 
  • Checkpoint VPN  
  • Fortinet VPN  
  • SonicWall VPN  
  • RD Web Services 
  • Miktrotik 
  • Draytek 
  • Ubiquiti 

History: Not so Private Virtual Private Networks

If you are here reading this blog, you know the drill. Maybe a password is slipped in code, spoofed, phished, whaled, 2FA or MFA is breached, or even a vendor is breached, and your organization and user information lies in the hands of a threat actor. According to an HBR Report “The FBI regards a cybersecurity breach at every organization—including yours—as a matter not of ‘if,’ or even ‘when,’ but ‘how often.'”

Most often then not, these threat actors will siege your assets, ask for ransom and cause a lot of trouble. Two out of Three organizations, without a regard of size, have faced ransomware in 2023. Beyond the cost of expenses, including, potentially, the ransom itself, downtime averages $365,000 an hour in revenue loss. When you consider that the average recovery time is three weeks, it becomes clear how devastating these attacks can be.

In our previous blog we have discussed VPN breaches in detail. Anyhow, here’s some compact data for you.

Affected EntityRoot CauseImpact
Avast AntivirusStolen credentialsAdversaries modified the CCleaner distributed by Avast .
Lockheed MartinCVE-2011-0609Critical data related to the defence contracts leaked.
Pulse SecureCVE-2019-115101000 enterprises are at risk of ransomware attacks.
Ukraine Power gridMalwarePower grid taken offline leading to no electricity for thousands.
List of the most serious VPN attacks due to stolen credentials

Brute Force Attacks

Brute force attacks involve systematically trying multiple username-password combinations until the correct one is found. Attackers leverage proxies like TOR, VPN Gate, IPIDEA Proxy etc to conceal their origins, intensifying the challenge of detection.Password spray attacks, on the other hand, target numerous accounts with commonly used passwords, increasing the likelihood of success.

Your Knight in Passwordless Armour – PureAuth

In light of escalating threats, enterprises must prioritise the adoption of passwordless VPN solutions. Embracing innovative authentication mechanisms ensures a resilient defence against evolving cyber threats.

Passwordless Authentication in popular VPN by PureAuth
VPNs you can make Passwordless

Transitioning to passwordless VPN systems offers a robust defence against brute force attacks. By eliminating passwords, these systems thwart credential stuffing attempts, enhancing overall security.

Conclusion

In the face of mounting VPN vulnerabilities, the imperative to transition to passwordless systems cannot be overstated. By embracing advanced authentication methods, organisations can fortify their defences against brute force attacks, safeguarding critical assets and data.

Read Also

Your 1st Step to #GoPasswordless

Credential stuffing Attacks on VPN: Serious Risk for Enterprise

Cloudflare Breach: Okta’s Ripple Effect

Abstract

In a recent revelation, Cloudflare disclosed a security breach on Thanksgiving Day, November 23, 2023. This blog delves into the timeline of events and emphasises the critical role of passwordless authentication in mitigating such breaches.

Breach Overview: Understanding the Thanksgiving Intrusion

In an orchestrated attack, threat actors exploited stolen credentials from the Okta security breach in October. Cloudflare’s internal systems, particularly the Atlassian server, became the focal point for unauthorised access and data compromise.

Compromised Credentials: The Fallout on Cloudflare’s Security

Despite the awareness of the Okta breach, Cloudflare’s failure to rotate service tokens that have very long validity and account credentials allowed threat actors to establish persistent access. This breach impacted Cloudflare’s Atlassian environment, leading to unauthorised access to sensitive documentation and a limited set of source code repositories.

Nation-State Attribution and the Real Culprit: Passwords

Cloudflare attributes the breach to a likely nation-state actor, mirroring the recent trend in cyber threats. However, one can suggest that the fundamental issue lies in the continued reliance on a vulnerable authentication method, which enables such breaches to unfold.

Highlighting the Key Issue: The Perils of Passwords

The breach underscores the inherent vulnerability of conventional password systems. Stolen Okta credentials served as the gateway for threat actors, exposing the limitations of password-centric security measures. This incident highlights the urgent need for organisations to transition towards passwordless authentication solutions & short session validity to fortify their security posture.

It’s the painful experience of passwords based login which forces admins and users to choose long term session tokens to minimise the number of logins.

PureID Solution: A Glimpse into a Secure Future

PureID offers a robust passwordless authentication solution that would have mitigated this breach. By eliminating the relevance of stolen credentials, PureID represents a paradigm shift in cybersecurity, providing a secure alternative to traditional password systems.

PureAUTH offers a simple & smooth login experience. This makes working with short term sessions and frequent login delightful.

Risk Mitigation: The Imperative of Passwordless Security

Cloudflare’s breach serves as a wake-up call for organizations to reevaluate their cybersecurity strategies. Embracing passwordless solutions, such as PureID, emerges as a proactive step to mitigate the risks associated with stolen credentials and enhance overall security.

Immediate Response: Cloudflare’s Security Reinforcement

In response to the breach, Cloudflare has initiated a comprehensive security reinforcement effort. Measures include mass credential rotation, system segmentation, forensic triage, and a meticulous review of all systems to ensure the threat actor’s access is fully revoked.

Ongoing Investigation: Collaboration for a Secure Future

Cloudflare’s ongoing collaboration with peers, law enforcement, and regulators emphasises dedication to assessing the breach’s full impact. This collaborative approach aims to implement additional preventive measures and adapt to the evolving landscape of cyber threats.

Conclusion: Advocating for Passwordless Security

The Cloudflare breach underscores the critical need to shift from traditional passwords and false passwordless systems to true passwordless authentication that can not be breached by stolen credentials. Passwordless solutions, like PureID, offer a robust defence against unauthorised access, heralding a more secure digital future for organisations.

Read Also:

Mother of all breaches: Which you could have avoided !!

Introduction

Don’t use passwords they said. It can be breached they said. Well, surprise, surprise, we didn’t pay much attention. Now, here we are, nervously checking our email IDs against the colossal 26 billion-record breach – the mother of all breaches!

Breach Unveiled: A Symphony of Chaos

So, there’s this massive breach, Mother of All Breaches (MOAB), a digital pandemonium that has exposed a whopping 26 billion records. It’s like a digital opera – records from MySpace to Adobe, starring Tencent, Weibo, Twitter, and LinkedIn. Your data just had its grand debut!

The Dramatic Unfolding

Picture this: MOAB is a blockbuster compilation of data breaches, meticulously curated. It’s like a Hollywood blockbuster, but your credentials are the star, and not in a good way. Your once-secure passwords are now part of a hacker’s treasure trove. Slow clap for the password drama.

Passwords – The Ultimate Blunder

If  Ellen DeGeneres hosted this show, she’d say, “You had one job – say no to passwords!” See the aftermath? Identity theft, phishing attacks, and a surge in password-stuffing shenanigans. All thanks to those outdated, reused, and easy-to-crack passwords.

Passwordless Paradise: Where Dreams Come True

Now, imagine an alternate universe where you actually listened – where passwordless authentication is the superhero. No MOAB nightmares, just smooth, secure logins without the hassle of juggling countless passwords. A utopia, right?

Mitigation Party: Reclaim Your Digital Kingdom

Inspect Your Vulnerability: Employ tools such as “Have I Been Pwned” and data leak checker. data leak checker. Use “Privacy Hawk” to trace your data’s path and request removal from unwanted websites. Move swiftly: Purge your digital footprint by eliminating your data from irrelevant websites.

Conclusion: Lessons Learned (Hopefully)

In an ideal world, you’d have embraced passwordless authentication, and we’d all be sipping digital margaritas by now. But, alas, here we are – dealing with the aftermath. Take this as a digital wake-up call: passwords belong to the past, let’s march into a passwordless future.

A Final Plea: Break Free from Passwords

Passwords are so yesterday!! The revolution is calling – will you answer? Join the passwordless parade; your digital sanity will thank you later. Use PureId, Stay Safe.

Okta Breach Part 2: Unveiling the Full Scope and Impact

Introduction

In late October, Okta, reported a cybersecurity breach that initially appeared to affect less than 1% of its customers. However, recent revelations indicate a far-reaching impact, affecting 99.6% of users in the customer support system. This blog post delves into the broader implications of this

The True Scope Revealed

Contrary to initial estimates downplaying, it has now been disclosed that hackers successfully ran a report on September 28, 2023. It contained sensitive information about all Okta customer support system users. The compromised data had names, email addresses, company names, contact phone numbers, and other details, Impacting 100% of Okta Workforce Identity Cloud (WIC) and Customer Identity Solution (CIS) customers. The only exception being those in highly sensitive environments such as the government.

Financial Impact on Okta

Despite the significant dip in Okta’s stock prices when the breach was first reported in October, resulting in a temporary loss of approximately $2 billion in market capitalisation, the financial fallout seems to be hovering in the single digits. Okta’s latest quarterly financial report indicates a more than 20% increase in revenues for the quarter ending October 31, demonstrating a robust financial performance despite the security incident.

Customer Trust at Stake

The discrepancy between the initially reported 1% impact and the actual 99.6% of affected users reveals a concerning lapse in transparency. Okta customers are now grappling with the realization that threat actors may have access to their names and email addresses, exposing them to the risk of phishing and social engineering attacks. While Okta assures that there is no direct evidence of exploitation, they urge customers to remain vigilant. This stolen information could be weaponized for targeted cyber scams.

Phishing and Social Engineering Threat

With 99.6% of users having their names and email addresses exposed. These stolen data poses a heightened risk of phishing and social engineering attacks.

Okta Phishing

Cyber security experts emphasise the need for Okta customers, especially administrators, to enforce multi-factor authentication (MFA) and consider the use of phishing-resistant authentication. The potential for threat actors to exploit this information for targeted attacks underscores the importance of proactive security measures on the customer’s end.

Conclusion

In the aftermath of the Okta breach, customer trust in identity management systems faces a critical test. As emphasised by the mantra “The ‘S’ in IAM stands for Security”, the true scale of the incident challenges the reliance on auto-saved passwords, demonstrating the vulnerability of conventional systems. We urgently advocate for the adoption of passwordless authentication. For those catching up, our previous post details the Okta breach, highlighting the imperative to #gopasswordless . This approach not only addresses current vulnerabilities but also aligns with the evolving demands of a secure digital landscape.

GitHub says #GoPasswordless

All the recent high profile breaches we have seen, have one common root cause – Account takeovers with compromised credentials.

Solarwinds incidents is a biggest examples of how simple account takeovers lead to distribution of malicious updates, which then got amplified through the supply chain and affect the entire world.

GitHub being the world’s code-repository and home for all updates, have taken a commendable step to curb account takeover attacks by going passwordless. 

Beginning August 13, 2021, GitHub will no longer accept account passwords when authenticating Git operations on GitHub.com.

As informed previously by Ben Balter, Program Manager at GitHub in July 2020, GitHub wants its users to use alternative forms of authentication which involves tokens, keys, device identification etc.

GitHub to #GoPasswordless

GitHub has also assured the customers already using 2FA or MFA with their existing passwords will remain unaffected. 

GitHub also acknowledges that many forms of 2FA that use SMS based OTP are weaker and bypassable, hence recommends stronger MFA solution to protect your GitHub accounts 

As far as Enterprises are concerned, GitHub supports SAML based authentication which is leveraged by PureAUTH to provide passwordless authentication. 

To further secure your code management platform you can integrate CICD automation suites like Jenkin and code scanning tools like Sonarqube with PureAUTH and #GoPasswordless. 

O #slack! We found your stored PASSWORDS…

Slack introduced a bug on 21st December 2020 that caused their android app to store user passwords in plain text on their local storage.

Slack communicated users to change their Slack passwords as well as to clear the Slack app data on android devices. The affected users’ passwords have been invalidated and they will be asked to set new passwords the next time they try to login.

Details shared by Slack

The problem occurred due to a bug introduced between December 21st and January 21st. Slack informed the Verge that the issue has now been resolved.

In their Email to the affected users, they have a few instructions for users to secure themselves:

  • If you are an Android user then you need to change your password urgently
  • Your password might be saved in your local storage in a plain text format.
  • Clear the app data for Slack from the android device.

The problem with storing your passwords in plain text on the local storage is, other apps on the phone can potentially read those passwords directly. A malicious app on the phone can exfiltrate passwords which can be used to login to the affected app or other apps on which the user has re-used the password.

If you have used your slack credentials on any other platform, reset them immediately. If you have saved your slack password with Google, you can check it with Chrome’s Built in password check-up tool. Slack has also mentioned that users authenticating with SSO or Social Logins may not have affected by the bug.

The Password Problem

Its a basic practice or Information Security 101 to securely (SALT & HASH) store passwords. This is not the first time when a reputed global company is seen not adhering to this basic practice. Right from Facebook, Twitter, Social Captain (Instagram 3rd party service) has history of storing passwords in plain text. In 2019 Robinhood made headlines for storing passwords in plain text in their internal systems.

Simple Solution

Go Passwordless!!! Adopting passwordless authentication eliminates the risk of password exposure due to insecure storage. An enterprise can also protect its users from password leaks and other phishing attacks without the need of additional 2FA/MFA or password managers.

Going passwordless drastically reduces enterprises attack surface, risk exposure and cost of authentication. 

Connect with us to know how our PureAUTH platform integrates with Slack as well as other SAML enabled applications and makes an enterprise more secure and resilient.

Making AWS Console Passwordless

In this blog, we are going to discuss one of the many (and we mean MANY) use cases of our passwordless authentication platform – PureAuth. 

We are working with a number of organisations that use AWS services. For contingency and serviceability reasons, the organisations share the access to AWS console with multiple admins. However, this is posing a big governance and compliance issue along with the conventional risks of shared accounts.

Problems with Shared accounts

Problems with Shared accounts

Shared accounts have been a widely accepted practice to assure serviceability. This convenience comes with a compromise on security and compliance.

In this writeup – The use and administration of shared accounts, SANS highlights the problem of managing passwords for shared accounts.

TL;DR Proper coordination is needed to change passwords periodically or on adhoc basis and every time an admin is moving in or out.

Sharing a secret with multiple people increases the risk of (accidental) leakage of the information and conventional approach to secure password with additional factor (MFA/2FA or OTP) fails for a shared account.

PureAUTH Solution

A simple SAML 2.0 integration of PureAUTH with AWS Console makes shared access passwordless and secure. PureAUTH helps  govern shared accounts better by maintaining strict mapping and accountability of each authentication instance. Our robust user on-boarding process allows an enterprise fine grain control to audit, manage and revoke access of their users as needed.

SAML Integration with PureAuth (behind the scene)

PureAUTH provides Proof-of-Association based authentication to any application over simple SAML 2.0 integration.  We use the same interface to make AWS console login passwordless.

Our Patented Proof-of-Association based authentication assures better accountability and attribution even for shared accounts.

SAML Integration with PureAuth
SAML Integration of AWS Console with PureAUTH

Authorization & Roles restriction 

AWS lets’ users choose their role at the time of login. PureAUTH also provides an optional facility to preselect the roles based on the entitlement of the user.

Passwordless Access

The video below demonstrates passwordless access to AWS Console with PureAUTH platform. Here you can see a user getting authenticated to AWS Console with his valid profile contained in VR5 app on his phone.

Conclusion

Going passwordless reduces risk and helps you to better comply & govern access to your crown jewels.

PureAUTH offers similar passwordless integrations for Google Cloud Platform, Azure, IBM Cloud and many more. Please get in touch with us for a free demo.