Hacker News Reader

Comment by orf | Hacker News Reader

How would this work in practice? In order to effectively filter for tokens you need a set of pretty specific regular expressions.

These specific expressions may contain non-public information about the structure of the tokens.

But imagine we live in a world where companies are OK with exposing this information publicly and investing time in keeping the expressions up to date.

Now what? How do you report it to services whilst stopping abuse? Like, if the code isn’t public then all this is an endpoint to let anyone to disable another users (or companies) key without any explanation or recourse.

Pushing to GitHub is actually quite an elegant solution to these issues I think, even if I do think it is a bit too centralized.

View on HN

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.

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.

I'd like a standardized token syntax that contains a domain (e.g. `secret:example.com/token`) Then you could fetch an url like `https://example.com/.well-known/secret-leak` which returns machine readable information about how to report a leaked token.

I keep arguing for this too! [1][2][3]

A few cycles ago [4] sudhirj pointed out that you could just use an actual URL as your secret key and have that be the URL you visit to revoke it, and I think that is genius.

[1] https://news.ycombinator.com/item?id=34009442

[2] https://news.ycombinator.com/item?id=31335081

[3] https://news.ycombinator.com/item?id=25979908

[4] https://news.ycombinator.com/item?id=28299624

Reply on news.ycombinator.com