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

81–90 of 90 posts

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#81

Post by mdtusz »

bagels wrote: post #39
mdtusz wrote: post #34

Earlier quoted context omitted.

I'm sure many will disagree, but just implement it yourself if you're an SP. If you're using a common web framework, there's almost certainly packages/plugins that will manage SSO and 2fa, and despite the constant fud, dealing with user accounts really isn't all that hard. More importantly, understanding the mechanics of your user account system will pay dividends as your product grows and new authN/Z requirements ar…

Apologies that my question wasn't clear enough. I am building a remote company and we use a ton of products. I'd like centralized authentication + sso + ability to enforce yubikeys for AWS, Jira Cloud, Bitbucket, and a ton of others that OKTA supports for SSO.

Azure Active Directory manages this well. If your company uses office365, it's likely you already are using this under the hood.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#82

Post by jf »

magicalhippo wrote: post #74
jf wrote: post #64

Earlier quoted context omitted.

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…

> Require that all administrators use multiple factors to log in (Yubikey, WebAuthn, etc) In addition, changing critical settings, like plain-text password replication, should require a separate second-factor confirmation. This prevents stolen tokens from being able to do too much damage.

This is a great idea. I’m going to share this with the Okta product team.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#83

Post by wcarss »

tialaramex wrote: post #66
jf wrote: post #64

Earlier quoted context omitted.

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

> I can't just see the passwords for those users, that's not how it works

But you _could_ likely install a malicious ssh server, bash binary, or whatever, that logs them for you as people enter them.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#84

Post by monocasa »

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

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#85

Post by kache_ »

tgv wrote: post #51
kache_ wrote: post #44

Earlier quoted context omitted.

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.

If I sell you shit and you happily eat it, but then 3 months later you're like "dude, why did you make me eat shit?". Idk.

seems kinda like the responsibility of the person building the application and managing your users' data to do your due diligence on where the keys to the kingdom go

but... on second thought it's crazy that okta even provides this lmao. It's different when you're a SaaS provider with a position of being secure compared to being an indie merc contractor. Hell, if I was an indie merc, I'd straight up just not do it out of principle.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#86

Post by GauntletWizard »

kache_ wrote: post #85
tgv wrote: post #51

Earlier quoted context omitted.

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.

If I sell you shit and you happily eat it, but then 3 months later you're like "dude, why did you make me eat shit?". Idk. seems kinda like the responsibility of the person building the application and managing your users' data to do your due diligence on where the keys to the kingdom go but... on second thought it's crazy that okta even provides this lmao. It's different when you're a SaaS provider with a position o…

You can't blame the shit-seller for making you eat shit, but you can choose not to eat at restaurants that have shit on the menu. I choose not to work with Okta.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#87

Post by WhyNotHugo »

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…

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.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#88

Post by tatersolid »

WhyNotHugo wrote: post #87
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…

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.

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

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#89

Post by deepakprab »

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?

It's just riddled with vulnerabilities but most of them are now well known and mitigated.

OpenID was meant to be the successor but popularity wise SAML is still the champion with enterprises.

SCIM doesn't really have a successor afaik. Azure AD I think doesn't do password sync, I am not sure who twisted Okta's hands to get this implemented.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#90

Post by deepakprab »

jf wrote: post #38
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?

The short version of why SAML is bad is because it’s based on XML. This means that SAML is not only subject to the usual vulnerabilities that you’d expect, but also XML vulnerabilities! A slightly longer explanation is that SAML is based on a garbage cryptographic signature standard called “XML-DSig” which, among other issues, allows for partial signatures and stores the signature inside the XML element that it signe…

We (BoxyHQ) are an SSO and Directory Sync vendor like WorkOS and they are spot on with the details of the SAML vulnerabilities. We have guarded against these attacks so our customers don't have to but plenty of companies still roll out their own implementations, not all of them securely.
Post reply on HN