It’s actually comical that Cloudflare is trying to blame Okta for this. A Cloudflare employee uploaded secrets to Okta’s support tool. That is what caused the breach.
'Malicious Okta employee' who already has privileged access in the systems the customer has chosen to outsource their auth to?
If Okta employee is a high priority threat model... then the customer is better off not using Okta.
Not that it shouldn't be considered, but if Okta top-to-bottom penetration is expected and accepted, then that's taking Zero Trust to a whole new length.
It's literally a policy from Okta to investigate issues, which isn't Cloudflare's fault. The tool from Okta got compromised and all clients that needed support from Okta could/have been damaged as well.
Additionally, it was Cloudflare that SAW something was off and notified Okta. Cloudflare didn't get breached at all.
> The root cause is that Okta got compromised.
It's even suprising that Cloudflare's policies are so good in detection that they detected this at all, before Okta.
It's the same type of session replay attack (likely HAR) discussed in the original article, no?
It seems a reasonable expectation to assume that anything sent to Okta support isn't instantly available to attackers.
So, yes, valid session tokens were dumb. But also yes, Okta fucked up here too.