

Production AWS keys on GitHub - jxf
https://github.com/search?q=production+SECRET_ACCESS_KEY%3A+%22A&type=Code&ref=searchresults

======
Lockyy
I did a quick check and found a few people with their Rails App's secret token
on display in config/initialisers/secret_token.rb. I guess most people reading
this will already be aware but it's in the same vein as the AWS keys problem
linked. Make sure this stuff hasn't been left in your public repos.

------
needcaffeine
If you use EC2, you can use IAM roles and your server can fetch temporary
credentials from AWS. There's no need for your application to even know your
AWS credentials.

Read more: [http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-
roles...](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-
amazon-ec2.html)

------
oakwhiz
I recommend putting your app's API keys into environment variables instead of
configuration files for this reason.

~~~
rrosen326
Could you go through this process? I just did something where I used a file
that was outside my repo but I knew there must be a best practice that I just
didn't know about. What is it?

~~~
spiralganglion
The implementation varies depending on your framework and personal
preferences.

For development, I usually use a file named .env in the same directory as my
project, and then do whatever I can to guarantee that this file won't be added
to my repo (or other public places). I use .gitignore_global to exclude .env
files, for instance.

For production, if you're running your app on a service like Heroku, they have
commands you can execute to securely set environment variables on their server
(since they discourage accessing the filesystem to load the .env file).

For Rails, take a look at the dotenv-rails gem. It's pretty convenient.
[https://github.com/bkeepers/dotenv](https://github.com/bkeepers/dotenv)

Here is the Heroku article on the topic (might not apply directly to your
situation, but the principal is key):
[https://devcenter.heroku.com/articles/config-
vars](https://devcenter.heroku.com/articles/config-vars)

~~~
a_bonobo
Rails 4.1 includes something similar to dotenv:

[https://github.com/rails/rails/blob/master/guides/source/4_1...](https://github.com/rails/rails/blob/master/guides/source/4_1_release_notes.md)

A secrets.yml which is globally accessible via Rails.application.secrets, and
should be in the default .gitignore from Github for Rails projects

------
sahat
I was charged over $1696.00 in AWS Usage fees for putting my production AWS
keys on GitHub. So think twice before you put any production keys out there,
for the whole world to see. UPDATE: As spydertennis mentioned, I also had 15
Double XL EC2 instances running in multiple regions.

~~~
MasterScrat
Do you have any idea what they were doing? mining coins?!

------
MasterScrat
It would be interesting to have an application that Googles regularly this
kind of sensitive information and tells you if it showed up somewhere public.

Of course it would need a full list of your sensitive keys and password, which
it practice would be quite dangerous...

------
MasterScrat
What exactly happens when someone takes advantage of these keys?

Is it considered as "hacking", ie is the offender's Amazon account terminated?
or is it "fair" in the sense that those credentials were willingly made
public?

------
mrThe
[https://github.com/search?p=1&q=Stripe.api_key+%22sk_live%22...](https://github.com/search?p=1&q=Stripe.api_key+%22sk_live%22&ref=searchresults&type=Code)
#facepalm

------
spydertennis
I got hacked a month ago because of this mistake. Someone initiated 15 heavy
duty aws instances on my account. Luckily aws support noticed the huge
increase in billing and called me to confirm. Now my github is private haha.

~~~
testaccount4
> Now my github is private

That is not the solution. You're supposed to isolate secrets from the code
repository.

------
catwf
I did this once in a gist by mistake - meant to remove them before submitting
it. Luckily someone spotted it and let me know so I could kill the access key.

