Hacker News Reader

Comment by h2s | Hacker News Reader

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...

View on HN

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.

I wrote a gem that I've used to help with the secret key problem in the past. It's called Envious: https://github.com/RyanNielson/envious

Basically it adds a yml file, that is added to .gitignore, with configuration settings that get added to ENV. It can even send your environment variables to Heroku using a Rake task. There are some examples on the page. You can use it to have different secret keys depending on your Rails environment as well.

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.

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#setting-up...

Yes it is for the session cookies. You are right that it won't work well for multiple frontend servers but that isn't going to be an issue for this current app. If it is written to the Heroku environment it should be available to all dynes I think.

I can rethink the solution if I need scale. I don't really think of it as config as I don't care what the value is just that it is consistent on any given host.

Reply on news.ycombinator.com