7 ms·

> The IT team member’s credentials for all systems were rotated, switched to only using a Yubikey for MFA, I hope this spurs them to switch all employees to us

> The IT team member’s credentials for all systems were rotated, switched to only using a Yubikey for MFA, 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.

latchkey 3y ago
> Can someone explain why people still choose Okta? 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?
- ghshephard 3y ago
  Who would you recommend as an iDP if not Okta?
  - Nextgrid 3y ago
    At this point any self-hosted option would do just as well. Not perfect, but not only it would require a targeted attack to pwn, but if you do end up pwned at least you weren't paying tens of thousands a year for the privilege.
    - ghshephard 3y ago
      I guess I'm curious as to how someone self-hosting would be able to perform their security better than a Tier 1 iDP. It would be the equivalent of trying to self-host email. 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?
      - Nextgrid 3y ago
        > I guess I'm curious as to how someone self-hosting would be able to perform their security better than a Tier 1 iDP. 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).
      - mike_d 3y ago
        > I guess I'm curious as to how someone self-hosting would be able to perform their security better than a Tier 1 iDP. 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.
        nixgeek 3y ago
        It’s extremely unlikely that every Okta Support employee has this level of access, much less on a persistent ongoing basis. It would be nearly impossible to achieve this level of compliance certification if it were this simple and this broken. https://www.okta.com/trust-page/compliance/ https://www.okta.com/trust-page/compliance/
        Veserv 3y ago
        Why do you have a link: https://www.okta.com/trust-page/compliance/ https://www.okta.com/trust-page/compliance/ 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/ 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 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.
    - thephyber 3y ago
      This is not a serious answer. It’s very unlikely that “any self-hosted option” actually competes with Okta’s IDP solutions, has really decent security, has very good logging features, has behavior analysis features to detect login/session anomalies, and has security staff to respond to those threats quickly. 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.
      - Nextgrid 3y ago
        > has really decent security 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.
      - lopkeny12ko 3y ago
  - latchkey 3y ago
    Personally, I'm fine with Google Workspace. IMHO, their track record for corporate auth, over the last what... decade... has been very good.
    - x0x0 3y ago
      Their security record is fantastic, but afaik they don't do what okta does. 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.)
  - radlad 3y ago
    I'm partial to Duo SSO because I helped build it (though I haven't worked there for years now.) There's also OneLogin, Jumpcloud, or you can use Google Workspace and I think Azure AD too.
    - vladvasiliu 3y ago
      > 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.
bsder 3y ago
> Can someone explain why people still choose Okta? 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 ...
- ghshephard 3y ago
  Aren't Yubikeys for MFA and Okta for iDP somewhat orthogonal? A common pattern that I've seen is companies use both.
  - insanitybit 3y ago
    Yes, they are unrelated. I brought up Yubikeys just because it was an interesting tidbit in the report.
  - bsder 3y ago
    They are, my point (which wasn't very clear) was that somebody needs to do the customer support. 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.
    - insanitybit 3y ago
      I think your point is still confusing. No one is suggesting replacing Okta with a Yubikey, so whether one chooses Okta to offload support requests or not has no bearing on Yubikeys.
    - ghshephard 3y ago
Nextgrid 3y ago
Yubikey or other browser-based MFA would not have mitigated this attack - the attacker obtained a valid administrative session token from _after_ any MFA would've been completed. MFA or not, this attack would've happened regardless. 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.
- jakobson14 3y ago
  Classic observation about security: any amount of damage is acceptable so long as you're not culpable. All you have to do is get insurance to cover it and/or tell your data-breach'd users to suck it up.
  - doubloon 3y ago
    Assuming your reputation doesn't matter.
    - Muromec 3y ago
      Microsoft literally lost private keys which gave access to all emails to state actors of hostile government. How worse you can get? And nothing happened, they are too big to fail. Everyone who used them as email provider are fine too. Cosmos ether absorbed all the damage.
      - insanitybit 3y ago
        I don't think Okta is comparable to Microsoft, Okta is not too big to fail.
- insanitybit 3y ago
  > MFA or not, this attack would've happened regardless. 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.
paranoidrobot 3y ago
> Can someone explain why people still choose Okta? I personally feel way more comfortable using GSuite as an IDP. 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)"
- insanitybit 3y ago
  Interesting, thank you! I'll note is that GSuite does allow for you to enforce Context Aware Access checks on every SSO, though that does not include a separate 2FA in the traditional sense. 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?
  - 3y ago
CalRobert 3y ago
I use Okta because I used Auth0 years ago and it's a pain to switch.
lopkeny12ko 3y ago
Hardware keys do not prevent session hijacking. If your IT department is empty-headed enough to share active session cookies, you are toast no matter what MFA you use.
- rbut 3y ago
  Tying sessions to the user's IP would help prevent this, but it comes with it's own issues. 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.
  - g_p 3y ago
    I wonder if we will see "zero trust" going full circle, and back to isolating privileged systems from the internet, on the basis of endpoint compromises stealing user session cookies. Just making the authentication and service endpoints inaccessible online significantly reduces the attack complexity.
    - wepple 3y ago
      Except “inaccessible” != “vpn” 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.
    - bayindirh 3y ago
      Actually, not putting administrative or sensitive servers behind a public key + certificate authenticated VPN baffles me. It's very simple and very effective. Also has no usability problems whatsoever.
