Hacker News Reader

Comment by mcspiff | Hacker News Reader

I mean yes — that’s the point. If untrusted parties have access to your keys, it’s already game over. You’ve lost. Disabling them is the nicest thing an attacker can do for you.

View on HN

Not really: it depends on the permissions assigned to the keys.

I wouldn’t like to wake up to an email that says “your key has been disabled because someone anonymously reported is as leaked, sorry if this has broken your entire system”.

What do you do with this, outside of obviously quarantining and/or disabling the key? How was it leaked? What’s the context?

If rogue party has access to the key, they can do a lot more damage.

Indeed, so you’re building all this tooling and complexity and introducing more issues for the very small intersection of people that:

1. Are not malicious

2. Have access to a key

3. Are unable or unwilling to commit it to GitHub

It would be great if this stuff was public and available without a central authority. But after working on it for a while it seems like a fairly good compromise.

There’s already an entire pipeline that handles a key being compromised when it is found on GitHub. All the “tooling and complexity” you need is a simple HTML form to ask for a key and where you found it, and some server-side code to trigger the same pipeline when somebody submits the form.

There are three issues with the use of GitHub here:

1. Not everybody knows that AWS will invalidate tokens committed into a public GitHub repository.

2. There is a window (67 seconds according to OP) in which the compromised token is public but working. For the “small intersection of people”, you could bring it down to 0.

3. GitHub protects GitHub keys, and apparently AWS keys, but does it protect Azure keys? Or GCP keys?

GitHub secret scanning is a product they allow partners to take advantage of: https://docs.github.com/en/code-security/secret-scanning/abo...

https://docs.github.com/en/code-security/secret-scanning/sec...

Not necessarily people but systems. Your code hosting platform, your mailing-list host, your chat app, ... are all examples of systems who are hopefully not malicious and could easily add this auto-revoke-publicly-leaked-secret feature, if it was a simple consistent scheme like an HTTP DELETE to a URL.

Reply on news.ycombinator.com