4 ms·

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

by jf 4y ago

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

reitzensteinm 4y ago
Yes - there are enough legitimate reasons to avoid Okta that we don't need to go making more up. The Lapsus$ incident was a disaster, and simultaneously showed a lack of technical competence, PR maturity and trustworthiness.
tjoff 4y ago
If the attacker can enable that edge-case it isn't that comforting. Though I don't even know what Okta is.
- Jenk 4y ago
  Sso provider
tialaramex 4y ago
> 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/ 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/ 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.
- jf 4y ago
  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/ 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/ 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.
  - tialaramex 4y ago
    > 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.
rndgermandude 4y ago
>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.
- jf 4y ago
  Okta uses bcrypt for hashing passwords, extra details can be found here: https://www.okta.com/resources/whitepaper/okta-security-technical-white-paper/#tenant-data-security-26 https://www.okta.com/resources/whitepaper/okta-security-tech...
monocasa 4y ago
When I worked at a competing SSO provider with device management, we specifically engineered our solution to this same problem to never send down passwords. Squirreling away plaintext passwords to send to remote systems over open Internet (even with mutual TLS) was seen as something that would at the least put egg on our face if someone wrote a blog post about it. 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.
WhyNotHugo 4y ago
Okta should simply sync hashes, not plain-text passwords. Syncing plain-text passwords implies that there's a configurable URL where all plain-text passwords are sent out.
- tatersolid 4y ago
  Different systems and apps use different password hashing algorithms. So syncing a hash is often useless.

by jf 4y ago

reitzensteinm 4y ago

Yes - there are enough legitimate reasons to avoid Okta that we don't need to go making more up. The Lapsus$ incident was a disaster, and simultaneously showed a lack of technical competence, PR maturity and trustworthiness.

tjoff 4y ago

If the attacker can enable that edge-case it isn't that comforting. Though I don't even know what Okta is.

Jenk 4y ago
Sso provider

tialaramex 4y ago

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

jf 4y ago
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/ 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/ 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.
- tialaramex 4y ago
  > 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.

rndgermandude 4y ago

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

jf 4y ago
Okta uses bcrypt for hashing passwords, extra details can be found here: https://www.okta.com/resources/whitepaper/okta-security-technical-white-paper/#tenant-data-security-26 https://www.okta.com/resources/whitepaper/okta-security-tech...

monocasa 4y ago

When I worked at a competing SSO provider with device management, we specifically engineered our solution to this same problem to never send down passwords. Squirreling away plaintext passwords to send to remote systems over open Internet (even with mutual TLS) was seen as something that would at the least put egg on our face if someone wrote a blog post about it. 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.

WhyNotHugo 4y ago

Okta should simply sync hashes, not plain-text passwords. Syncing plain-text passwords implies that there's a configurable URL where all plain-text passwords are sent out.

tatersolid 4y ago
Different systems and apps use different password hashing algorithms. So syncing a hash is often useless.