Hacker News Reader

Comment by njsubedi | Hacker News Reader

+1 to this. Why outsource the most business-critical parts like auth and email to a third party, knowing that they're the biggest target? I know that the most common argument is "they know $service more than we do", but don't really have a counter argument against it.

View on HN

Because in both auth and email one can make a small screw-up that allows for a company threatening breach. As someone who has performed penetration tests for all of: companies that roll their own SSO, companies that use a third party SSO service, companies that provide third party SSO services, the failure modes for contracting out to a third party are a bit easier to manage if you are a small company, and chances are if your SSO provider is breached they are going to care about bigger fish than you.

For medium to large enterprises, the calculus is harder and there's going to be months of flame war trying to hash that out.

Its expensive and keeping the expertise around and maintaining it was seen as not worth the cost.

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.

> In some ways, if Okta can fall basically anyone can

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.

So hire someone who does, or consult an outside company to do the work for you. You can get the expertise without necessarily having it in-house. There are agencies both big and small that can help you, including training your existing staff.

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

consult an outside company to do the work for you

Maybe a company that specializes in this kind of thing? Like Okta?

I meant specifically to do an integration for you on your infrastructure, not to use a centralized PaaS/SaaS like Okta. I'm not in a position to say that Okta never does this for anyone, like key customers, but it is not part of their standard offering.

But you said you want a company with expertise, who has more expertise at building and running an SSO service than a company that's selling that service?

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.

The parallel to conventional software infrastructure would be: Hire staff, or contract local expertise from reputable businesses, to build and maintain your software (probably using existing technologies rather than writing everything from scratch) on bare-metal or colo, rather than reaching for fully managed PaaS for your entire stack.

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.

> who has more expertise at building and running an SSO service than a company that's selling that service?

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.

Because auth is super hard? Have you tried implementing SSO for arbitrary OAuth2 providers?

Why would I ever need to support arbitrary Oauth2 providers? As long as they're following the standards, a generic Oauth2 client should suffice. If they're misaligned with the standards I wouldn't be using their service.

I can tell you never have, because there's no such thing as a generic OAuth2 implementation. They're all slightly different and incompatible. SAML is what you really want in terms of making things works more generically, but even that is generally a nightmare as you still need mappings.

I can tell you don't know about OpenID Connect. ;)

No, but there are both open source libraries, and complete authorisation servers. If you trust Okta, you can trust these, and embed them in your infrastructure. Auth only gets super hard if you try to be smart and deviate from best practices.

I agree with you on not outsourcing authentication etc to a big provider like Okta, but OAuth2/SSO can get ridiculously annoying in large organization/s. If it's one app that you're dealing with, no worries. If it's multiple operating systems, multiple legacy and new apps etc, its a headache. Not that Okta particularly helps with that either though, it's a problem full stop.

Doing user IP address change detections as part of a heuristic vector for account compromise is sometimes a best practice and sometimes a great way to generate a bunch of useless noise, but I know which is less likely to break UX by integrating such a feature.

Can you link me to these open source libraries that will handle arbitrary oauth2 providers?

As I wrote in a sibling comment:

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.

This seems to be one of the more popular ones: https://www.keycloak.org/

Thanks, I'l check keycloak out.

This is ridiculously reductive.

Could you expand a little? Of course a HN comment is not giving you full instructions on implementing custom authentication infrastructure, but that doesn't mean it's impossible or somehow "wrong" to do so, if you rely on established libraries and patterns.

OAuth2 is a really complicated standard and is complicated to get correct. I mentally compare it with SIP which also has several open-source implementations but still often ends up getting outsourced to others due to the sheer complexity of the thing. Though in OAuth2's case I'm willing to say it's complicated because security is complicated. With SIP I really don't know why lol.

Can't you say the same thing about a lot of stuff? Why outsource hosting to a third party like AWS, knowing they're the biggest target? I trust AWS a lot more than myself when it comes to securing infrastructure.

That's a good one! :thumbsup:

Reply on news.ycombinator.com