Amazon AWS vs GitHub – “Suspected Unauthorized Activity” | Hacker News Reader

Amazon AWS vs GitHub – “Suspected Unauthorized Activity”

pivotedreality.wordpress.com

10 pointsarijitraja7 comments

"When we moved our Github repository from private to public (as the co-founder was leaving and I had to share it with some other prospective co-founders), the AWS keys were all in the open for everyone under the sky to play with. Doing some online search, I figured out we were not the only ones. It’s apparently quite a common mistake developers do."

Yes, Yes and Yes. I have made a similar mistake once on Github for a personal project, I realized my mistake and immediately updated the file and did a new commit. Guess what ? Even after committing a new version of the file, you can always check the "History" of the file which will show you the version with the credentials. My only option was to delete that config file completely.

Having said this, it can be scary if you leave your credentials on sites like Github. I work a lot with Python Flask framework and oen of the commonly used extension is Flask-Mail to send emails. Guess what ? A lot of developers are leaving their email credentials in the open and being a flask dev, I know that most of the time, it is MAIL_PASSWORD variable usually in a config file. Knowing this, I can just do a code search on github with keyword MAIL_PASSWORD. You figure out the rest.

Even after deleting the file, you can still find it in git's history, it's just very slightly less easily accessible through github's web interface. The whole point of git is that nothing ever actually gets deleted.

You need to do a reset of any credentials that end up in public, ever.

It's really a PITA to have to scrub the repo before going public with it, but that's what you have to do or risk security leaks.

Another reason to always always always setup AWS billing alerts: https://aws.amazon.com/about-aws/whats-new/2012/05/10/announ...

This can POST to a URL, SMS you, email you etc. Set a $ threshold you are comfortable with and enable this right away.

Absolutely, spot on. This is the best way to avoid this situation. Thanks, I will put this in the blog somewhere.

The best practice with AWS API keys is to ONLY EVER use IAM (Identity and Access Management). There is nowadays zero reason to even generate account-level API keys. With IAM, you can create separate keys with separate abilities, down to the API call, even locked down to certain IP addresses. Even on my personal account I have separate IAM "users", e.g. one for each S3 bucket that I use for backups, locked down to the minimum access needed for the backup software to work.

I've heard the billing alerts elsewhere.

Seems like AWS did a great job of making things right in the end.

Reply on news.ycombinator.com