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

51–60 of 90 posts

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#51

Post by tgv »

kache_ wrote: post #44
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.

don't hate the provider hate the buyer if someone tells me to sell them shit for 1m ARR i'm going to get squattin and shittin

I'd say that when the provider says "it's safe!" (and Okta does that: the words trust and secure are all over their front page), then the buyer may assume that it's true. Should the buyer get hacked because the provider leaked plain-text passwords, it is clearly the latter's fault.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#52

Post by jf »

sascha_sl wrote: post #45
jf wrote: post #31

Earlier quoted context omitted.

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…

But how long is such a password stuck in the system, e.g. if the downstream is unreachable.

Good question! If I remember correctly, the downstream system has only one chance to handle the HTTP request from Okta.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#53

Post by matsemann »

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.

> This is ridiculous and unjustifiable.

No, this feature is basically Okta working as a password-manager for systems not supporting oauth-flows / single-sign-on. Of course they then need to store and forward the actual passwords to log you in.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#54

Post by tsimionescu »

munchbunny wrote: post #19
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…

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, t…

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

I believe "them" here referred to "identity providers" - that is, can an identity provider authenticate a person without that person sending their password to the identity provider?

The response to that is yes, though they are not widely used - WebAuthn is a standard though that covers this - though in such a system there simply is no password.

The idea that you would have a password but not send it to the identity provider makes no sense: the whole purpose of the identity provider is to recognize you. When using an IdP, you are protecting your password from the final website who only gets to see what details you allow the identity provider to share with them. If you trust the website more than the identity provider, you shouldn't be using the identity provider at all.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#55

Post by Jenk »

tjoff wrote: post #50
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…

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

Sso provider

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#56

Post by justusw »

bagels wrote: post #37
justusw wrote: post #27

Earlier quoted context omitted.

Are you talking about customer facing SSO?

I'm talking about my company uses jira, git, aws, etc., and I'd like to centrally enforce SSO + yubikeys.

This is just my personal opinion and after evaluating it from a compatibility angle I found that Azure AD is suitable. We are using it with Nextcloud, Apple Business Manager, Tailscale and Figma. U2F is not well supported, but OTP works well (with yubico auth as well of course.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#57

Post by FreakLegion »

suriyaG wrote: post #29
FreakLegion wrote: post #23

Earlier quoted context omitted.

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.

You're not wrong. To clearly delineate the two possibilities:

1. Hashing client-side in addition to standard server-side handling (Have I Been Pwned passwords disallowed, good hash function, preferably memory-hard, salted, peppered for storage, etc.). In this case client-side hashing adds complexity but doesn't improve the security model at all, so we shouldn't do it. Which is why nobody does it.

2. Hashing client-side instead of standard server-side handling. In this case client-side hashing completely breaks the security model, since the hash is equivalent to a cleartext password, so we shouldn't do it. Besides random websites, this kind of mistake has actually been made at scale. See https://en.wikipedia.org/wiki/Pass_the_hash.

In summary, basic client-side hashing either doesn't improve security or compromises it, and is therefore best avoided.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#59

Post by GauntletWizard »

lll-o-lll wrote: post #11
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.

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 different interpretations of the message.

This has lead to things like popular SAML parsers that do not even attempt to validate the signature. For examples of how this has gone badly wrong, see https://workos.com/blog/fun-with-saml-sso-vulnerabilities-an... .

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#60

Post by tialaramex »

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

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.

Post reply on HN