Hacker News Reader

Comment by remram | Hacker News Reader

It is really silly that the only easy way to report a leaked secret from most services is to push it to GitHub. I don't understand how the industry failed to standardize any secret-reporting scheme.

View on HN

This is a misunderstanding of how standards come about. Standards don't come about because someone theorizes pushing the envelope and then everyone gets together to form a convention to decide the best way to push the envelope.

Standards describe existing behaviour of value that benefits from a single interface. For that, the behaviour has to be first demonstrated. That's how the envelope is pushed. You make an implementation, then you show how that solves something worthwhile, and then if there are multiple implementations that could benefit from a single interface, you do that.

Totally agree, and I do hope that at some point this will be standardised.

Ideally you’d have an endpoint that returns a set of patterns to check for and a way to submit a set of tokens for checking, along with some kind of context. It would probably be something like what GitHub requires[1].

Unfortunately that has somewhat limited value when GitHub can do most of the legwork for you, and as the de-facto place to publish code the majority of “accidental secrets exposed in code” are leaked there.

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

At the very least I would think GitLab might be interested in providing a similar feature.

That's right, the behavior exist, on GitHub. Multiple services, including open-source ones like PyPI, integrated with it because they find it worthwhile. Yet it remains impossible for anyone to use it except through GitHub.

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.

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