If you are in the 5%, great! You are probably set already.
If you are not, overreacting isn't going to help anyone. There's no need to start writing user login code tonight.
I agree. That being said, there's no need to write login code yourself. Trust on the existing, tested, proven OSS solutions and libraries available, if you decide to not rely on a provider like Okta.
Can you recommend some?
I've also heard good things about Hydra: https://www.ory.sh/hydra/
Depending on your needs, an SSO proxy like Vouch works well for internal services: https://github.com/vouch/vouch-proxy
There's also an abundance of libraries for different programming languages to implement authentication or authorisation, lots of them battle-tested by thousands of services. It's not like providing secure services is impossible without Okta.
I think it's worth pointing out that replacing Okta for most people isn't just doing login +MFA stuff.
Sure, there's that part of it - but a lot of the value in going with Okta in particular is that so many third parties support integrating with them in ways that other Identity providers are just not supported.
Account lifecycle stuff (via SCIM) is often limited to just Okta support for products.
There's also the account lifecycle stuff so that HR doesn't have to tell you when they hire someone, they just add them into the HR system and all the things flow out from that. Similarly when someone leaves, you can have those workflows go and disable/delete their accounts.
In fact, a third-party’s “Okta integration” should work out of the box with Keycloak or any other IdP.
It also makes user lifecycle someone else's problem. Very important. As a medium and larger sized company, when you have to tell your customers your homegrown IAM was pwned, you're in for a world of hurt. When you're just in the boat with everyone else who got popped, it's an easily recoverable incident.
It doesn't really matter who runs your auth service, if the auth service getting pwned results in a reportable attack, you're in for a world of hurt.
The next step is to articulate why this isn't your fault and that you did everything you reasonbly could have done to not get pwned.
Do you have evidence to support you did your due dilligance on your provider?
So for example if you want to use AWS SSO tied to GSuite, you have to manually manage users, group membership, etc inside AWS SSO.
Similarly for a bunch of other products.
A couple of companies I've worked for now use GSuite as their primary accounts, and while a ton of things authenticate through GSuite (either as a built-in integration, or as SAML) - when you onboard/offboard users it involves going into a bunch of different systems to create/invite, set up group memberships, and then later deactivate accounts.
We're still considering Okta to solve all that workflow stuff. Yes, even after this event.
I believe Okta can also do custom security flows that GSuite can't.
So, if you're on a trusted device+network, then you might not need a 2FA challenge. Or conversely if you're trying to access a sensitive service - then always require a 2FA challenge every X hours.
though that sort of answers a followup Q, it would seem that there would be a market that punts the authentication to gsuite's saml, but automates the user creation and the like on the different services (and deactivation), but one still wouldn't have the "custom flows" as you said.
but if the custom flows aren't that important, I'd rather trust google to handle my authentication than okta, and in my pseudo-okta without authentication scenario, even access to my pseudo-okta would authenticate via google.
This reads to me like you are unfamiliar with keycloak, which is a very mature and capable solution with plenty of support for everything you mention other than SCIM.
Hosting it is not overly challenging, running it in a container would suffice for most companies. Updates are in my experience a smooth process.
I'm not claiming it's as easy as an "auth as a service" platform, but as we see, that comes with its own costs.
You will have to find someone to host and patch it, but we shouldn't pretend it's up there with write your own crypto.
Using saas is fine too. Often there cheaper than hiring a person until you need said person anyway, and at that point they're just a single point of failure, and people do underestimate the effort to run a production service well.
But we shouldn't be so anti-intellectual that we pretend that it's the only way to do things, and that well supported foss products don't exist.
[1] 2FA/Time based OTP: https://www.keycloak.org/docs/12.0/server_admin/keycloak-ima...
[2] LDAP/AD (Kerberos) https://dmc.datical.com/z_resources/images/assets/screenshot...
[3] SCIM (third party) https://github.com/Captain-P-Goldfish/scim-for-keycloak
Most of the time I'm talking about SCIM outbound, so provisioning/managing users in some other random service (like Trello, Github, whatever).
That's the major value-add for Okta.
https://stackoverflow.com/questions/58566587/does-keycloak-s...
So will likely require some changes to Keycloak internals in order to address that reliability issue, which will enable building a reliable interface for your use case.
Okta is a security company, and due to a well-organized, well-funded attacker, they were able to be breached. If a similar attacker is trying to breach you, you're likely going to get breached.
I think the logic here is accepting that if an attacker is trying to breach you, you’re likely going to get breached. But, if an attacker is trying to breach someone else, you’re still safe(-ish). With a centralized service, you don’t have to be the target to feel the effect.
At small company sizes, where dedicated security team or an admin with sufficient expertise to do proper setup is unaffordable, risk of Okta breach is lower than risk of automated custom setup breach. When you are big enough to deploy self-hosted solution and maintain it for reasonable cost, then yes, I would agree with you, self-hosted setup may reduce risks. When does that happen? When your company has over 1000 people (to break even with your Okta spending) or when your revenue per employee is high enough to spend every year 200-300k€ just on security.
That said, I would think Keycloak would fall under IT in many orgs. So you need a security org mature enough to have trained IT to the point where they can successfully run something this sensitive and security can have confidence in everything around it.
At a guess, that's not before you have 15-20 people in the security org. Probably something like: alerting and incident response (i.e., ops) is 3-5, vendor management 2-3, governance/audit 2-3, security engineering 3-5, security architecture 2-3, management 2-3, privacy 1-2. Run something like this for a year or two and see how the business as a whole shapes up.
As you say, it's a cost question. At what point does running your own IdP become the most valuable thing your company could do with a given chunk of money? One of the perks of a vendor is that the contract comes with liability. How much is that worth to the company?
Your company isn't delegating any operations away? Not even support? If they are, what level of access do those people have? Are the internal services they have access to as secure as your perimeter?
Even if they aren't, the attack can come through any internal employee, and your least security conscious person is your weakest link. Again, what do they have access to? Will they be able to use them to move laterally? Spear phishing from an internal employee to another employee is really, really effective.
BTW Keycloak.current has tossed JBoss & friends for Quarkus. In any case, it's been a remarkably safe product over the years.
Proxyshell and similar recent issues have shown “near-instant compromise” to be the current state of affairs. Most instances are attacked within hours or even days before a vulnerability is disclosed publicly and hits the news.
If "LAPSUS$" is after big companies with significant IP they can hold ransom for millions of dollars, it's most likely not even worth their time to find let alone attack your small company's on-prem SSO even if it was a single shell command away, so you'd still be more secure.
Wait, what exactly makes this problem so fundamentally hard?
What stops someone from just releasing a software system that solves the authentication infrastructure problem in a general way (e.g. as Kubernetes did for cloud orchestration)?
If you mean that a single codebase could be an attractive target for attacks, it's still not a problem since the Free Software community loves having a dozen of competing implementations of the same thing just for the sake of it :)
And this isn't even solved by having standard protocols, open source implementations as you mentioned -- only mitigated. OpenSSL was exploited too.
Kubernetes doesn’t go after it, either; it complicates your system so exponentially that it drives the same lie. All Kubernetes does is assign a workload to a machine and hook crap up to it. That problem was solved in the 1960s by systems that don’t take multiple FTEs just to operate itself. When you look at Kubernetes in this light there’s a moment of clarity waiting regarding why it exists in the first place, and why it will never in a millennium replace Borg.
In 2010, I joined a social media startup. I was the only operations employee on the team of nine who had ever touched an actual server with my hands. We’re on the third or fourth generation of systems people now who’ve never heard anything except the cloud-native drum and how they’ll never be qualified to run their fingers along the faceplate of the computers running their business. paxys is sharing a derivative of that because it is a strongly held industry belief and a safe language to speak in this market. It just doesn’t make it true, and that’s a powerful realization, but that’s not something most people are ready to hear and truly understand.
You’re asking the absolutely right questions. You’re just asking an industry that gave up on itself so long ago that kids born after UTAH2000 can vote now.
On the other hand, I feel fine using GSuite for SSO because we have a much better view of their security.
That said, it sucks that everyone is so fucking bad at security. I maintain that it is not that hard.
Add in systems that were built for X and now doing Y. This is hard to get right. A single slip up will lead to you being compromised.
Yeah, people need to stop using memory unsafe languages. They choose not to.
> A single slip up will lead to you being compromised.
Not if you add multiple layers of security. Like sandboxing. Or mTLS. It's not hard to do that.
edit: Let me clarify. Security isn't hard generally, but it's hard individually, because you're drowning under everyone else making it artificially 10000x harder.
Golang and Rust are not magic bullets that makes systems automatically secure.
Flaws in application logic have little to do with language choice.
Also consider the effort and money it takes to rewrite a multi million LOC system with several dependent apps. The new trendy languages introduce breaking changes, switch paradigms, and have less mature ecosystems.
What are their usual criticisms? Genuinely curious. I've always hated their UI, their docs, and lack of real support but felt that at least they had security going for them. The last assumption might have been proven wrong tonight.
Also, what would be a reasonable alternative to Okta now that their nearest competitor, Auth0, was acquired by them. Is GSuite a reasonable alternative for SSO with multiple different providers and supporting SAML, etc.? Thanks in advance.
I wouldn't want to make a recommendation, but I'll say that my company uses GSuite.
I'm struggling to see how that attack works without a copy of the private key.
Any pointers for what to search for to understand this better?
A better solution is to use ephemeral SSH keys generated using an SSH CA. This kind of thing can be implemented with Hashicorp Vault, though I'm sure there are plenty of other solutions out there.
It simplifies key checking on servers too, as they just need to the details of the signer and there's no need to juggle keys in LDAP.
I don't remember Google having any large-scale security incidens.
Have they been better at playing down their security incidents or are they doing something very right that the rest of the industry can learn from?
yes
> that the rest of the industry can learn from
unlikely
It's simple: they pay absurd amounts of money for top talent and let them work. Look: https://www.levels.fyi/company/Google/salaries/Software-Engi... can your company afford to pay 2-300K cash -- not to mention serious stock -- to bread and butter mid level engineers?
Then their SNMP mib doesn't work properly. So you have a a box that is proxying some of your most critical systems that are so old that to integrate them with MFA requires OAG (think mainframes, old ERP systems etc) and you have to take Okta's word for it that the server is secure and not hacked.
They do thankfully support Syslog for logs, but again you have to take their word for it that you're getting all the logs, because you can't access the system to verify.
Having said all that. OAG solves a very real business problem and it is hard to find a competitor in the market with the level of integration it has to legacy platforms.
Security isn't just about overflows and injections, outsider enemies vs insider allies. Any human with privileged access that can be compromised will eventually be compromised as the perceived value of his privilege increases beyond the cost of compromising him. Logging, distribution of privileges, and other such solutions aren't really solutions so much as just a sort of cat and mouse game.
I would claim that impenetrable security is not only hard, but ultimately impossible.
Keycloak, for one: https://www.keycloak.org
I've also heard good things about Hydra: https://www.ory.sh/hydra/
Depending on your needs, an SSO proxy like Vouch works well for internal services: https://github.com/vouch/vouch-proxy
There's also an abundance of libraries for different programming languages to implement authentication or authorisation, lots of them battle-tested by thousands of services. It's not like providing secure services is impossible without Okta.
For medium to large enterprises, the calculus is harder and there's going to be months of flame war trying to hash that out.
The problem is motivation to break it trends up over time as the service gets more and more popular.
In some ways, if Okta can fall basically anyone can. Sometimes there's an advantage in being smaller. One would hope that the actual attack surface on Okta was smaller than the post seems to imply. That there is even any way to get full access to all customers would seem to be a critical failure.
This might be true, but for someone to "fall" they must be targeted to begin with.
If "LAPSUS$" is after big companies with significant IP which they can hold ransom for millions, as a small business you'll be safe because they won't even bother attacking you, and may not be willing to put the same amount of effort into breaching your small company's SSO than they would for Okta.
Yes, it's going to cost more upfront, but there are a wide range of options between "rely on a blackbox PaaS/SaaS" and "write and deploy everything yourself".
Maybe a company that specializes in this kind of thing? Like Okta?
How do you have an SSO system without a centralized service? Whether you buy it as an outsourced SaaS service or run it yourself, it's still SaaS, but now you're on the hook for managing it and keeping it secure.
Or for comms, run a team- or company-wide chat server rather than relying on Slack/Teams/Discord.
Either you're missing my point (and maybe I didn't express myself super clearly), or you're pitching a false dichotomy.
> who has more expertise at building and running an SSO service than a company that's selling that service
OP illustrates well the consequence of that line of reasoning. I'm certain this is just the beginning as more too-big-to-fail vendors get compromised.
The cloud is just somebody elses' computer, "Move fast and break things" mean things get broken, etc.
Whenever we get subscription services for "smart security" involving cloud-connected cameras, AI-controlled locks and drones, would you also consider that as the one-size-fits all over having security guards or contracting companies like Securitas or your local equivalent?
> now you're on the hook for managing it and keeping it secure
You always were. There is no free lunch.
If Okta gets away with this (and the Equifax breach and subsequent outcome suggests they will) it proves that the market doesn't actually care about security, thus a company selling that service has little incentive to actually invest in security.
Agreed. Centralization of attack surface is a major risk.
I understand the allure and have been in situations where even knowing the risks, the path is forced upon us because "nobody is fired for buying IBM".
But yes, a centralized service holding all the marbles is an infinitely more attractive target than lots of disjoint little systems which aren't individually very interesting. The centralized system may be better run (arguable, but at least they have the resources and it is their primary job) but they also face a much higher attack concentration.
A compromise solution is to have both. I've been in one company where okta was used as the primary SSO and for most internal systems the only one. But for the very sensitive resources, one had to be authenticated via okta but also via a homegrown MFA system.
[1] https://www.thediff.co/p/plaid-data-layer-to-payments-layer
In a B2B setting you get rid of a LOT of paperwork and due diligence by just saying "We use Okta for X, Y, Z." Hell for SOC2, Okta got rid of a shit ton of verifications for us at a critical stage of the startup I was leading, Papa.
Sure you can build your own but at that point you're wasting months for zero customer benefit. You could be building product. I don't know what the right answer is.
No, not just that.
Commercial open source companies (COSS) minimise those tradeoffs and give you the best of both worlds. That is - The power of build and the speed of buy.
You can migrate to and from a completely self hosted solution to a managed service as your needs change (for many COSS alternatives)
It doesn't work.
In my book that counts as "obscurity". "We are not an attractive target, hence we won't be targeted". You will be targeted, as long as your defence is weak. Only if you manage to set up a comparable defence to a large provider, this argument flies: because all things equal, attackers will attack the more attractive party. But all things are not equal. (Which I'm not certain about, it may very well be that Okta has a really poor defence in place, in which case my argument falls apart, because you'd be able to "make all things equal" much easier. I doubt this though).
> Are we really at a point where not relying on external account providers is considered unusual, or a bad practice?
No. I consider it reasonable to "build your own", but only in certain cases. Things like auth are not your core domain (unless you are an auth-provider, obviously), so all effort and time you spend on building the umpteenth login/auth-flow is not spent on building the stuff that sets you apart. Even if you drag in a standard library and only spend an afternoon: you're still maintaining it, testing it, etc. And with external parties, generally, you'll be following market best practices: fingerprint-login becomes standard? You'll get it almost for free, whereas in the diy-case you'll be designing, testing, building such progressing tech for ever. The economics for building are just wrong.
As are the security: as pointed out above: I highly doubt you'll be able to match a level of defence a large, focused, experienced party can obtain.
But there may very well be cases in which building your own login/auth makes sense and the tradeoffs in economics and security (and features) make sense. Maybe it has to integrate into some legacy; maybe (legal) requirements enforce you to keep it all in-house, etc.
I find this point to require more subtlety; "we are not as much of an attractive target, so we likely won't be targeted by a sophisticated, human adversary" is more apt for the situation. The attack vector is just not comparable to Okta's scale, which is true for the majority of companies and platforms out there. That doesn't mean security should be taken lightly, just that the magnitude and frequency of bad things happening will be lower.
> Things like auth are not your core domain
That's a good point, but it depends on the situation. I wouldn't recommend spending lots of time on this yourself, but there are standard libraries or OSS solutions available. If you're optimising for reliability, it might be beneficial to keep auth within your own systems. If you're optimising for privacy under GDPR, for example, it might be beneficial to not trust your users' data to an external provider. And so on.
Unfortunately, this is in direct opposition to
> That doesn't mean security should be taken lightly
I agree about the subleties that, indeed, make the tradeoff more nuanced. You are less likely to be targeted. But, given that you "wouldn't recommend spending lots of time on this yourself" (my recommandation too), the trade-off balances dangerously into the "attractive target" too.
> but there are standard libraries or OSS solutions available.
Which, unfortunately is hardly different from "a centralized target". Look at, for example, WordPress. I used to have a WordPress hosting company: the constant battering on the entry-doors, by bots, and humans is real. The amount of successful breaches are staggering. I don't host anything WordPress anymore, yet IPs that haven't ever seen WP are hammered by bots trying to breach WordPress admin, XMLRPC, Woocommerce and so on.
By your reasoning, none of the WP sites we hosted back then were "attractive". By that reasoning, the servers I run now, without WP, are even less attractive. Yet they are battered by attackers. 24/7. And breached (not my current servers, though) quite often. Small websites for coaches, mom-pop-shops, the garage around the corner, your local football fanclub, and so on. Breached. Because they were an attractive target, not by being centralized, but because they weren't. Exactly because they use (OSS) libraries, combined with very little resources for defence, they are attractive.