Okta Exposes Passwords in Clear Text for Possible Theft
darkreading.com
darkreading.com
The claim that Okta exposes plain text passwords is only true in an edge case: When an Okta administrator has set up password syncing to a downstream system.
For this to work, the person who sets this up has to be an administrator and they have to SPECIFICALLY enable password syncing (the default is to sync random passwords). Even then, the real user passwords can only be synced at the time of login. Because, as stated above, Okta stores passwords as hashes.
(Full disclosure, I have been an Okta employee for over 8 years)
The Lapsus$ incident was a disaster, and simultaneously showed a lack of technical competence, PR maturity and trustworthiness.
Though I don't even know what Okta is.
This is a serious hole though. Suppose I have figured out how to obtain working credentials for the Okta administrator at Big Corp. At 0815 on Friday morning I use those credentials, and as the administrator I tell Okta to synchronise passwords for Big Corp to https://steal-passwords.example/
As each Big Corp employee signs in with Okta that morning, Okta "correctly" sends over their password to https://steal-passwords.example/ for me.
How quickly do Big Corp figure out there's a problem? Once they realise that I have their Okta administrator's credentials, can they shut me out while they investigate or do they need Okta to help them? How easy is it for them to find out about my password stealing operation?
This reminds me of the situation with private keys for certificates in the Web PKI ("SSL certificates"). So long as you do this correctly you cannot get into trouble. But once you try to fudge things, maybe because it seems easier, and now a private key is (even briefly) in the possession of another party, it's game over for security. When you trust Okta to keep passwords safe, they can (and here do) fuck that up.
Does Okta offer a product where they can't make things worse? Note that a product where there's a config setting "Make things worse", even behind six "Are you really sure?" dialogs is worthless for this purpose, the actual product that your customer bought needs to irrevocably be better than nothing. My guess from this is maybe no.
Getting working credentials for an Okta administrator is not unlike getting working credentials for the “root” user on a UNIX system.
Note that, as with getting root, this edge case isn’t the only way that an attacker could compromise the security of an Okta tenant.
Similar attack vectors might include: setting up an AD or LDAP directory with delegated authentication or adding a password Webhook.
The way that you mitigate these sorts of issues are very similar to how you’d mitigate the risk of a bad actor getting root access:
1. Log everything, check the logs frequently 2. Require that all administrators use multiple factors to log in (Yubikey, WebAuthn, etc) 3. Tightly scope who has access to what. Limit the permissions to only what a person needs 4. Etc, etc
I’m not trying to downplay the scenario that you present, it is serious. However, as with any computer system, eventually somebody has to have administrative access, with all of the privileges and risk that come with that access.
Well, it's like if you had root for an early UNIX system which was the company's only computer. I have root on numerous systems today, but even though they're all tied to a vast directory system with tens of thousands of users I can't just see the passwords for those users, that's not how it works.
Because of its intent as an SSO, Okta will have everything. If they're signing in, they're signing in to Okta, whether that's to read their email, make a leave request in the HR system, check in changes to a company revision control service, read the new brand guidelines in the Sharepoint, whatever. All those passwords get snaffled.
Worse, as I understand it, this isn't restricted to some root-like overall administrator for the entire Okta system, which we might imagine is locked down to two or three people in a CSO role - instead it's app administrators, which might include dozen of other people across the business many of whom have other priorities above security.
Is there at least a master "Off" switch for this feature so that app admins can't turn it on if your organisation decided not to use it?
> eventually somebody has to have administrative access, with all of the privileges and risk that come with that access.
What those privileges are is up for grabs though. In lots of systems they don't include "Learn other people's passwords" and in Okta they do. I argue they shouldn't.
I mentioned private keys in the Web PKI earlier. We forbade root CAs from knowing your private key. Rather than relying on possibly naive users to know they shouldn't give anybody their private key, we told the CAs if you learn somebody else's key, that key is now worthless, revoke certificates for the associated public key. The result is that if you somehow got privileges at an important root CA like say, ISRG (Let's Encrypt) you don't get people's private keys, they don't have them and designed all their systems to never learn what those keys are.
But you _could_ likely install a malicious ssh server, bash binary, or whatever, that logs them for you as people enter them.
In addition, changing critical settings, like plain-text password replication, should require a separate second-factor confirmation. This prevents stolen tokens from being able to do too much damage.
The "root" user has been acknowledged as a design flaw even by the team that was making Research UNIX, the people who later moved on to build Plan 9 (which didn't have a root account[0]). That was a late 1980s / early 1990s design.
Even modern systems are attempting to do away with root, or to restrict its unlimited power: reduce the necessity for setuid-root (e.g. via capabilities(7) on Linux[1]), restrict some actions (such as writing to mounted raw disk devices) which shouldn't normally occur at runtime (e.g. securelevel(7) in OpenBSD[2]), the fact that OpenSSH defaults PermitRootLogin to "without-password"; or ultimately - the craziness that is SELinux - the fact that some people are willing to put up with SELinux just to restrict what root can do is IMHO enough of a sign that having root in the first place was maybe not a great idea.
[0]: http://doc.cat-v.org/plan_9/4th_edition/papers/auth [1]: https://man7.org/linux/man-pages/man7/capabilities.7.html [2]: https://man.openbsd.org/securelevel.7
> The way that you mitigate these sorts of issues are very similar to how you’d mitigate the risk of a bad actor getting root access:
I think the most important bit about all five examples I've named is that every one of these is a default (not everywhere, but at least in the upstream project), that administrators have to go out of their way to disable these mitigations, and that (for the most part) all of these are transparent to the normal operation of the system.
Of course you can't fix bad security hygiene, but you can always make doing the more secure thing easier (or in worst case, doing the insecure thing harder).
I would have loved to not sync passwords this way, but there is often no support for that, and okta is really not at fault here.
SSO is an enterprise feature, if available at all. And most of the time we are left with some sort of password sync. It's horrible. And this is why I sympathize with okta here: what should they do? Not support shitty usecase X?
Sure, enabling this should probably have a 24h cooldown and several safety nets. But I think this is not on okta in this case.
You can’t just wave your hands and say it “makes things worse”. The far more common scenario is that 70% of help desk calls are for password resets, which make it pretty easy to social engineer or otherwise compromise a user account through that process. If the hacker can compromise the whole system by grabbing an admin’s credential… you lost the game before you even started as that’s a risk you need to control for in other ways. (Ie MFA, PAM, etc)
If you don’t or can’t trust your identity team to notice a compromise that causes your IDP to sync passwords to a hostile system, why do you trust them to manage user identities in a fragile system like AD that’s pretty trivial to compromise?
Sorry, when it comes to passwords, in particular plain text ones, this is not good enough.
Then you repeatedly say "hashes", which may mean anything from md5 to argon2id and whatever. Given that Okta stores plaintext in some cases, the generic use of the term "hashes" is a bit of a red flag to me, to be honest.
We looked at our internal data, it seemed admins loved to drop admin accounts on systems by default, so dropping plaintext to nearly all systems when they rotated those credentials led to a mechanism for lateral movement with across their network.
That was a good option anyway because there's generally a bajillion ways an administrator account can change passwords that can't all be plugged by the client software. So the end user systems can get their, say, FileVault view of their password out of sync, so you have to cleanly handle the cases when the backend doesn't even know the FileVault password to send.
Syncing plain-text passwords implies that there's a configurable URL where all plain-text passwords are sent out.
(March 22) Hackers claim to have breached Okta systems [1]
(March 22) Updated Okta Statement on Lapsus$ [2]
(March 23) Okta’s Investigation of the January 2022 Compromise [3]
(March 27) Okta: “We made a mistake” delaying the Lapsus$ hack disclosure [4]
(March 29) New documents for the Okta breach [5]
[1] https://news.ycombinator.com/item?id=30762520
[2] https://news.ycombinator.com/item?id=30769537
[3] https://news.ycombinator.com/item?id=30775180
What???
Can someone fill me in as to why they can’t just store the password using something like bcrypt?
I guess you either have to store the password in plaintext so they can do dynamic hashing operations on it, or transmit the password (via TLS hopefully) which is vulnerable to packet capture (or captured within the receiving app).
Are there any techniques for identity providers to authenticate people without storing or transmitting the users password to them?
> OAuth is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password.
The answer is for the third-party apps to add modern auth, but this is dependent on the vendor, not Okta. The only alternative is to have unmanaged logins, which is arguably worse than SCIM.
SCIM is there as a last resort, its use is heavily discouraged.
Doesn't this presume that the third-party app supports OIDC? Which again makes it dependant on the vendors, not Okta.
Say you use Google Workspace for your staff and have some application that uses SAML.
How do you tell the application about the users and groups in Google?
Well ideally Google has built an integration that can do this. That's not a big set of integrations, though.
Perhaps your application can just read the incoming user's identity and membership details during the login process.
If none of that is an option, you need to use something to read the lists of users and groups, and push those over to your application. SCIM is a reasonable (if not 'great') way of doing this.
AWS SSO[1] (now "AWS IAM Identity Center") is an example of this.
[1] https://docs.aws.amazon.com/singlesignon/latest/developergui...
e: Also, you need to consider the de-provisioning thing, too. Leaving resources hanging around for people that have left can be expensive and/or annoying.
You have the application use SLDAP to query the group with entitlements to the system.
There’s no magic here. The google integrations are using SCIM iirc.
If you're trying to do this right, the short answer is "don't try to sync passwords." Use federated authentication (such as OAuth), or just use different passwords.
Can someone fill me in as to why they can’t just store the password using something like bcrypt?
It's addressed in the last paragraph: "For Okta's part, the passwords are in clear text because there is no standard reliable protocol for syncing hashes, researchers noted."
I guess you either have to store the password in plaintext so they can do dynamic hashing operations on it, or transmit the password (via TLS hopefully) which is vulnerable to packet capture (or captured within the receiving app).
TLS (when securely configured) is generally considered sufficient protection for the passwords in transit because stealing the password out of TLS typically requires first compromising the TLS connection, in which case you don't even need the password because you can steal the bearer token and the bearer token doesn't require you to get past a MFA check.
Are there any techniques for identity providers to authenticate people without storing or transmitting the users password to them?
This question doesn't quite compute for me, do you mean provisioning as opposed to authenticating? There's no reason an identity provider would need to send a user's password to the user when trying to authenticate that user.
Incorrect. Okta stores passwords as hashes.
By default, random passwords are synchronized when an administrator sets up SCIM and enables password synchronization. If the administrator specifically configures SCIM to synchronize the real passwords, then the downstream system will only get the real password for a user after a user successfully logs in.
> This question doesn't quite compute for me, do you mean provisioning as opposed to authenticating? There's no reason an identity provider would need to send a user's password to the user when trying to authenticate that user.
I believe "them" here referred to "identity providers" - that is, can an identity provider authenticate a person without that person sending their password to the identity provider?
The response to that is yes, though they are not widely used - WebAuthn is a standard though that covers this - though in such a system there simply is no password.
The idea that you would have a password but not send it to the identity provider makes no sense: the whole purpose of the identity provider is to recognize you. When using an IdP, you are protecting your password from the final website who only gets to see what details you allow the identity provider to share with them. If you trust the website more than the identity provider, you shouldn't be using the identity provider at all.
It's possible to prove to a remote system that one knows their own password without sending the password (or an equivalent, like NTLM hashes). Secure Remote Password protocol (SRP)[1] is one specific implementation.
[1] https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
In the words of Raymond Chen this exploit is basically being on the other side of the air tight hatch
If I have local admin on a company laptop, it makes sense I can cause it to record the passwords of other employees who use the laptop so that I can retrieve them later. This is not so different from just shoulder surfing them and has the same cure - disciplinary policy maybe resulting in termination.
But it would be extraordinary if as local admin of my laptop I can just tell the domain controller "Please give me plaintext passwords for all the other users of this global Windows domain as they log in anywhere in the world". And that's what this Okta feature does.
Okta uses bcrypt to store passwords.
Are there any techniques for identity providers to authenticate people without storing or transmitting the users password to them?
There are several! WebAuthn is one of the better methods to do this.
"When users authenticate to Okta with a local Okta password, credentials are stored in the Okta cloud. Okta uses salted bcrypt with a high number of rounds to protect the Okta passwords." [1]
1. https://www.okta.com/resources/whitepaper/okta-security-tech...
I would not only hash it already on the client side, but have it also encoded with a freshly generated one-time-use public key on the client side every time it is being transmitted to my servers.
And has been for two decades. I was just a high-school kid with a website in ~2001 and I knew plaintext was bad even then.
I did it anyway, but it was just some homebrew blog I built.
There are however real schemes to avoid transmitting passwords that may interest you, like PAKEs: https://en.wikipedia.org/wiki/Password-authenticated_key_agr.... But there are still compelling reasons not to use these, e.g. https://palant.info/2018/10/25/should-your-next-web-based-lo....
1. Hashing client-side in addition to standard server-side handling (Have I Been Pwned passwords disallowed, good hash function, preferably memory-hard, salted, peppered for storage, etc.). In this case client-side hashing adds complexity but doesn't improve the security model at all, so we shouldn't do it. Which is why nobody does it.
2. Hashing client-side instead of standard server-side handling. In this case client-side hashing completely breaks the security model, since the hash is equivalent to a cleartext password, so we shouldn't do it. Besides random websites, this kind of mistake has actually been made at scale. See https://en.wikipedia.org/wiki/Pass_the_hash.
In summary, basic client-side hashing either doesn't improve security or compromises it, and is therefore best avoided.
No, this feature is basically Okta working as a password-manager for systems not supporting oauth-flows / single-sign-on. Of course they then need to store and forward the actual passwords to log you in.
How does hashing on the client side help?
If you're using a common web framework, there's almost certainly packages/plugins that will manage SSO and 2fa, and despite the constant fud, dealing with user accounts really isn't all that hard. More importantly, understanding the mechanics of your user account system will pay dividends as your product grows and new authN/Z requirements arise.
Okta works really well in your use case. I recommend trying it out yourself.
Since you mention YubiKeys, I’d also suggest that you try removing passwords from your setup entirely by using YubiKeys and one or more other factors.
If you don’t want to use Okta, I’m also happy to give you my take on the alternatives to consider. Feel free to reach out to me directly.
Just remember that properly upgrading Keycloak without downtime is nearly impossible without booting up a second instance on a clone of your database and moving traffic over there, so if you have anything that needs to work 24/7, wait for HA upgrades feature that's supposedly coming soon.
At the end, does SSO improve the security, compared to password manager ?
at least they still have Auth0, and the branding is still somewhat distanced
A slightly longer explanation is that SAML is based on a garbage cryptographic signature standard called “XML-DSig” which, among other issues, allows for partial signatures and stores the signature inside the XML element that it signed.
Honestly, SAML is something of an info hazard. I don’t recommend learning more about it. But if you really want to, this blog post goes into more detail: https://dev.to/workos/fun-with-saml-sso-vulnerabilities-and-...
You have a signing authority and it liaisons access. Though it does go in the wrong direction a little bit with SAML
This has lead to things like popular SAML parsers that do not even attempt to validate the signature. For examples of how this has gone badly wrong, see https://workos.com/blog/fun-with-saml-sso-vulnerabilities-an... .
OpenID was meant to be the successor but popularity wise SAML is still the champion with enterprises.
SCIM doesn't really have a successor afaik. Azure AD I think doesn't do password sync, I am not sure who twisted Okta's hands to get this implemented.
The people who like easy solutions are the Fortune 500.
How do you propose your average enterprise should manage auth for these legacy systems without using SCIM?
However, I’m curious to learn why you think SCIM is a “bad” protocol, can you explain why you don’t like it?
if someone tells me to sell them shit for 1m ARR i'm going to get squattin and shittin
seems kinda like the responsibility of the person building the application and managing your users' data to do your due diligence on where the keys to the kingdom go
but... on second thought it's crazy that okta even provides this lmao. It's different when you're a SaaS provider with a position of being secure compared to being an indie merc contractor. Hell, if I was an indie merc, I'd straight up just not do it out of principle.