16 ms·
Okta Exposes Passwords in Clear Text for Possible Theft
- hericium 4y agoThis post is from July. And earlier this year: (March 22) Hackers claim to have breached Okta systems [1] (March 22) Updated Okta Statement on Lapsus$ [2] (March 23) Okta’s Investigation of the January 2022 Compromise [3] (March 27) Okta: “We made a mistake” delaying the Lapsus$ hack disclosure [4] (March 29) New documents for the Okta breach [5] [1] https://news.ycombinator.com/item?id=30762520 https://news.ycombinator.com/item?id=30762520 [2] https://news.ycombinator.com/item?id=30769537 https://news.ycombinator.com/item?id=30769537 [3] https://news.ycombinator.com/item?id=30775180 https://news.ycombinator.com/item?id=30775180 [4] https://news.ycombinator.com/item?id=30819368 https://news.ycombinator.com/item?id=30819368 [5] https://news.ycombinator.com/item?id=30841413 https://news.ycombinator.com/item?id=30841413
- downvotetruth 4y ago& stock pops ~8% from 7/19~7/20
- ta988 4y agoIf you are in the US you may contact the SEC if you think those two are related.
- boomboomsubban 4y agoAm I reading this right? Are they defending having passwords in clear text by saying only admins can access it?
- oefrha 4y agoThe feature is essentially a syncing password manager for legacy apps that only support password authentication. Password manager exposes passwords in clear text, no shit.
- Sebb767 4y agoJust for the record, they usually don't even do that, but user a randomly generated password for each app and user (like a password manager would). You can configure it to use the users password, though, for example for edge cases when the user also needs to log in to the app himself.
- deleted 4y ago[deleted]
- skywhopper 4y agoThe article is wrong about that detail. The syncing only happens at login time. No passwords are stored in plaintext.
- GauntletWizard 4y agoOkta 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.
- lll-o-lll 4y agoHow 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?
- jf 4y agoThe 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 signed. Honestly, SAML is something of an info hazard. I don’t recommend learning more about it. But if you really want to, this blog post goes into more detail: https://dev.to/workos/fun-with-saml-sso-vulnerabilities-and-footguns-1feo https://dev.to/workos/fun-with-saml-sso-vulnerabilities-and-...
- deepakprab 4y agoWe (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.
- kache_ 4y agoIt's all the same thing with a different flavor You have a signing authority and it liaisons access. Though it does go in the wrong direction a little bit with SAML
- 4y ago
- yardstick 4y ago> 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 agoYes there are techniques, e.g. OAuth.
- metadat 4y agoThe 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 agoSCIM 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 agoSCIM 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.
- de6u99er 4y agoThis 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.
- mod 4y ago> Hashed pqsswords in databases is the absolutely bare minimum nowadays. And has been for two decades. I was just a high-school kid with a website in ~2001 and I knew plaintext was bad even then. I did it anyway, but it was just some homebrew blog I built.
- FreakLegion 4y agoHashing 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_agreement 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-login-form-avoid-sending-passwords-in-clear-text/ https://palant.info/2018/10/25/should-your-next-web-based-lo....
- suriyaG 4y agoI'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.
- 4y ago
- bagels 4y agoIs there an alternative to OKTA for managing sso access for a hundred users with second factor across a couple dozen websites?
- justusw 4y agoAre you talking about customer facing SSO?
- bagels 4y agoI'm talking about my company uses jira, git, aws, etc., and I'd like to centrally enforce SSO + yubikeys.
- justusw 4y agoThis 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.
- mdtusz 4y agoI'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 arise.
- bagels 4y agoApologies 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.
- jf 4y agoThere 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 agoYes - 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 agoIf the attacker can enable that edge-case it isn't that comforting. Though I don't even know what Okta is.
- Jenk 4y agoSso 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.
- kache_ 4y agodamn Okta can't catch a break on optics at least they still have Auth0, and the branding is still somewhat distanced
- jawadch93 4y ago[dead]
- monster_group 4y agoSyncing passwords is a bad idea and is really a legacy case for applications that don't support SSO. The correct way to do provisioning + auth is to use SCIM just for provisioning users and groups (with password based auth disabled in the downstream app) and use SSO (SAML / OIDC) from Okta to actually do the auth for the user. Also configure your SCIM API to never taken in the password if Okta sends it and never return it in case some user decides to set the password on the downstream app anyway.
- aborsy 4y agoSo a single point of failure, also in plaintext? At the end, does SSO improve the security, compared to password manager ?