Okta Breach Part 2: Unveiling the Full Scope and Impact


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.


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.


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.