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

21–30 of 90 posts

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#21

Post by hnzix »

GauntletWizard wrote: post #5

Okta has always been a marketing organization first and a security organization second. Their support (and encouragement!) of bad protocols like SCIM and SAML are no surprise. Their target market are people who like easy solutions.

Okta's primary use case is for enterprise orgs with dozens or hundreds of third party apps that need to be integrated. You use modern auth with the 90% of apps that support it. But there are almost always a couple of legacy apps that aren't going to add OAuth anytime soon if ever.

How do you propose your average enterprise should manage auth for these legacy systems without using SCIM?

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#22

Post by hnzix »

beberlei wrote: post #20
hnzix wrote: post #18

Earlier quoted context omitted.

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 ar…

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.

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

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#23

Post by FreakLegion »

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.

Hashing the password client-side just means that the hash is now the password. Storing that hash is no different than storing the password, and when someone dumps out your database they can log in directly with the hash, because it's the password. So you still need to take all the same precautions you would with the original password, including hashing it again. For your trouble here you get essentially no security value, assuming you're doing everything else right, but do get some additional risk thanks to the extra moving part.

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

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#25

Post by paranoidrobot »

hnzix wrote: post #18
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…

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 ar…

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

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#26

Post by windowsworkstoo »

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

In the words of Raymond Chen this exploit is basically being on the other side of the air tight hatch

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#28

Post by oefrha »

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.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#29

Post by suriyaG »

FreakLegion wrote: post #23
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.

Hashing the password client-side just means that the hash is now the password. Storing that hash is no different than storing the password, and when someone dumps out your database they can log in directly with the hash, because it's the password. So you still need to take all the same precautions you would with the original password, including hashing it again. For your trouble here you get essentially no security v…

I'm confused. How is it possible to login directly with the hash? I was under the impression that if you use the hashed password obtained from the DB, then the system will try to match the hash of the hash and would fail because they would be different.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#30

Post by jf »

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)

Post reply on HN