71–80 of 90 posts
Am I reading this right? Are they defending having passwords in clear text by saying only admins can access it?
The feature is essentially a syncing password manager for legacy apps that only support password authentication. Password manager exposes passwords in clear text, no shit.
At the end, does SSO improve the security, compared to password manager ?
Earlier quoted context omitted.
> 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…
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…
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.
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…
> 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…
"When users authenticate to Okta with a local Okta password, credentials are stored in the Okta cloud. Okta uses salted bcrypt with a high number of rounds to protect the Okta passwords." [1]
1. https://www.okta.com/resources/whitepaper/okta-security-tech...
Earlier quoted context omitted.
> 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…
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…
The "root" user has been acknowledged as a design flaw even by the team that was making Research UNIX, the people who later moved on to build Plan 9 (which didn't have a root account[0]). That was a late 1980s / early 1990s design.
Even modern systems are attempting to do away with root, or to restrict its unlimited power: reduce the necessity for setuid-root (e.g. via capabilities(7) on Linux[1]), restrict some actions (such as writing to mounted raw disk devices) which shouldn't normally occur at runtime (e.g. securelevel(7) in OpenBSD[2]), the fact that OpenSSH defaults PermitRootLogin to "without-password"; or ultimately - the craziness that is SELinux - the fact that some people are willing to put up with SELinux just to restrict what root can do is IMHO enough of a sign that having root in the first place was maybe not a great idea.
[0]: http://doc.cat-v.org/plan_9/4th_edition/papers/auth [1]: https://man7.org/linux/man-pages/man7/capabilities.7.html [2]: https://man.openbsd.org/securelevel.7
> The way that you mitigate these sorts of issues are very similar to how you’d mitigate the risk of a bad actor getting root access:
I think the most important bit about all five examples I've named is that every one of these is a default (not everywhere, but at least in the upstream project), that administrators have to go out of their way to disable these mitigations, and that (for the most part) all of these are transparent to the normal operation of the system.
Of course you can't fix bad security hygiene, but you can always make doing the more secure thing easier (or in worst case, doing the insecure thing harder).
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…
> > 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" -…
It's possible to prove to a remote system that one knows their own password without sending the password (or an equivalent, like NTLM hashes). Secure Remote Password protocol (SRP)[1] is one specific implementation.
[1] https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
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…
You can’t just wave your hands and say it “makes things worse”. The far more common scenario is that 70% of help desk calls are for password resets, which make it pretty easy to social engineer or otherwise compromise a user account through that process. If the hacker can compromise the whole system by grabbing an admin’s credential… you lost the game before you even started as that’s a risk you need to control for in other ways. (Ie MFA, PAM, etc)
If you don’t or can’t trust your identity team to notice a compromise that causes your IDP to sync passwords to a hostile system, why do you trust them to manage user identities in a fragile system like AD that’s pretty trivial to compromise?
Earlier quoted context omitted.
SCIM 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 ar…
SCIM is also there to allow filling gaps between systems that use federated identity. Say you use Google Workspace for your staff and have some application that uses SAML. How do you tell the application about the users and groups in Google? Well ideally Google has built an integration that can do this. That's not a big set of integrations, though. Perhaps your application can just read the incoming user's identity a…
You have the application use SLDAP to query the group with entitlements to the system.
There’s no magic here. The google integrations are using SCIM iirc.