
Secrets in the code - geetarista
https://github.com/blog/1390-secrets-in-the-code
======
h2s
I think one of the common security issues strongly hinted at by this blog post
is Rails' secret_token.rb security debacle[1]. Basically Rails has a file
called secret_token.rb containing what should be a complete secret, but the
default Rails .gitignore doesn't ignore it and as far as I've experienced,
none of the main introductory Rails tutorials mention it. So a lot of people
accidentally publicise it on GitHub, and this facilitates exploits of some of
the recent Rails vulnerabilities.

[1] [http://biggestfool.tumblr.com/post/24049554541/reminder-
secr...](http://biggestfool.tumblr.com/post/24049554541/reminder-secret-token-
rb-is-named-so-for-a-reason)

~~~
josephlord
I've made this mistake although fortunately with an unpublished app to a
private repo but I'd still like to fix it.

My ideal solution will probably be to:

1) Look for an environment variable

2) Look for a file in the project config or root named: secret-git-ignore-
this-file (or something similar)

3) If it fails to find either of then generate a new secret with secure_rand

4) If running on Heroku write it to the environment variable (I think this can
be done and should persist although I'll need to check the documentation).

5) Otherwise write it to the secret-git-ignore-this-file

If/when I get round to this I'll probably try to put it on Github for others
to use although if anyone knows of any good published solutions that do
something like this that would be even better.

~~~
Xion
Even if #4 is possible (I rather doubt it), you shouldn't really do that. It
breaks the barrier between code and configuration by making the former
influence the latter.

Such approach is simply not scalable. I don't know what secret_token.rb is (I
do Python) but if it's anything like an HMAC key for encrypting your session
cookies, your app will break once deployed to more than one frontend because
the cookies will suddenly become tied to specific dyno.

~~~
thisone
4 is possible.

You run the app locally using foreman, store your local variables in a .env
file, and add that to your gitignore.

For your heroku running app, you use the toolbelt to add env variables.

[https://devcenter.heroku.com/articles/config-vars#local-
setu...](https://devcenter.heroku.com/articles/config-vars#local-setup)

[https://devcenter.heroku.com/articles/config-vars#setting-
up...](https://devcenter.heroku.com/articles/config-vars#setting-up-config-
vars-for-a-deployed-application)

------
malexw
I've had this issue affect me once or twice in the past (fortunately only with
debugging settings, not secret keys). The solution for me was to create a pre-
commit script for git that looks through the diff of my commit for a special
token, and aborts the commit if the token was found. Now when I make a change
to a bit of code that shouldn't be committed, I'll throw in the token as an
additional sanity check.

For someone who had never done any git scripting before, I was surprised at
how easy it was to put together - just 9 lines of bash for the simplest thing
that could possibly work: <https://gist.github.com/4513374>

------
serf
but it is hilarious to read zsh logs.

~~~
burke
For the lazy:
[https://github.com/search?q=extension%3Azsh_history&type...](https://github.com/search?q=extension%3Azsh_history&type=Code&ref=advsearch&l=)

~~~
Tuna-Fish
More specifically, on r/netsec someone who used that search found a
.zsh_history file that contained mplayer invocations with file names that
imply child porn. This caused quite a stir.