- DanielHB 3y ago
  to be fair session cookies at least expire at some point. You can't completely hijack the users account with them.
StressedDev 3y ago
Do you have any proof Okta is better or worse than any other solution? Measuring security is very hard. 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).
- wepple 3y ago
  Unless you’re a tiny company, there are legal/regulatory requirements to disclose breaches. 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.
deleted 3y ago
[deleted]
hnlmorg 3y ago
> I hope this spurs them to switch all employees to use Yubikeys for 2FA. Anything less than FIDO2 is really weak. 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.
- dkobia 3y ago
  I’ve used and implemented both. A case can be made for Google Workspace as an IDP if you don’t need all the bells and whistles. It is extremely secure and generally, engineering practices at Google give me much more confidence than Okta. 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.
  - hnlmorg 3y ago
    I've used and implemented both too. You immediately out grow Google Workspace as an IDP whenever you need to do role based access control, like AWS Session Manager for machine access instead of long lived SSH keys. Which is a pretty major shortcoming for an IDP to have. 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.
    - spydum 3y ago
      100%, living this for many years. Google IDP is great for a shop who doesnt need elaborate identity needs. It quickly falls apart when trying to manage an enterprise of any complexity. 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.
mschuster91 3y ago
> I personally feel way more comfortable using GSuite as an IDP. Way too many horror stories about Google suddenly banning accounts here to ever trust them with this kind of responsibility.
- rrdharan 3y ago
  I think there’s an interesting statistical argument here. 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.
  - josephcsible 3y ago
    At least Okta is trying to fix their mistakes. Google doesn't unban wrongfully banned users even when the New York Times publishes an article about an individual case <https://news.ycombinator.com/item?id=32538805 https://news.ycombinator.com/item?id=32538805>.
    - rrdharan 3y ago
      Are you sure they didn't, after that article was published? "Google eventually fixed the problem a few months after this story was published" is not a story the NY Times is that interested in publishing, nor is "it turns out there was a reason this account remained banned" a particularly compelling follow-up story.
  - mschuster91 3y ago
    > Google supports billions of accounts and clearly screws up a few of them (which are noteworthy events precisely because they are so rare). 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.
FinnKuhn 3y ago
When you choose Okta you can be sure they still exist in a few years. With GSuit as an IDP Google might decide that there aren't enough users and kill the product randomly at any point in the future as they have done with Google Domains and countless other examples

latchkey 3y ago

> Can someone explain why people still choose Okta? 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?

ghshephard 3y ago
Who would you recommend as an iDP if not Okta?
- Nextgrid 3y ago
  At this point any self-hosted option would do just as well. Not perfect, but not only it would require a targeted attack to pwn, but if you do end up pwned at least you weren't paying tens of thousands a year for the privilege.
  - ghshephard 3y ago
    I guess I'm curious as to how someone self-hosting would be able to perform their security better than a Tier 1 iDP. It would be the equivalent of trying to self-host email. 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?
    - Nextgrid 3y ago
      > I guess I'm curious as to how someone self-hosting would be able to perform their security better than a Tier 1 iDP. 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).
    - mike_d 3y ago
      > I guess I'm curious as to how someone self-hosting would be able to perform their security better than a Tier 1 iDP. 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.
      - nixgeek 3y ago
        It’s extremely unlikely that every Okta Support employee has this level of access, much less on a persistent ongoing basis. It would be nearly impossible to achieve this level of compliance certification if it were this simple and this broken. https://www.okta.com/trust-page/compliance/ https://www.okta.com/trust-page/compliance/
        Veserv 3y ago
        Why do you have a link: https://www.okta.com/trust-page/compliance/ https://www.okta.com/trust-page/compliance/ 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/ 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 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.
  - thephyber 3y ago
    This is not a serious answer. It’s very unlikely that “any self-hosted option” actually competes with Okta’s IDP solutions, has really decent security, has very good logging features, has behavior analysis features to detect login/session anomalies, and has security staff to respond to those threats quickly. 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.
    - Nextgrid 3y ago
      > has really decent security 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.
    - lopkeny12ko 3y ago
- latchkey 3y ago
  Personally, I'm fine with Google Workspace. IMHO, their track record for corporate auth, over the last what... decade... has been very good.
  - x0x0 3y ago
    Their security record is fantastic, but afaik they don't do what okta does. 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.)
- radlad 3y ago
  I'm partial to Duo SSO because I helped build it (though I haven't worked there for years now.) There's also OneLogin, Jumpcloud, or you can use Google Workspace and I think Azure AD too.
  - vladvasiliu 3y ago
    > 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.

bsder 3y ago

> Can someone explain why people still choose Okta? 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 ...

