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

41–50 of 90 posts

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#41

Post by aobdev »

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.

They’re talking specifically about client-side hashing. You’re right that the system will hash the stolen hash, but only in cases where the system can’t be bypassed (which client side code always can be).

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#42

Post by reitzensteinm »

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…

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

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#43

Post by jf »

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.

(Disclaimer: I’m an Okta employee)

Okta works really well in your use case. I recommend trying it out yourself.

Since you mention YubiKeys, I’d also suggest that you try removing passwords from your setup entirely by using YubiKeys and one or more other factors.

If you don’t want to use Okta, I’m also happy to give you my take on the alternatives to consider. Feel free to reach out to me directly.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#44

Post by kache_ »

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

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#45

Post by sascha_sl »

jf wrote: post #31
munchbunny wrote: post #19

Earlier quoted context omitted.

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…

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.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#46

Post by kache_ »

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

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#47

Post by sascha_sl »

bagels wrote: post #24

Is there an alternative to OKTA for managing sso access for a hundred users with second factor across a couple dozen websites?

If you want to self-host, Keycloak. You can then either find OIDC/SAML integrations for your systems or use something like Pomerium to add authentication via a proxy.

Just remember that properly upgrading Keycloak without downtime is nearly impossible without booting up a second instance on a clone of your database and moving traffic over there, so if you have anything that needs to work 24/7, wait for HA upgrades feature that's supposedly coming soon.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#50

Post by tjoff »

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.

Post reply on HN