hckrnws
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 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)
> 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 that morning, Okta "correctly" sends over their password to 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.
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 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?
Getting working credentials for an Okta administrator is not unlike getting working credentials for the “root” user on a UNIX system.
Note that, as with getting root, this edge case isn’t the only way that an attacker could compromise the security of an Okta tenant.
Similar attack vectors might include: setting up an AD or LDAP directory with delegated authentication or adding a password Webhook.
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:
1. Log everything, check the logs frequently 2. Require that all administrators use multiple factors to log in (Yubikey, WebAuthn, etc) 3. Tightly scope who has access to what. Limit the permissions to only what a person needs 4. Etc, etc
I’m not trying to downplay the scenario that you present, it is serious. However, as with any computer system, eventually somebody has to have administrative access, with all of the privileges and risk that come with that access.
> 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 not how it works.
Because of its intent as an SSO, Okta will have everything. If they're signing in, they're signing in to Okta, whether that's to read their email, make a leave request in the HR system, check in changes to a company revision control service, read the new brand guidelines in the Sharepoint, whatever. All those passwords get snaffled.
Worse, as I understand it, this isn't restricted to some root-like overall administrator for the entire Okta system, which we might imagine is locked down to two or three people in a CSO role - instead it's app administrators, which might include dozen of other people across the business many of whom have other priorities above security.
Is there at least a master "Off" switch for this feature so that app admins can't turn it on if your organisation decided not to use it?
> eventually somebody has to have administrative access, with all of the privileges and risk that come with that access.
What those privileges are is up for grabs though. In lots of systems they don't include "Learn other people's passwords" and in Okta they do. I argue they shouldn't.
I mentioned private keys in the Web PKI earlier. We forbade root CAs from knowing your private key. Rather than relying on possibly naive users to know they shouldn't give anybody their private key, we told the CAs if you learn somebody else's key, that key is now worthless, revoke certificates for the associated public key. The result is that if you somehow got privileges at an important root CA like say, ISRG (Let's Encrypt) you don't get people's private keys, they don't have them and designed all their systems to never learn what those keys are.
> 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.
> 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.
> Getting working credentials for an Okta administrator is not unlike getting working credentials for the “root” user on a UNIX system.
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).
An Okta organization administrator by definition has the ability to compromise the auth config of any systems the company uses Okta to SSO into. Setting up a user password exfiltration mechanism is probably one of the least damaging ways of abusing that level of trust.
Typically that would be detected by monitoring.
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?
I have been administering things when I started my career.
I would have loved to not sync passwords this way, but there is often no support for that, and okta is really not at fault here.
SSO is an enterprise feature, if available at all. And most of the time we are left with some sort of password sync. It's horrible. And this is why I sympathize with okta here: what should they do? Not support shitty usecase X?
Sure, enabling this should probably have a 24h cooldown and several safety nets. But I think this is not on okta in this case.
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.
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.
If the attacker can enable that edge-case it isn't that comforting.
Though I don't even know what Okta is.
Sso provider
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.
>only true in an edge case
Sorry, when it comes to passwords, in particular plain text ones, this is not good enough.
Then you repeatedly say "hashes", which may mean anything from md5 to argon2id and whatever. Given that Okta stores plaintext in some cases, the generic use of the term "hashes" is a bit of a red flag to me, to be honest.
Okta uses bcrypt for hashing passwords, extra details can be found here: https://www.okta.com/resources/whitepaper/okta-security-tech...
This 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
[2] https://news.ycombinator.com/item?id=30769537
[3] https://news.ycombinator.com/item?id=30775180
There seems to be a small copy/paste mishap.
Thanks!
> 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?
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 arguably worse than SCIM.
SCIM is there as a last resort, its use is heavily discouraged.
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 and membership details during the login process.
If none of that is an option, you need to use something to read the lists of users and groups, and push those over to your application. SCIM is a reasonable (if not 'great') way of doing this.
AWS SSO[1] (now "AWS IAM Identity Center") is an example of this.
[1] https://docs.aws.amazon.com/singlesignon/latest/developergui...
e: Also, you need to consider the de-provisioning thing, too. Leaving resources hanging around for people that have left can be expensive and/or annoying.
> How do you tell the application about the users and groups in Google?
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.
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.
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, the short answer is "don't try to sync passwords." Use federated authentication (such as OAuth), or just use different passwords.
Can someone fill me in as to why they can’t just store the password using something like bcrypt?
It's addressed in the last paragraph: "For Okta's part, the passwords are in clear text because there is no standard reliable protocol for syncing hashes, researchers noted."
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).
TLS (when securely configured) is generally considered sufficient protection for the passwords in transit because stealing the password out of TLS typically requires first compromising the TLS connection, in which case you don't even need the password because you can steal the bearer token and the bearer token doesn't require you to get past a MFA check.
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.
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.
But how long is such a password stuck in the system, e.g. if the downstream is unreachable.
Good question! If I remember correctly, the downstream system has only one chance to handle the HTTP request from Okta.
> > 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" - that is, can an identity provider authenticate a person without that person sending their password to the identity provider?
The response to that is yes, though they are not widely used - WebAuthn is a standard though that covers this - though in such a system there simply is no password.
The idea that you would have a password but not send it to the identity provider makes no sense: the whole purpose of the identity provider is to recognize you. When using an IdP, you are protecting your password from the final website who only gets to see what details you allow the identity provider to share with them. If you trust the website more than the identity provider, you shouldn't be using the identity provider at all.
> The idea that you would have a password but not send it to the identity provider makes no sense
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...
To answer the why plain text, the feature this talks about is the Okta Secure Web App - basically if an app cant do proper SSO you can set it up as SWA which just acts like a password manager. The Okta browser plugin will just fill out the login form of whatever site for you. One bonus feature with SWAs is the admin can set a password for all users, making it a cheap way to share an account transparently for all your users.
In the words of Raymond Chen this exploit is basically being on the other side of the air tight hatch
But it's not quite an "air tight hatch" situation. Chen deals typically with Windows stuff, so lets shade this as if it was a Windows problem.
If I have local admin on a company laptop, it makes sense I can cause it to record the passwords of other employees who use the laptop so that I can retrieve them later. This is not so different from just shoulder surfing them and has the same cure - disciplinary policy maybe resulting in termination.
But it would be extraordinary if as local admin of my laptop I can just tell the domain controller "Please give me plaintext passwords for all the other users of this global Windows domain as they log in anywhere in the world". And that's what this Okta feature does.
Okta does use bcrypt.
"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...
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.
Yes there are techniques, e.g. OAuth.
The 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.
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.
Just 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.
Comment was deleted :(
The article is wrong about that detail. The syncing only happens at login time. No passwords are stored in plaintext.
Syncing 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.
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.
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 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_agr.... But there are still compelling reasons not to use these, e.g. https://palant.info/2018/10/25/should-your-next-web-based-lo....
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.
You're not wrong. To clearly delineate the two possibilities:
1. Hashing client-side in addition to standard server-side handling (Have I Been Pwned passwords disallowed, good hash function, preferably memory-hard, salted, peppered for storage, etc.). In this case client-side hashing adds complexity but doesn't improve the security model at all, so we shouldn't do it. Which is why nobody does it.
2. Hashing client-side instead of standard server-side handling. In this case client-side hashing completely breaks the security model, since the hash is equivalent to a cleartext password, so we shouldn't do it. Besides random websites, this kind of mistake has actually been made at scale. See https://en.wikipedia.org/wiki/Pass_the_hash.
In summary, basic client-side hashing either doesn't improve security or compromises it, and is therefore best avoided.
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).
> This is ridiculous and unjustifiable.
No, this feature is basically Okta working as a password-manager for systems not supporting oauth-flows / single-sign-on. Of course they then need to store and forward the actual passwords to log you in.
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.
> 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.
> I would not only hash it already on the client side,
How does hashing on the client side help?
& stock pops ~8% from 7/19~7/20
If you are in the US you may contact the SEC if you think those two are related.
Out of curiosity: do you really have to be/live in the US? You're not permitted to contact them in such case if you're investing on the US market with proper IRS forms filled?
You're right looks like anybody can contact them.
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.
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.
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.
(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.
There are many alternatives like CyberArk, OneLogin, Ping Identity and others.
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.
This 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.
WorkOS
So a single point of failure, also in plaintext?
At the end, does SSO improve the security, compared to password manager ?
damn Okta can't catch a break on optics
at least they still have Auth0, and the branding is still somewhat distanced
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.
Okta's primary use case is for enterprise orgs with dozens or hundreds of third party apps that need to be integrated. You use modern auth with the 90% of apps that support it. But there are almost always a couple of legacy apps that aren't going to add OAuth anytime soon if ever.
How do you propose your average enterprise should manage auth for these legacy systems without using SCIM?
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?
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?
SAML signs "XML Documents". It does not sign the specific bytes of a document, you have to perform a transform to get the "canonical" version of the document and that's what you perform cryptography on. This creates a large surface for different implementations to be incompatible, subtly, but more importantly it creates a surface area for the nastiest bugs in authentication - When the sender and receiver have different interpretations of the message.
This has lead to things like popular SAML parsers that do not even attempt to validate the signature. For examples of how this has gone badly wrong, see https://workos.com/blog/fun-with-saml-sso-vulnerabilities-an... .
Thanks, this was an interesting and informative read.
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-...
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.
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.
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
For what it’s worth…
The people who like easy solutions are the Fortune 500.
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.
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.
Crafted by Rajat
Source Code