5 ms·

+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 c

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

staticassertion 5y ago
Because auth is super hard? Have you tried implementing SSO for arbitrary OAuth2 providers?
- 9dev 5y ago
  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.
  - staticassertion 5y ago
    Can you link me to these open source libraries that will handle arbitrary oauth2 providers?
    - m12k 5y ago
      This seems to be one of the more popular ones: https://www.keycloak.org/ https://www.keycloak.org/
      - staticassertion 5y ago
        Thanks, I'l check keycloak out.
    - 9dev 5y ago
      As I wrote in a sibling comment: Keycloak, for one: https://www.keycloak.org https://www.keycloak.org I've also heard good things about Hydra: https://www.ory.sh/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 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.
  - mdoms 5y ago
    This is ridiculously reductive.
    - 9dev 5y ago
      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.
      - Karrot_Kream 5y ago
        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.
  - photon12 5y ago
    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.
  - ta34634643 5y ago
    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.
- njsubedi 5y ago
  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.
  - ryan_lane 5y ago
    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.
    - njsubedi 5y ago
      I can tell you don't know about OpenID Connect. ;)
photon12 5y ago
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.
taurath 5y ago
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.
- Nextgrid 5y ago
  > 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.
3np 5y ago
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".
- Johnny555 5y ago
  consult an outside company to do the work for you Maybe a company that specializes in this kind of thing? Like Okta?
  - 3np 5y ago
    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.
    - Johnny555 5y ago
      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.
      - 3np 5y ago
        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.
yibg 5y ago
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.
- njsubedi 5y ago
  That's a good one! :thumbsup:

staticassertion 5y ago

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

9dev 5y ago
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.
- staticassertion 5y ago
  Can you link me to these open source libraries that will handle arbitrary oauth2 providers?
  - m12k 5y ago
    This seems to be one of the more popular ones: https://www.keycloak.org/ https://www.keycloak.org/
    - staticassertion 5y ago
      Thanks, I'l check keycloak out.
  - 9dev 5y ago
    As I wrote in a sibling comment: Keycloak, for one: https://www.keycloak.org https://www.keycloak.org I've also heard good things about Hydra: https://www.ory.sh/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 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.
- mdoms 5y ago
  This is ridiculously reductive.
  - 9dev 5y ago
    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.
    - Karrot_Kream 5y ago
      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.
- photon12 5y ago
  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.
- ta34634643 5y ago
  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.
njsubedi 5y ago
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.
- ryan_lane 5y ago
  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.
  - njsubedi 5y ago
    I can tell you don't know about OpenID Connect. ;)

photon12 5y ago

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.

taurath 5y ago

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.

Nextgrid 5y ago
> 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.

3np 5y ago

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

Johnny555 5y ago
consult an outside company to do the work for you Maybe a company that specializes in this kind of thing? Like Okta?
- 3np 5y ago
  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.
  - Johnny555 5y ago
    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.
    - 3np 5y ago
      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.

yibg 5y ago

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.

njsubedi 5y ago
That's a good one! :thumbsup: