Securing the Rails session secret • Hacker News Board

Re: Securing the Rails session secret

#11

Post by MattRogish » Fri, Jan 04, 2013, 5:48 PM UTC

tptacek wrote: post #9

MattRogish wrote: post #7

We use Heroku and PaaS environment variables, with a default value if you're running in development/test mode, e.g. if Rails.env.production? && ENV['SECRET_TOKEN'].blank? raise 'SECRET_TOKEN environment variable must be set!' end secret_token = ENV['SECRET_TOKEN'] || 'safdasfjlkj...'

Make sure your session secret is a long random string (it might be tempting, if you're passing it in through the environment, to make it shorter or readable). It's an HMAC key that anyone who can get a session from your application can dictionary.

Oh yes. It's probably ridiculously long (I think 256 chars, letters numbers special etc) :)

Re: Securing the Rails session secret

#12

Post by LaGrange » Fri, Jan 04, 2013, 6:29 PM UTC

I like the solution I stole from rstat.us: you have an off-repository location for the token If there's none:

* on production you crash,

* on dev, you autogenerate one and save it to a config file that's possibly dev-only,

* during automated tests you just autogenerate something and live with it.

Here's the nice replacement for secret_token.rb: https://github.com/hotsh/rstat.us/blob/master/config/initial...

Re: Securing the Rails session secret

#13

Post by Corrado » Fri, Jan 04, 2013, 7:20 PM UTC

thibaut_barrere wrote: post #5

Sharing a few thoughts: - having a per-machine key auto-generated will not work properly with PaaS (such as Heroku, DotCloud etc), especially if you have N machines behind a load-balancer. In that case they need to share the key, so using a Heroku production variable or similar will have to be used instead. - I believe we (Rails users) should at least move away from having a hard-coded key in the source by default, a…

Agreed! We've already had and solved this problem with various config settings (i.e. database.yml). Why is there a big debate about this? The way I see it, the Rails community is already used to dealing with database.yml so it makes sense to extend this same pattern to other sensitive configurations.