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

31–40 of 90 posts

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#31

Post by jf »

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…

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 synchronization. If the administrator specifically configures SCIM to synchronize the real passwords, then the downstream system will only get the real password for a user after a user successfully logs in.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#32

Post by jf »

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…

Can someone fill me in as to why they can’t just store the password using something like bcrypt?

Okta uses bcrypt to store passwords.

Are there any techniques for identity providers to authenticate people without storing or transmitting the users password to them?

There are several! WebAuthn is one of the better methods to do this.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#33

Post by jf »

hnzix wrote: post #22
beberlei wrote: post #20

Earlier quoted context omitted.

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.

It presumes that the legacy app supports an SSO protocol like OIDC, SAML, or WS-Fed. Ideally the app will support one of those protocols directly, otherwise it’s possible to bolt on support for one of those protocols via a proxy.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#34

Post by mdtusz »

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?

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

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#35

Post by jf »

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.

As someone who has implemented SAML and SCIM, I agree with you about SAML.

However, I’m curious to learn why you think SCIM is a “bad” protocol, can you explain why you don’t like it?

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#37

Post by bagels »

justusw wrote: post #27
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?

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.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#38

Post by jf »

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?

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

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#39

Post by bagels »

mdtusz wrote: post #34
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?

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.

Re: Okta Exposes Passwords in Clear Text for Possible Theft

#40

Post by xander158 »

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.

I think you're confusing storing user password for access to Okta vs storing passwords in Okta for access to other applications. If you're going to use Okta as a password manager and store passwords to access other applications you can't hash the password because it irreversible and you won't be able to get the real password to authenticate with the other application. So you must encrypt the passwords instead.
Post reply on HN