Hacker News Reader

Comment by Nextgrid | Hacker News Reader

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.

View on HN

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.

Assuming your reputation doesn't matter.

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.

I don't think Okta is comparable to Microsoft, Okta is not too big to fail.

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

> the attacker obtained a valid administrative session token from _after_ any MFA would've been completed

But you can lock session tokens to specific IPs or user agents. I've implemented similar in the past for a B2B admin-panel, and whilst there were the occasional false positive with browsers updating in the middle of a session (incrementing the user agents version number) and people's IP changing if they switched networks (or in one instance, a badly configured office network that randomly routed through 2 proxy servers with different outbound IP addresses) which then made it demand MFA again, it was fairly rare and didn't attract too many complaints.

FIDO2 wouldn't have helped the customers' accounts since valid session tokens were obtained. However, hardware tokens for the Okta customer service accounts may have blocked the threat actor's access depending on the (undisclosed) method of attack.

Actually if browser used plain old smartcard cert off yubikey for client cert auth it would be prevented, but that's too PITA to use.

Well, if implemented right. Techically every ssl connection would carry user's identity so cookie with that identity wouldn't even be required

https://learn.microsoft.com/en-us/windows-server/security/to...

Sounds like token binding.

Reply on news.ycombinator.com