I hope this spurs them to switch all employees to use Yubikeys for 2FA. Anything less than FIDO2 is really weak.
Can someone explain why people still choose Okta? I personally feel way more comfortable using GSuite as an IDP. Okta suffered a pretty terrible breach and, candidly, I hadn't heard great things about their security practices before that.
Enforcing hardware-based MFA is good practice and may protect against future attacks (the attackers might be back with a spear-phishing campaign?) but is completely irrelevant to what's actually happened here.
> Can someone explain why people still choose Okta?
Nobody's been fired for buying IBM. Also blame outsourcing - if your run your own Keycloak and get pwned it's on you, if it's Okta then it's not your problem.
Yeah sorry, I shouldn't have implied otherwise/ should have been clearer about that. I just thought it was notable that admins were not using stronger 2FA. This is a company that owns password management, it seems like having proper auth should be a number one priority.
Of course, once a session token is created you are past the initial point where a 2FA mechanism like a Yubikey would help.
> if your run your own Keycloak
Sure but I think most people would consider Google to be a far safer company than Okta, no? If not I think that they should be. TBH I feel like "session token used from a totally different computer/UA/IP/Region" is something Google may actually have caught.
Well, if implemented right. Techically every ssl connection would carry user's identity so cookie with that identity wouldn't even be required
Sounds like token binding.
But you can lock session tokens to specific IPs or user agents. I've implemented similar in the past for a B2B admin-panel, and whilst there were the occasional false positive with browsers updating in the middle of a session (incrementing the user agents version number) and people's IP changing if they switched networks (or in one instance, a badly configured office network that randomly routed through 2 proxy servers with different outbound IP addresses) which then made it demand MFA again, it was fairly rare and didn't attract too many complaints.
The session cookies were stolen. 2FA has nothing to do with this.
> Can someone explain why people still choose Okta? I personally feel way more comfortable using GSuite as an IDP. Okta suffered a pretty terrible breach and, candidly, I hadn't heard great things about their security practices before that.
Have you actually used Google Workspace for anything serious? It's one of the least capable IDPs out there, with Okta being one of the most capable. Comparing the two is like comparing a bicycle to a motor bike because they both have two wheels. Frankly, I'm surprised to read anyone on a technical forum recommend Google Workspace as an IDP.
I’ve spent quite a lot of time interacting with Okta support over system issues and frankly that experience does not leave me assured. My sense is that perhaps they’re wrangling software that has grown exponentially in size and complexity as they try to accommodate the myriad use cases.
I'm not suggesting everyone should use Okta either. Frankly I'm not the biggest fan of it myself. But I wouldn't argue it's less secure than Google Workspace when the big G forces you to workaround it's limitations with less secure implementations.
Okta is quite flexible and supports a lot of tech you want (WebAuthN/SCIMv2 provisioners for popular platforms/all the SSO/API integration/workflows), but comes with it's own set of warts and dysfunction (api rate limits, quirky AD integration with anything complicated).
Probably any of them would be suitable, if you are comfortable building your own custom tooling AROUND their APIs. Almost none of them will do exactly what you need out of the box.
I had replied 5 hours earlier than your post already saying that I understood that. I was just quoting from their report because I think it's interesting.
> Have you actually used Google Workspace for anything serious?
Yes lol I'd rather not comment on which of the companies I've worked at that used Google as an IDP but you're welcome to speculate - they all have thousands of employees and followed AWS best practices around user/role management. I can say that we used it at the company I founded as well, though.
Often these places end up with two domains because working with Corporate IT is painful for agile development scrums. But the issue there is company culture, not the IDP.
I'm yet to see anyone use Google Workspace effectively at enterprise scale (startups, sure. But startups optimise for speed of development, not long term scalability).
Most people don't choose Okta. Somebody at the executive level chooses Okta and everybody else gets to deal with it.
Yubikeys mean that your IT department now does customer support for every single password issue instead of handing it off to the outsourcing company.
MFA has two problems: the technical one (technical security aspects of implementing keys, fobs, phones, SMS, whatever) which is almost irrelevant and the social one (customer support, forgotten passwords, key through the wash, can't get email, etc.) which is the gigantic one.
Everybody wants to outsource the gigantic, dumbass customer support role of security. The problem is that everybody is also incentivized to cut corners once having done so.
Which gives you Okta ...
If you just do YubiKeys but not Okta, your staff takes all the calls. Yubi sure isn't going to do the customer support when Employee #46 can't log into Office 365 today.
That's why people outsource this to Okta and its ilk.
When we SSO to Okta - they will for some applications (VPN, Github, etc..) require us to MFA with our Yubikey. But for some other, lower risk applications, MFA isn't required.
When an employee has difficulty connecting to one of the 84 applications that we SSO via Okta - they file a ticket with IT, not Okta. There is no way any employee would even know how to contact Okta, and there isn't any way that Okta could troubleshoot for the employee anyways - the source of truth for their password (first factor) would be the corporate Active Directory server.
Okta doesn't (to my knowledge) provide any customer support (I guess they might work with IT if there is a service-outage) to our employees. It's just an IdP SaaS.
GSuite as an IDP is very very limited. Sure, it checks that box as "Yes, is IDP"
However if you want to do much beyond "can connect", it's either difficult or impossible.
Take for example you're an organisation that has all employees in GSuite.
You also have an AWS organisation, and need to provide access - well, AWS SSO[1] is the recommended way to do this. I set up the connection, and people can now connect.
However there's some gaps:
There's no automatic user [de]provisioning into AWS SSO, based on GSuite user groups. (You could write some code to do this via the SCIM support in SSO, but you have to maintain it)
There's no way on either the GSuite or AWS SSO side to enforce an MFA check when the SSO session is being set up.
GSuite doesn't let you require an MFA check before authenticating to SAML applications.
AWS SSO doesn't allow forcing MFA check when using an IDP, even though it does if you use it's internal Directory.
Okta, and similar products (can) do those things for you, and allow some of those MFA checks to be based on what endpoint is being used. At least according to their marketing materials and sales people. I've never actually done it myself.
I guess the tl;dr is that Okta provides a lot more options for automation and security glue between the identity provider and consuming application(s).
[1] When I say AWS SSO, I mean specifically the AWS product: "AWS IAM Identity Center (Successor to AWS Single Sign-On)"
Lack of auto-provisioning seems like the biggest issue to me.
> There's no way on either the GSuite or AWS SSO side to enforce an MFA check when the SSO session is being set up.
I don't know what you mean here but I'm curious if you wouldn't mind?
Much of what you're talking about seems to be when a 2FA is forced. With GSuite it's forced on login, and CAA is forced on SSO, and that's it. If you want other 2FA prompts (such as with AWS) those are configured through that service. I think you're saying that Okta would allow you to force the 2FA on login to and also then when you want to access some other system via SSO it would ask you to 2FA again?
It's only available in the Enterprise plan levels.
> I don't know what you mean here but I'm curious if you wouldn't mind?
Using the prior example where GSuite is my IDP. If I want to require an MFA check before granting access to AWS SSO - I've got no way of doing this.
CAA might help, but if I want to be explicit "Hey, this has access to customer data - we're always going to do an MFA check on this access", there's no good way of doing this.
Using an intermediary like Okta would allow you to do that additional level of checking.
e: To be clear, I'm using AWS SSO as the destination application as an example. There's other applications that you might want to control access to that also have particularly sensitive data where you want to re-verify that someone else hasn't just walked past an unlocked laptop and decided to poke around.
It can be bought separately for Business iirc.
> there's no good way of doing this.
Through GSuite, agreed. But you could just configure the 2FA for the downstream service, no? That's what we did at my company.
> There's other applications that you might want to control access to that also have particularly sensitive data where you want to re-verify that someone else hasn't just walked past an unlocked laptop and decided to poke around.
For sure, I'm not trying to argue or debate or anything, was just curious.
Only if the downstream service supports it. Lots don't, or at least don't enforce it when you come in via SSO.
AWS SSO being the one I keep coming back to, because it bugs me so much.
For those that do, you now have to also manage the 2FA tokens with that service, using whatever they support. Often that's SMS based 2FA, or maybe TOTP, or their own custom TOTP/Push. Maybe they support FIDO2, but only a single FIDO2 key.
Unfortunately, GSuite seems to move very slowly :\
Here is the evidence I have seen regarding Okta's security: 1. The had a breach last year. 2. They just had another breach. The breach was in their customer service department/system. 3. They may or may not have been slow to disclose the breach (remember, they may not have realized they were breached because they may get a lot of false breach reports and they may not have found evidence of a breach until recently). 4. They did not give credit to the customer who first reported the breach. 5. They may not have communicated with the customer after the customer reported the breach.
Here is what we don't know:
A. How skilled was the attacker. Skilled attackers are better at covering their tracks and harder to catch.
B. How many breaches has each ID provider had?
C. How many breaches has each ID provider detected?
D. How many breaches has each ID provider detected and covered up?
E. How many security bugs are in each provider's service? How serious are the bugs? How easy are they to find?
F. How good is the provider at detecting breaches?
G. How well are the provider's employees trained?
H. What percentage of the ID provider's employees care about security. A lot of people in the tech industry (software engineers, IT/sys admins/devops, managers, etc.) claim they care about security but their actions say otherwise. Examples include using easily guessed passwords, not patching software/dependencies, writing insecure code (buffer overflows, SQL injection, cross site scripting errors, etc.).
My main point is bashing Okta because they reported a breach does not prove Okta's product is any worse than any other product because we just don't have the information. We don't know how good other products are and it is even possible Okta is better than some or all of its competitors (it could also be worse).
When it comes to AuthN, the right number of breaches is 0. Same argument for password managers, and why I advise people to stay clear of lastpass.
We all know that breaches do occur, it’s impossible to be 100% secure etc. but having multiple breaches when you’re a security service provider is simply unacceptable. And when the timeline shows you were slow to react, it’s negligible for anyone to continue using that service provider.
Data is great, but in lieu of it, that’s enough for me.
Even better don't put admin tools on the open internet, put them behind a VPN like wireguard. Then if the session cookies are stolen, they can't even access them anyway.
Just making the authentication and service endpoints inaccessible online significantly reduces the attack complexity.
There are a bunch of things folks forget when talking down zero trust; EG if it is done properly then the endpoint the user is using has to AuthN too, and be in good health. That solves cookie/token theft, forcing the attacker to fully route through the endpoint.
It's very simple and very effective. Also has no usability problems whatsoever.
And even if you don't have that, when authentication is your core business you might want to harden your sessions against transmission contents getting in the wrong hands by setting up an additional factor in the browser's local storage that gets challenged without putting the key on the wire. Sure, that local storage is no secrets vault, but you don't write some existing secret there, you set up an additional key that would protect e.g. from a .HAR playback. That's the nature of multi-factor tiered defense, protection from just one angle is protection nonetheless, perfect must not be the enemy of good.
Way too many horror stories about Google suddenly banning accounts here to ever trust them with this kind of responsibility.
Google supports billions of accounts and clearly screws up a few of them (which are noteworthy events precisely because they are so rare).
Okta’s total accounts under management are a fraction of this number and they clearly have compromised or put larger percentages of such accounts at risk given what’s been disclosed.
The problem is that Google doesn't (seem to) have any kind of customer support. Everyone's gonna get hacked at some point, including Google themselves, so I'll choose the company where I can at least get somebody on the phone.
Or 1password for that matter... do you really trust them as well?
"we are continuously enhancing our security measures"
How about not using Okta to begin with?
Also - never having worked for a company that hosted their own - what's the experience like - with Okta, you can essentially SSO onto hundreds (thousands?) of different cloud service providers. Similiar if you self-host?
Not saying you can do better, just saying that you can get the same level of quality for free without paying for an incompetent & expensive snake-oil vendor.
But if you want a non-exhaustive list, there are a few lessons we can learn at Okta's expense:
Not outsource support to low-wage boiler rooms could be a good start - that's what got them their previous breach some time ago, and the current breach isn't that far off although it seems more down to the support infrastructure than the people themselves.
If you can, restrict access per IP address. Even better, if everyone works out of the office or VPNs into it, don't expose the service publicly in the first place. Defense in depth, something we seem to have forgot in the process of putting everything on the public internet.
If you see an existing session token suddenly show up with a different user-agent and IP address (not matching previous usage patterns or expected wifi-to-mobile handover), invalidate the session and ask the user to reauth again.
If possible, high-value accounts need to be IP restricted in the first place to known IPs or at least subnets (if the employee is on a dynamic IP).
If you use Okta, every single Okta support person is a super-admin in your environment with access to every role in every app. It is trivial to do better than that.
It would be nearly impossible to achieve this level of compliance certification if it were this simple and this broken.
to the list of Okta certifications in your bookmarks? You absolutely did not do a search for it just now because that is a stale link so there is no way you even clicked through that link before pasting it and you already knew what was supposed to be on that page.
This is the current link: https://trust.okta.com/compliance/
And anyways, yeah, those certifications are useless box checking garbage that a totally broken system can get.
Solarwinds has most of those same certifications: https://www.solarwinds.com/trust-center
and they are a total clown show. In fact, basically all of the clown shows have those because all most of those standards amount to is verifying your paperwork is consistent.
returns a 404, page not found. There is nothing on that page.
I replied to you at most a few hours after you posted that link. Are you going to claim that Okta updated the url in that few hour long window? For that matter, you did not even double check the link after I said it was stale or you would have used that argument in your post since it is the only credible reason to claim a dead link had contents.
I’m honestly not sure why you’re so caremad about this either, your tone is extremely accusatory over something incredibly minor.
Saying “just self-host anything” makes a massive assumption that your company can afford to compete against Okta/Google for the same talent. Some companies can, but the vast majority of Okta’s user base can’t. You would be fighting against specialization and comparative advantage.
It might be possible that there are significantly better options than Okta, but I have yet to find them.
Okta has a major insider threat problem though (either their employees/subcontractors get pwned like last time, or their infra gets pwned like now). I would expect much better from a "security" vendor, and since they consistently fail at it, I wonder what else they fail at that we don't (yet) know.
> has behavior analysis features to detect login/session anomalies
This is what baffles me. Given the description of the attack some attacker reused a stolen session token from a different IP address (not sure if they bothered to spoof the UA) - how was this not immediately challenged, especially for a high-value account? I indeed expected this to get flagged immediately.
> that your company can afford to compete against Okta/Google for the same talent
Not sure about Google, but given the (repeated!) breaches, Okta can't compete for talent either, or that talent isn't actually everything.
A big advantage of self-hosting is that you reduce your exposure to opportunistic and "for the lulz" attacks - if someone breaches Okta, it's trivial for them to automatically pwn everyone. If you self-host, they'd have to know you exist and target you specifically - that doesn't scale. Plus you can layer extra security on top such as VPN and then your IdP is invisible from the outside and a potential attacker would first need a VPN exploit before they can even do the initial recon to find out what's your IdP and its vulnerabilities. Can't do that with Okta.
The consistent pattern of breaches and their nature makes me believe they are not a serious vendor worthy of the price or the trust people put in them, and missing a better option I'd rather self-host - all else being equal, at least it would save on the fees.
I have always found this argument so interesting. I host tens of services myself on a Raspberry Pi, with better uptime than many of your favorite cloud services. If a company cannot find even one person, earning a software salary, to host an open source IDP for tens or hundreds of employees, either something is deeply wrong with the company, the sysadmin talent pool, or both.
Companies learn the same lessons painfully when it comes to build-vs-buy. There is no such thing as "buy". There is "build", and there is "buy-and-build". Purchasing and deploying (or in executive speak, "implementing") a particular solution is at best 30% of the work - and less than that of the cost. The remainder goes into integrations, maintenance, customisations, ongoing configuration, adapting to ongoing user behaviour changes, adapting to ongoing development needs, etc.
Running an IdP is one of the very few ventures where four nines of reliability is still inadequate. Once you have a centralised auth, it CAN NOT break.
Okta: comprehensive scim allowing your IT instead of random application admins throughout your company to manage user provisioning / deprovisioning. Start pages that don't require users to remember urls but instead show them a list of applications they can use. Adaptive MFA with IT-administered settings (though Google's super-enterprisey solutions may have sth here.)
There's also OneLogin, Jumpcloud, or you can use Google Workspace and I think Azure AD too.
Not sure that "security" should be the top reason for switching from Okta to AzureAD.
Also, as a "user" (in IT), AAD is a royal PITA to use, with stupid limitations, such as not supporting group hierarchies. And don't even get me started on the horrid UX of the Azure portal. I've never used Okta in any capacity, though, so I don't know if it's any better.