ghshephard 3y ago
Aren't Yubikeys for MFA and Okta for iDP somewhat orthogonal? A common pattern that I've seen is companies use both.
- insanitybit 3y ago
  Yes, they are unrelated. I brought up Yubikeys just because it was an interesting tidbit in the report.
- bsder 3y ago
  They are, my point (which wasn't very clear) was that somebody needs to do the customer support. 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.
  - insanitybit 3y ago
    I think your point is still confusing. No one is suggesting replacing Okta with a Yubikey, so whether one chooses Okta to offload support requests or not has no bearing on Yubikeys.
  - ghshephard 3y ago

Nextgrid 3y ago

Yubikey or other browser-based MFA would not have mitigated this attack - the attacker obtained a valid administrative session token from _after_ any MFA would've been completed. MFA or not, this attack would've happened regardless. 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.

jakobson14 3y ago
Classic observation about security: any amount of damage is acceptable so long as you're not culpable. All you have to do is get insurance to cover it and/or tell your data-breach'd users to suck it up.
- doubloon 3y ago
  Assuming your reputation doesn't matter.
  - Muromec 3y ago
    Microsoft literally lost private keys which gave access to all emails to state actors of hostile government. How worse you can get? And nothing happened, they are too big to fail. Everyone who used them as email provider are fine too. Cosmos ether absorbed all the damage.
    - insanitybit 3y ago
      I don't think Okta is comparable to Microsoft, Okta is not too big to fail.
insanitybit 3y ago
> MFA or not, this attack would've happened regardless. 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.

paranoidrobot 3y ago

> Can someone explain why people still choose Okta? I personally feel way more comfortable using GSuite as an IDP. 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)"

insanitybit 3y ago
Interesting, thank you! I'll note is that GSuite does allow for you to enforce Context Aware Access checks on every SSO, though that does not include a separate 2FA in the traditional sense. 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?
- 3y ago

CalRobert 3y ago

I use Okta because I used Auth0 years ago and it's a pain to switch.

lopkeny12ko 3y ago

Hardware keys do not prevent session hijacking. If your IT department is empty-headed enough to share active session cookies, you are toast no matter what MFA you use.

rbut 3y ago
Tying sessions to the user's IP would help prevent this, but it comes with it's own issues. 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.
- g_p 3y ago
  I wonder if we will see "zero trust" going full circle, and back to isolating privileged systems from the internet, on the basis of endpoint compromises stealing user session cookies. Just making the authentication and service endpoints inaccessible online significantly reduces the attack complexity.
  - wepple 3y ago
    Except “inaccessible” != “vpn” 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.
  - bayindirh 3y ago
    Actually, not putting administrative or sensitive servers behind a public key + certificate authenticated VPN baffles me. It's very simple and very effective. Also has no usability problems whatsoever.
DanielHB 3y ago
to be fair session cookies at least expire at some point. You can't completely hijack the users account with them.

StressedDev 3y ago

Do you have any proof Okta is better or worse than any other solution? Measuring security is very hard. 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).

wepple 3y ago
Unless you’re a tiny company, there are legal/regulatory requirements to disclose breaches. 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.

deleted 3y ago

[deleted]

hnlmorg 3y ago

> I hope this spurs them to switch all employees to use Yubikeys for 2FA. Anything less than FIDO2 is really weak. 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.

dkobia 3y ago
I’ve used and implemented both. A case can be made for Google Workspace as an IDP if you don’t need all the bells and whistles. It is extremely secure and generally, engineering practices at Google give me much more confidence than Okta. 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.
- hnlmorg 3y ago
  I've used and implemented both too. You immediately out grow Google Workspace as an IDP whenever you need to do role based access control, like AWS Session Manager for machine access instead of long lived SSH keys. Which is a pretty major shortcoming for an IDP to have. 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.
  - spydum 3y ago
    100%, living this for many years. Google IDP is great for a shop who doesnt need elaborate identity needs. It quickly falls apart when trying to manage an enterprise of any complexity. 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.

mschuster91 3y ago

> I personally feel way more comfortable using GSuite as an IDP. Way too many horror stories about Google suddenly banning accounts here to ever trust them with this kind of responsibility.

rrdharan 3y ago
I think there’s an interesting statistical argument here. 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.
- josephcsible 3y ago
  At least Okta is trying to fix their mistakes. Google doesn't unban wrongfully banned users even when the New York Times publishes an article about an individual case <https://news.ycombinator.com/item?id=32538805 https://news.ycombinator.com/item?id=32538805>.
  - rrdharan 3y ago
    Are you sure they didn't, after that article was published? "Google eventually fixed the problem a few months after this story was published" is not a story the NY Times is that interested in publishing, nor is "it turns out there was a reason this account remained banned" a particularly compelling follow-up story.
- mschuster91 3y ago
  > Google supports billions of accounts and clearly screws up a few of them (which are noteworthy events precisely because they are so rare). 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.

FinnKuhn 3y ago

When you choose Okta you can be sure they still exist in a few years. With GSuit as an IDP Google might decide that there aren't enough users and kill the product randomly at any point in the future as they have done with Google Domains and countless other examples