Hacker News Reader

Comment by shawabawa3 | Hacker News Reader

It is customer fault.

However it should be pretty easy for them to set up a script to search github for this kind of stuff and automatically invalidate keys

View on HN

At my work one of my coworkers accidentally put a secret token in a GitHub issue. Couple hours later he got an email from the sysadmin at the parent company saying his token finding script went off. He probably wouldn't have noticed for a long while if that script wasn't running.

Wouldn't the token-finding script be even more of a risk?

If the token is XYZ and the script is searching https://github.com/search?utf8=%E2%9C%93&q=XYZ&type=Commits&...:

1. It's sharing the token with GitHub.

2. It's embedding the token as query-string parameter in a GET request, which is much more likely to be logged (than sending it as data in a POST request), and more likely to be available to less-privileged/less-trusted staff.

3. If the request is sent to a non-HTTPS endpoint, the query can be MITMd, revealing the token.

I'd be very wary of setting up a token-finding script, it feels like it adds more risk than it saves.

It was a pattern based script, all the tokens had the same length.

You can scrape the issues without exposing the token. You could probably do it by just subscribing to all of them and parsing emails. No one(especially in security) should be using a third party search to match sensitive data. It's like searching Google for your social security number.

You just search that some token was uploaded by your people, not specifically yours.

Maybe they search the tokens public key and not the token itself. Then if the public key is found, then they download the repo and do scanning for the private key.

A group at BigCorp Inc. was sharing a tool they'd written to ThirdParty Ltd. As part of this, they transferred documentation, including how to configure the tool. Including an example. With a real AWS key. For a dev too, so the key had no restrictions.

And this would be a cool feature from github too. A link mentioning "we found something in your code that looks like a secret, please know people will use it."

They do this for all of their own API keys already. They not only notify you but instantly invalidate a key pushed to a public repo.

Annoyingly there is no way to turn it off even when you explicitly want to share an API key knowingly. But i'm more than fine with needing to "obfuscate" an API key or manage secrets correctly knowing it saves TONS of people.

Why would you ever want to share a valid Github API key publicly?

Continuous development, e.g. Jenkins? (Please don’t do this)

Why not?

Out of curiosity, why not a deploy user? https://developer.github.com/guides/managing-deploy-keys/

It's been a while, but IIRC it was a key with no permissions used on a CI server to get around github's API usage limits.

It probably wasn't the best idea, but it was the only "secret" needed in the whole project and I didn't want to maintain a way of managing secrets in a public project for a pointless key.

In the end I did just that, and looking back it was the better choice, but at the time it was annoying.

"... used ... to get around github's API usage limits."

I wonder why they'd want to invalidate that. :)

Split it to parts and concatenate it, then?

$key = "BAAD" + "F00D" + "CAFE" + "BABE";

> But i'm more than fine with needing to "obfuscate" an API key or manage secrets correctly

GitLab has this: https://docs.gitlab.com/ee/push_rules/push_rules.html#preven... (enterprise edition, admittedly)

1) Search for common pattern where the key can be stored

2) Search if found keys are actual valid keys

3) Expire key, send explanatory email, issue new key

(I think that's what AWS does)

Heroku's official Python template include `.env` in the repo: https://github.com/heroku/python-getting-started https://github.com/heroku/heroku-django-template (Although, to be fair, they do include `.env` in the `.gitignore` file.)

Reply on news.ycombinator.com