Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Okta Exposes Passwords in Clear Text for Possible Theft

darkreading.com

Post reply on HN
Print view View original

61–70 of 90 posts

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#61

Post by rndgermandude »

jf wrote: post #30

There seems to be a lot of confusion here. First of all, for the users that have passwords, Okta stores those passwords as hashes. 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…

>only true in an edge case

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.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#62

Post by Sebb767 »

oefrha wrote: post #28
boomboomsubban wrote: post #4

Am I reading this right? Are they defending having passwords in clear text by saying only admins can access it?

The feature is essentially a syncing password manager for legacy apps that only support password authentication. Password manager exposes passwords in clear text, no shit.

Just for the record, they usually don't even do that, but user a randomly generated password for each app and user (like a password manager would). You can configure it to use the users password, though, for example for edge cases when the user also needs to log in to the app himself.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#63

Post by jf »

rndgermandude wrote: post #61
jf wrote: post #30

There seems to be a lot of confusion here. First of all, for the users that have passwords, Okta stores those passwords as hashes. 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…

>only true in an edge case 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.

Okta uses bcrypt for hashing passwords, extra details can be found here: https://www.okta.com/resources/whitepaper/okta-security-tech...

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#64

Post by jf »

tialaramex wrote: post #60
jf wrote: post #30

There seems to be a lot of confusion here. First of all, for the users that have passwords, Okta stores those passwords as hashes. 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…

> When an Okta administrator has set up password syncing to a downstream system. 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…

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.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#65

Post by tialaramex »

windowsworkstoo wrote: post #26
yardstick wrote: post #6

> For Okta's part, the passwords are in clear text because there is no standard reliable protocol for syncing hashes, researchers noted. However, Authomize noted that Okta did pledge to have its product team take a closer look at the password-leak risks. 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 s…

To answer the why plain text, the feature this talks about is the Okta Secure Web App - basically if an app cant do proper SSO you can set it up as SWA which just acts like a password manager. The Okta browser plugin will just fill out the login form of whatever site for you. One bonus feature with SWAs is the admin can set a password for all users, making it a cheap way to share an account transparently for all your…

But it's not quite an "air tight hatch" situation. Chen deals typically with Windows stuff, so lets shade this as if it was a Windows problem.

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.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#66

Post by tialaramex »

jf wrote: post #64
tialaramex wrote: post #60

Earlier quoted context omitted.

> When an Okta administrator has set up password syncing to a downstream system. 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…

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…

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

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#67

Post by lll-o-lll »

GauntletWizard wrote: post #59
lll-o-lll wrote: post #11

Earlier quoted context omitted.

How is SAML bad? Old and ugly perhaps, but are there specific security issues? Also SCIM; I don’t think it’s a great standard, but what’s the alternative?

SAML signs "XML Documents". It does not sign the specific bytes of a document, you have to perform a transform to get the "canonical" version of the document and that's what you perform cryptography on. This creates a large surface for different implementations to be incompatible, subtly, but more importantly it creates a surface area for the nastiest bugs in authentication - When the sender and receiver have differe…

Thanks, this was an interesting and informative read.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#68

Post by skywhopper »

boomboomsubban wrote: post #4

Am I reading this right? Are they defending having passwords in clear text by saying only admins can access it?

The article is wrong about that detail. The syncing only happens at login time. No passwords are stored in plaintext.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#69

Post by lelanthran »

de6u99er wrote: post #12

This is ridiculous and unjustifiable. Hashed pqsswords in databases is the absolutely bare minimum nowadays. 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.

> I would not only hash it already on the client side,

How does hashing on the client side help?

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#70

Post by treffer »

tialaramex wrote: post #60
jf wrote: post #30

There seems to be a lot of confusion here. First of all, for the users that have passwords, Okta stores those passwords as hashes. 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…

> When an Okta administrator has set up password syncing to a downstream system. 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…

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.

Post reply on HN