Hacker News Reader

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?

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.

> Getting working credentials for an Okta administrator is not unlike getting working credentials for the “root” user on a UNIX system.

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.

> I can't just see the passwords for those users, that's not how it works

But you _could_ likely install a malicious ssh server, bash binary, or whatever, that logs them for you as people enter them.

> Require that all administrators use multiple factors to log in (Yubikey, WebAuthn, etc)

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.

This is a great idea. I’m going to share this with the Okta product team.

> Getting working credentials for an Okta administrator is not unlike getting working credentials for the “root” user on a UNIX system.

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).

An Okta organization administrator by definition has the ability to compromise the auth config of any systems the company uses Okta to SSO into. Setting up a user password exfiltration mechanism is probably one of the least damaging ways of abusing that level of trust.

Typically that would be detected by monitoring.

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?

I have been administering things when I started my career.

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.