6 ms·

> For Okta's part, the passwords are in clear text because there is no standard reliable protocol for syncing hashes, researchers noted. However, Authomize note

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

green_on_black 4y ago
Yes there are techniques, e.g. OAuth.
- metadat 4y ago
  The OAuth protocol involves someone else storing and verifying the password (e.g. Microsoft authenticated you already), and then you trust that whatever the provided token says is true. > OAuth is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password.
hnzix 4y ago
SCIM integration is for legacy apps that don't support modern auth. I'm not an expert, but I believe Okta is essentially filling in the legacy app's login page automatically. By definition this action requires a password to be transmitted in plaintext. 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.
- beberlei 4y ago
  SCIM is a sensible protocol and useful for syncing users and groups from central system to apps, syncing the clear text password is the problem, it should be used to sync user id and group membership only and the OpenId Connect performs the login.
  - hnzix 4y ago
    > OpenId Connect performs the login Doesn't this presume that the third-party app supports OIDC? Which again makes it dependant on the vendors, not Okta.
    - jf 4y ago
      It presumes that the legacy app supports an SSO protocol like OIDC, SAML, or WS-Fed. Ideally the app will support one of those protocols directly, otherwise it’s possible to bolt on support for one of those protocols via a proxy.
- paranoidrobot 4y ago
  SCIM is also there to allow filling gaps between systems that use federated identity. 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/developerguide/what-is-scim.html 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.
  - Spooky23 4y ago
    > How do you tell the application about the users and groups in Google? 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.
munchbunny 4y ago
It seems that the fundamental problem here is Okta is sending passwords by design to execute a password sync. Typically, when you build an authentication system, you design your code to not store the password in plaintext so that there is no possibility of the password being read back out of the system, but Okta isn't doing this because they need to be able to do password syncing. 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.
- jf 4y ago
  Typically, when you build an authentication system, you design your code to not store the password in plaintext so that there is no possibility of the password being read back out of the system, but Okta isn't doing this because they need to be able to do password syncing. 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.
  - sascha_sl 4y ago
windowsworkstoo 4y ago
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 users. In the words of Raymond Chen this exploit is basically being on the other side of the air tight hatch
- tialaramex 4y ago
  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.
jf 4y ago
Can someone fill me in as to why they can’t just store the password using something like bcrypt? 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.
chirau 4y ago
Okta does use bcrypt. "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-technical-white-paper/#tenant-data-security-26 https://www.okta.com/resources/whitepaper/okta-security-tech...

green_on_black 4y ago

Yes there are techniques, e.g. OAuth.

metadat 4y ago
The OAuth protocol involves someone else storing and verifying the password (e.g. Microsoft authenticated you already), and then you trust that whatever the provided token says is true. > OAuth is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password.

hnzix 4y ago

SCIM integration is for legacy apps that don't support modern auth. I'm not an expert, but I believe Okta is essentially filling in the legacy app's login page automatically. By definition this action requires a password to be transmitted in plaintext. 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.

beberlei 4y ago
SCIM is a sensible protocol and useful for syncing users and groups from central system to apps, syncing the clear text password is the problem, it should be used to sync user id and group membership only and the OpenId Connect performs the login.
- hnzix 4y ago
  > OpenId Connect performs the login Doesn't this presume that the third-party app supports OIDC? Which again makes it dependant on the vendors, not Okta.
  - jf 4y ago
    It presumes that the legacy app supports an SSO protocol like OIDC, SAML, or WS-Fed. Ideally the app will support one of those protocols directly, otherwise it’s possible to bolt on support for one of those protocols via a proxy.
paranoidrobot 4y ago
SCIM is also there to allow filling gaps between systems that use federated identity. 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/developerguide/what-is-scim.html 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.
- Spooky23 4y ago
  > How do you tell the application about the users and groups in Google? 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.

munchbunny 4y ago

It seems that the fundamental problem here is Okta is sending passwords by design to execute a password sync. Typically, when you build an authentication system, you design your code to not store the password in plaintext so that there is no possibility of the password being read back out of the system, but Okta isn't doing this because they need to be able to do password syncing. 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.

jf 4y ago
Typically, when you build an authentication system, you design your code to not store the password in plaintext so that there is no possibility of the password being read back out of the system, but Okta isn't doing this because they need to be able to do password syncing. 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.
- sascha_sl 4y ago

windowsworkstoo 4y ago

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 users. In the words of Raymond Chen this exploit is basically being on the other side of the air tight hatch

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

jf 4y ago

Can someone fill me in as to why they can’t just store the password using something like bcrypt? 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.

chirau 4y ago

Okta does use bcrypt. "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-technical-white-paper/#tenant-data-security-26 https://www.okta.com/resources/whitepaper/okta-security-tech...