19 ms·

And this is why I would ultimately never trust a centralised company with our authentication infrastructure: because something like Okta is an infinitely more a

• njsubedi 5y ago
  +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
  I wouldn't throw out the baby with the bathwater. I don't know how publicly it's acknowledged, but most people I know in security have always had a poor view of Okta's security. 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.
  • bushbaba 5y ago
    Security IS hard. Every single day there’s a zero day practically released. 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.
    • staticassertion 5y ago
      > Every single day there’s a zero day practically released 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.
      • lanstin 5y ago
        Log4j was memory safe. Tho I agree on mTLS and even would like most valuable networks to be connected only via an allow list of safe-ish destinations. It would make things a lot harder, and the logs of denied hosts would also be a nice warning.
        • staticassertion 5y ago
          Yep, after memory safety there's still work to be done. But it'll be a lot less work.
          • 5y ago
• paxys 5y ago
  95% of companies on the planet do not have the necessary resources or expertise to run a robust authentication infrastructure, and this one hack (which we really know nothing about at this point) doesn't change that fact. 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.
  • 9dev 5y ago
    > 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.
    • hutzlibu 5y ago
      "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?
      • 9dev 5y ago
        Yes. 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.
        • ddaalluu2 5y ago
          Yes but I'm having trouble with the client side. Especially Cordova or Capacitor. In a hybrid app with keycloak in the back it's just not working. I tried the cordova-native keycloak adapter but it's just not working. Pure Vue or Angular no issues. Flutter issues because AppAuth is not very well documented and it's even worse for Android Java or Kotlin. Security or auth should be treated as the president of the 1st class citizens, instead it's a mess. On the backend everything is fine, but frontend is in a really bad state.
• tommoor 5y ago
  Apparently Plaid has 40% penetration of US bank account holders[1], and of course their entire business is storing the username and passwords for all those accounts so they can screen scrape. I struggle to think of a more attractive target than that! [1] https://www.thediff.co/p/plaid-data-layer-to-payments-layer https://www.thediff.co/p/plaid-data-layer-to-payments-layer
  • ec109685 5y ago
    So unfortunate banks haven't implemented SSO and fine grain access control after all the years.
    • wdb 5y ago
      Ain’t that idea of the Open Banking standard?
      • ec109685 5y ago
        Good point. Updated to "implemented".
• sergiotapia 5y ago
  That's part of the equation. 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.
  • hakre 5y ago
    > 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." No, not just that.
• advaitruia 5y ago
  There is a lot of conversation here about building your own vs using something 'centralized'. All software comes with the “build vs buy” tradeoff. 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)
• jjav 5y ago
  > something like Okta is an infinitely more attractive target than we are 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.
• berkes 5y ago
  Ah. Yes. The old 'security through obscurity' protection. It doesn't work.
  • 9dev 5y ago
    No, that's distinctively different. This is about distributing attack surface, not obscuring authentication infrastructure. Are we really at a point where not relying on external account providers is considered unusual, or a bad practice? I'm not buying it.
    • berkes 5y ago
      > something like Okta is an infinitely more attractive target than we are 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.