The Lapsus$ Breach at Okta and Why Single Sign On Needs an Identity Layer
When news of the Lapsus$ breach at Okta surfaced a few days ago it initially seemed of little consequence. The explanation that a 3rd party contractor with limited access had been compromised seemed small and contained. But, murky and slow to emerge details including that around 375 customers may have been affected raised concerns and spawned an all-too-predictable backlash for the company as customers rushed with little guidance to implement their own security countermeasures.
Clearly, more could have been done in the way of effective corporate communications, but how surprised should we really be that SSO is vulnerable to this sort of breach? As security professionals, we all know that SSO still uses passwords. Depending on how you view the world, we understand that either passwords or the humans that use them are the weakest link in security. We provide workers access via those same systems to critical infrastructure, and we embrace the balance between risk and convenience as acceptable with a sort of “good enough” attitude. And, when the weak link breaks, some of us freak out, and some of those that do with good reason.
Surprise! Single Sign On Still Uses Passwords
This should really come as no surprise. Passwords have always been a balance of risk and convenience. At Internet scale, passwords become inconvenient and unworkable as the abundance of in-person services move online and the people requesting those services operate remotely, no longer from fixed or even predictable locations. SSO clearly solves part of the convenience challenge.
But passwords are not an Identity. We can go further in that the Identity in “Identity and Access Management (IAM) is largely a misnomer, because what all-too-often passes as an Identity Provider is in actuality a user store – in actuality, a list of users and their shared secrets … a repository for passwords used for knowledge based authentication.
Okta and other SSO systems like it solve the convenience challenge and obfuscate the password. But passwords and one time codes are still there and still vulnerable. The weak link is baked into the infrastructure, and in this sort of breach Lapsus$ found and broke it.
Single Sign On Requires an Identity Layer
This is why SSO needs a true identity layer, but here we wade into another murky cesspool of passwordless technologies. Let’s say we remove the password, and replace it with a biometric. Problem solved?
We may be a step further in removing passwords, but a biometric without verified identity is really another step along the “good enough” mindset. Clearly a device-level biometric comes with numerous limitations. We have multiple applications on the device. Can access be tailored for the numerous applications accessible from that device? Is the biometric stored in a safe location so that it cannot be stolen and used in place of the legitimate user? Does the biometric even belong to the authorized user? After all, most devices allow multiple user biometrics. Can the biometric be spoofed or fooled. Is the biometric free from decisioning bias (AKA racial bias)?
Solving Passwordless Access for Both Convenience and Security
The point here is that by replacing the weakest link in security with the next weakest link, which in this case is an unverified biometric, we’ve again solved the convenience challenge and placed security at a distant second. Why? Because when a biometric replaces the password and stands in place of the individual, we still face a fundamental security issue that the biometric alone can’t resolve. Is this the legitimate and intended user behind the login? Without verified identity, we simply can’t be sure.
This is why 1Kosmos has always advocated for the convergence of identity with authentication. It’s why we’ve made verification of the identity behind a biometric a convenient, self-service process that can be implemented anywhere, any time. It’s why our solutions provide for flexible levels of identity assurance tailorable to evolving business requirements so every access request can be verified with passwordless multifactor authentication. It’s why we use an identity verification engine that is over 99% accurate and free from human and racial bias. And it’s why from the start we’ve developed “privacy by design” solutions that put users in complete control of their identity, helping organizations comply with the over 230 privacy regulations globally.
For security professionals and business leaders alike, the question worth asking is “For which business systems is this good-enough approach to authentication acceptable?” But, the time to ask this question is before a breach such as we just saw in Lapsus$ … not after the fact and then call out the SSO vendor. Again, this is not to argue on the side of a lack of transparency, but to recognize the convenience vs. security trade off we all accept when we implement authentication without verified identity.
Are you interested in keeping the convenience of Okta while eliminating identity compromises and data breaches? I invite you to attend our upcoming webinar.
