Hacker News Reader

Comment by smsm42 | Hacker News Reader

If the criminals can create a bot to scan for AWS keys, I wonder if github can't create a plugin to detect the same and warn the committer or maybe limit access to this data to original committer only. It won't be 100% but I bet the bots aren't 100% either, so if it covers most of the cases it would still be useful.

Or maybe just have a script on local github pre-commit hook?

View on HN

This happened to me and I was immediately emailed by AWS with an auto-generated support case: "Your AWS account ### is compromised". The emails outlined next steps like: check for unauthorized usage, delete/rotate the key, etc.

I was very surprised/impressed.

> It won't be 100% but I bet the bots aren't 100% either

Bots having tons of false positives doesn't really matter (except to the bot maker, maybe). But GitHub having tons of false positives means customers get annoyed by false alerts, locked data, whatever.

I don't think people will be upset to get an "WARNING: You might have committed a secret" if it's a negative.

You might be right if it really is a ton, but then you work on your algorithm. I think the problem is so big that there really do need to be warnings for these kind of issues.

Removing such suspicious actions from public /events API and other APIs would probably have minimal effect but have the bots that feed from those not see it. Just one of the possibilities :)

I don't think it's github's responsibility to prevent you from shooting yourself in the foot.

It is thinking like this that leads companies from being awesome. I've known a couple people in real life that this has happened to. It is stupid and wasteful.

It's not an obligation, but neither is running a free git repository :) It would be a nice help though. One that can save some people $2k - not many software features have this kind of immediate impact :)

Nobody said it was their responsibility. If adding an optional feature that prevents you from shooting yourself in the foot makes people like github more, maybe it's worth it to them. "Responsibility" has nothing to do with it.

Would have to make it an option, because we check in various AWS keys into private repos.

Also how do you differentiate an AWS root key (bad) vs an IAM Key (good)?

Maybe you should rethink your policy either way.

In my circles, at least, it's standard practice to use environment variables.

But I would think clearly it'd be an option.

> Maybe you should rethink your policy either way.

Do you have articles discussing the cons of AWS keys in private repos?

We deploy our systems on vanilla EC2 instances, which are configured by using a server orchestration system (Ansible). So for any env variables to get set, we'd have to put them in config scripts, which are currently checked into github.

To make it clear, we only check in our IAM keys that are AWS service specific, like SES.

Well, no, but it would be a nice-to-have.

Reply on news.ycombinator.com