5 ms·
I wouldn’t recommend this. What if GitHub’s token scanning service went down. Ideally GitHub should expose an universal token revocation endpoint. Alternatively
by securesaml 9mo ago
I wouldn’t recommend this. What if GitHub’s token scanning service went down. Ideally GitHub should expose an universal token revocation endpoint.
Alternatively do this in a private repo and enable token revocation (if it exists)
- jychang 9mo agoYou're revoking the attacker's key (that they're using to upload the docs to their own account), this is probably the best option available. Obviously you have better methods to revoke your own keys.
- securesaml 9mo agoit is less of a problem for revoking attacker's keys (but maybe it has access to victim's contents?). agreed it shouldn't be used to revoke non-malicious/your own keys
- nebezb 9mo agoThe poster you originally replied to is suggesting this for revoking the attackers keys. Not for revocation of their own keys…
- securesaml 9mo agothere's still some risk of publishing an attacker's key. For example, what if the attacker's key had access to sensitive user data?
- avarun 9mo ago[flagged]
- throwawaysleep 9mo agoAll the more reason to nuke the key ASAP, no?
- deleted 9mo ago[deleted]
- eru 9mo ago> What if GitHub’s token scanning service went down. If it's a secret gist, you only exposed the attacker's key to github, but not to the wider public?
- OJFord 9mo agoThey mean it went down as in stopped working, had some outage; so you've tried to use it as a token revocation service, but it doesn't work (or not as quickly as you expect).