Auth companies are high value targets for hackers. You'd think outsourcing auth is a smart idea because it's difficult to get auth right but otoh you might never have been a target if you hadn't used Okta.
How is it difficult to get web application authentication wrong at this point? It’s super well tread territory. Add your spices, a sprinkle of cookie crumbs, a token here or there, and then 2 hours in the oven and you’re done!
And that’s rolling it entirely by hand. Most web frameworks have middleware that get you going in minutes.
> How is it difficult to get web application authentication wrong at this point?
Adding a log in to an app is no big deal but there are more complex scenarios to consider. Maybe single auth to multiple services, SSO, 2FA, OTP, Oauth, etc.
This is literally the only value add in my mind. When you know it’s not just one simple app. When you know you’ve going to have frontends and backends and server to server tokens and third party and SSO and all the other TLA soup… then it starts to be something where im going “how much time could this save, would this be a good idea”
> How is it difficult to get web application authentication wrong at this point? It’s super well tread territory
Implementing an auth flow to specification isn't trivial at all and that is a problem. Authn and authz get mixed up, people not checking tokens or their expiration, etc pp. There is probably a minefield of security issues here and some of those come to be because it is too complicated.
Sure, there is middleware with sensible service integration, but you still need to do a lot of legwork in any case.
Often it's really about positioning the business to minimize and avoid liability and risk of lawsuits, which is orthogonal to security.
It's not a satisfying answer, but none of this will change until the public feels so strongly about this problem they become single-issue voters electing legislators to pass radically different laws.
Would Okta be one of the things you can use to get authentication right in a few minutes? Aside from the whole Okta themselves don't know how to do this security lark thing that is
Oh, I didn't mean cloud providers, I mean more like when a Fortune 500 company's management decides to shutdown their IT department and outsource the entire function to one of a handful of offshore companies who handle many other important companies as well.
> This is an interesting story since the threat actor targeted MSPs to go after their customers and then carry out their objectives from there. MSPs are pretty common. More and more companies are outsourcing their IT infrastructure, so to target them makes a lot of sense if your goal is to steal intellectual property. It’s sort of like going after the janitor’s key ring which can get you access into many buildings in town.
Remember RSA and OPM? The RSA hack had huge implications for the Department of Defense, and was probably a state-sponsored hack (likely China). Around the same time the Office of Personnel Management (OPM) was hacked. So the state-sponsored hackers got to all the private details of anyone with classified access and clearances (which can be used for blackmail or for answering those strange "Who was your 3rd grade teacher?" auth questions to get past an identity test), and simultaneously could hack the rotating MFA codes from RSA.
Auth companies will always be a high value target for state-sponsored espionage.
As a rule of thumb, if you value the privacy or security of your users, never ever use services such as Okta. Product that rely on them are guaranteed to suffer from breaches. Told my clients that and i was right. It is a matter if time until the next breach.
If the org has a software development team, there's really no reason not to roll your own. As stated previously, this is a pretty well solved and well documented problem. A lot of development teams outsource this under the idea that authx is not their core competency, but I'd argue protecting customer data ought to be among every development org's core competency, otherwise they;re asking for trouble.
If you're talking about orgs that don't have a dev team and buy everything off the shelf / through SaaS... well, this is unfortunately part of the risk those orgs run. If you're manufacturing and shipping widgets in boxes, and your box supplier starts using cheaper materials that don't hold up to shipping, the only option is to switch box providers. Same here - if you're org relies on an IAM tool to allow employees to log into SaaS or other hosted software platforms and the IAM leaks data, the only real options are to switch providers or work with the existing provider to fix the damage.
Your solution of "write your own" is fraught with so many problems.
Why not write your own OS? Then you can control the vulns!
Why not design your own hardware? You can secure the hardware comms channels better.
Why not invent your own coding language? You can ensure it's written with zero vulns.
Why not invent a new base-30 numbering system? With out extra efforts, they can't even read your excel spreadsheets!
Your solution works in a select few companies that have monster dev farms, but everyone else cannot implement this and it's silly to tout it as a solution.
There are zero perfect solutions.
The way we do this in the real world, is patch, read up on vulns that might affect us, monitor, control access, and audit.
It's still not perfect, since nothing is, but in 30+ years of managing Healthcare IT and being senior technical, I've had exactly 1 breach and she did it with pencil and paper, at an HIS workstation, who's job is to look at many medical records, daily.
