Live data from Hacker News

Why Deleting Sensitive Information from GitHub Doesn't Save You

jordan-wright.github.io

71–80 of 91 posts

Re: Why Deleting Sensitive Information from GitHub Doesn't Save You

#71

> In this post, I’m going to show exactly how hackers instantly harvest information committed to public Github repositories... A few days ago I published my blog to GitHub, with my MailGun API key in the config file (stupid mistake, I know). In less than 12 hours, spammers had harvested the key AND sent a few thousand emails with my account, using my entire monthly limit. Thankfully I was using the free MailGun accou…

I had a similar but less pleasant experience. I had decided to opensource an old side project of mine, that gets a good amount of users daily. And by that, it was just initially to make the repo public. But I had totally forgot about the mail server keys- this was a paid mail server, so you can imagine my disbelief when I get an email of a $1000 bill and a complaint saying that I had sent upwards of 250k emails with…

To be fair to you, part of being a paid mail provider is dealing with this kind of stuff on the daily, I am surprised they didnt stop it WAY before it hit that send count.

Re: Why Deleting Sensitive Information from GitHub Doesn't Save You

#72
First time I tried to use github I uploaded my gmail password which I was using to send myself an email when something failed. I figured that there would be bots that would scoop up that information right away. Luckily I realized what I had done before people could get into my gmail.

Re: Why Deleting Sensitive Information from GitHub Doesn't Save You

#73
post #56

Earlier quoted context omitted.

If you're feeling fancy, you can use my library to asymmetrically encrypt credentials using RSA keys [1]. [1]: https://github.com/jacobgreenleaf/greybox

The fact that this uses RSA directly seriously worries me. Is the RSA library using OAEP? Does it properly blind it's inputs before signing? What's the modulus? Does key generation avoid using weak keys? Maybe the answer to these questions and others is satisfactory, but getting RSA catastrophically wrong is easy enough that I'm extremely skeptical that a library will get it right. Honestly, I'd be infinitely more li…

If you read the code it's obvious that it uses a Python named 'rsa' which implements PKCS#1

Re: Why Deleting Sensitive Information from GitHub Doesn't Save You

#74
post #24

There's a fairly straight forward pattern for keeping sensitive credentials out of github. It comes straight from http://12factor.net/config store configuration data in the environment. What I do for most projects is keep the tree containing the working directory in a directory that has some other items that don't belong on github (like the project brief, my emacs bookmarks file, random notes related to the project e…

Those who use ansible can use ansible-vault to encrypt credentials (http://docs.ansible.com/playbooks_vault.html) and chef has encrypted data bags (https://docs.chef.io/chef/essentials_data_bags.html). Really, any raw config shouldn't ever make it in the repo anyway, other than sample.conf.

Re: Why Deleting Sensitive Information from GitHub Doesn't Save You

#76
post #75

TLDR: It won't save you because people could have copied the information before you deleted it. Duh?

TL;DR: github makes it easy to notice when events have occured, so easy that you can write tools to copy information as soon as it hits.

This is a bit more nuanced than your summary because GH makes it easy. Without the events API, you would have to poll the various repos to find out if changes happened

Furthermore, the existence of GHTorrent demonstrates the ease with which this information can be harvested

Re: Why Deleting Sensitive Information from GitHub Doesn't Save You

#77

Earlier quoted context omitted.

I had a similar but less pleasant experience. I had decided to opensource an old side project of mine, that gets a good amount of users daily. And by that, it was just initially to make the repo public. But I had totally forgot about the mail server keys- this was a paid mail server, so you can imagine my disbelief when I get an email of a $1000 bill and a complaint saying that I had sent upwards of 250k emails with…

I'm curious. Did they excuse the bill or was this a $1000 lesson?

Yup, it was credited as they checked the IPs of the server that was sending those requests. It was clear that it was malicious, also I had been a long time customer.

Re: Why Deleting Sensitive Information from GitHub Doesn't Save You

#78
post #71

Earlier quoted context omitted.

I had a similar but less pleasant experience. I had decided to opensource an old side project of mine, that gets a good amount of users daily. And by that, it was just initially to make the repo public. But I had totally forgot about the mail server keys- this was a paid mail server, so you can imagine my disbelief when I get an email of a $1000 bill and a complaint saying that I had sent upwards of 250k emails with…

To be fair to you, part of being a paid mail provider is dealing with this kind of stuff on the daily, I am surprised they didnt stop it WAY before it hit that send count.

Yeah, its weird because I was subscribed to a much lower email plan anyway. Somehow, that gave them the okay to auto-upgrade my account and 'release the hounds.'

Also, this was a reputable email provider that many of you know of (i believe it went thru one of the incubators).

Re: Why Deleting Sensitive Information from GitHub Doesn't Save You

#79

Earlier quoted context omitted.

My point in my OP was to not play the game of catch-up, don't even pitch in your vuln strs. Any time you want to show me a 100% future-proof algorithm for sensitive-info detection that works across any/all code on github, I'd be happy to toss my hat in and say, "I was wrong", until then, people will never ever beat 0days they don't know exist (0day being more than just a SW exploit). Just do.not.commit.sensitive.info…

You're straw-manning. The suggestion was that it would be useful to have a best-effort system to try to detect when people make mistakes. I don't think there's any suggestion that it should be something that people rely on, or that the system should or could be perfect - merely that it would be useful.

I wouldn't go so far as saying I was creating a straw-man argument. My point is just that relying on other people to take care of security for you ends up with an "eh" attitude in the long-run, and self-education is more important.

Yes, Github can/should help, but developers should not think they're owed it just because they constantly check in sensitive info to a website, that's all.

Post reply on HN