4 ms·

What a weird and potentially misleading statement. * They stress that the compromised account wasn't able to "create/delete users or download customer database

What a weird and potentially misleading statement. * They stress that the compromised account wasn't able to "create/delete users or download customer databases", but not what it could do. Could it change passwords of accounts and add 2fa methods, allowing them to take over rarely/never accessed users? Disable 2fa? Change account permissions? List user accounts and metadata to build a user account DB for further attacks? The application is named "SuperUser" ... * It took public posting of a screenshot to trigger an audit of access logs, two months after the compromise was detected! * "Only" 2.5% of customers were accessed. That's supposed to be a good thing? Those were certainly the most valuable targets. * Concludes everything is just fine and no corrective actions need to be taken, but affected customers might want to do their own analysis... Huh? Sounds a lot like damage control.

Cthulhu_ 5y ago
> Sounds a lot like damage control. Yup, the first line made my hackles stand up; surely there's no security incidents raised for a user-invoked operation like adding MFA to a subcontractor's account? Audit logging is fine, but that's a user-initiated operation that already requires (if they have their shit in order) username, password, existing MFA if applicable, and an e-mail confirmation. To the user. It's all by the user. Does Github raise the alarms if I change something in my MFA settings?
- throw1230 5y ago
  It looks like it's got flagged because the key was added from a new location
- ensignavenger 5y ago
  The MFA tokens you use on Github are provided by you. The MFA tokens used by Okta employees/contractors may be provided by Okta, therefore Okta may know the token that was attempted to be added was not provided by them, and that is why it may have been blocked and a security alert generated. GitHub can't do that unless they are the only ones providing the tokens to their users.

Cthulhu_ 5y ago

> Sounds a lot like damage control. Yup, the first line made my hackles stand up; surely there's no security incidents raised for a user-invoked operation like adding MFA to a subcontractor's account? Audit logging is fine, but that's a user-initiated operation that already requires (if they have their shit in order) username, password, existing MFA if applicable, and an e-mail confirmation. To the user. It's all by the user. Does Github raise the alarms if I change something in my MFA settings?

throw1230 5y ago
It looks like it's got flagged because the key was added from a new location
ensignavenger 5y ago
The MFA tokens you use on Github are provided by you. The MFA tokens used by Okta employees/contractors may be provided by Okta, therefore Okta may know the token that was attempted to be added was not provided by them, and that is why it may have been blocked and a security alert generated. GitHub can't do that unless they are the only ones providing the tokens to their users.