https://blog.1password.com/okta-incident/
Original Incident Report: https://blog.1password.com/files/okta-incident/okta-incident...
Original Incident Report: https://blog.1password.com/files/okta-incident/okta-incident...
> A member of the IT team was engaged with Okta support, and at their request, created a HAR file from the Chrome Dev Tools and uploaded it to the Okta Support Portal. This HAR file contains a record of all traffic between the browser and the Okta servers, including sensitive information such as session cookies. In the early morning hours of Friday, Sept. 29th, an unknown actor used the same Okta session that was used to create the HAR file to access the Okta administrative portal
Like your bank tells you, don't give the support person your password.
Based on the activity logs provided by Okta for their Support Portal, the HAR file had not been accessed by their support engineer until after the events of the incidenthow can "the industry" trust okta?!
Sure, but was the user aware what the HAR-file actually contained?
At the least all active sessions should be cleared after sharing something like that. But that hinges on you knowing about it. Support should also make it mandatory/automatic.
The "Copy as cURL" feature has the same issue. As does highlighting and copying request/response headers to the clipboard.
However, less sensitive data should ideally remain easily transferred, without much effort on the part of the user.
HAR files are a debug tool. If I have to debug a problem with a webservice, I require them to contain all the information that was sent/received by the browser. The browser arbitrarily deciding to delete part of that information, would make it worthless to me as a debug tool.
Browsers could add even more nag screens between the user and the tools, but those have zero effect once the assumption "I'm talking to a person from the hoster" is established. It's the old "put on a safety vest and a hardhat and you can walk anywhere" hack that only training can protect you from. And even with the best training, you'll never reach 100%. That's why you need many tiers of your operation is as sensitive as selling a trust store.
It's well possible that 1Password are still far from being breached thanks to tiers, but it's interesting to see even people working full-time on the conflict between authentication and convenience struggle with that balancing act.
But having that cookie, or any other data from my dev environment, after I manage to recreate the reported bug internally, has often helped me debug problems.
The point here is, debug tools that delete information are less useful. Worst case, they are useless.
Yes, such tools can be problematic. With great power comes great responsability. But I rather have powerful tools with a big 'ol warning sign, than useless tools.
Sure, but they uploaded it to the okta portal, not to any random support person. Most users would expect that people getting files from the company portal would be cleared to see confidential and sensitive stuff.
Obviously not passwords, but still ...