Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Better Way to Manage the Rails Secret Token

daniel.fone.net.nz

Post reply on HN
Print view View original

21–30 of 60 posts

Re: A Better Way to Manage the Rails Secret Token

#21

Post by ricardobeat »

ceol wrote: post #18

For Python website projects, I enforce the creation of a _secrets.py file in the config folder that is ignored by git and contains all sensitive constants like database information and tokens. Then, in the _base.py settings file (what all other settings files inherit from), I make sure to `from _secrets import *`. I'm not a fan of setting tokens by environment because it gets a little too unwieldy to make sure bash/z…

When using Heroku and similar hosts, the only way to upload files is via git push, so you won't be able to get your _secrets.py file into the server.

Re: A Better Way to Manage the Rails Secret Token

#22

Post by danielfone »

olalonde wrote: post #20
charliesome wrote: post #9

> Knowing the secret token allows an attacker to trivially impersonate any user in the application. Worse. Knowing the secret token allows an attacker to trivially execute code in your application. Don't ever let your secret token become public knowledge, and if it does, you need to change it straight away.

Doesn't Rails use randomly generated session IDs? Also, how does it allow an attacker to trivially execute code?

> Session data is marshal-ed Ruby data, deserializing it has the same risks as YAML.load.

http://daniel.fone.net.nz/blog/2013/05/20/a-better-way-to-ma...

Re: A Better Way to Manage the Rails Secret Token

#23

Post by ceol »

ricardobeat wrote: post #21
ceol wrote: post #18

For Python website projects, I enforce the creation of a _secrets.py file in the config folder that is ignored by git and contains all sensitive constants like database information and tokens. Then, in the _base.py settings file (what all other settings files inherit from), I make sure to `from _secrets import *`. I'm not a fan of setting tokens by environment because it gets a little too unwieldy to make sure bash/z…

When using Heroku and similar hosts, the only way to upload files is via git push, so you won't be able to get your _secrets.py file into the server.

Oh, that's a very good point. I assume Heroku allows you to set environment variables? I've never really used it before, so I didn't even think of that possibility.

Re: A Better Way to Manage the Rails Secret Token

#24

Post by olalonde »

danielfone wrote: post #22
olalonde wrote: post #20

Earlier quoted context omitted.

Doesn't Rails use randomly generated session IDs? Also, how does it allow an attacker to trivially execute code?

> Session data is marshal-ed Ruby data, deserializing it has the same risks as YAML.load. http://daniel.fone.net.nz/blog/2013/05/20/a-better-way-to-ma...

That's a bit surprising. I'd be interested to read the reasoning behind this design decision as most frameworks I have used store session data in a database rather than directly in the cookie. Well I guess there is a pretty damn good reason given Rails' reputation.

Re: A Better Way to Manage the Rails Secret Token

#25

Post by steveklabnik »

ceol wrote: post #23
ricardobeat wrote: post #21

Earlier quoted context omitted.

When using Heroku and similar hosts, the only way to upload files is via git push, so you won't be able to get your _secrets.py file into the server.

Oh, that's a very good point. I assume Heroku allows you to set environment variables? I've never really used it before, so I didn't even think of that possibility.

Yes, Heroku does, with 'heroku config'.

Re: A Better Way to Manage the Rails Secret Token

#26

Post by olalonde »

bifrost wrote: post #19
krapp wrote: post #15

Earlier quoted context omitted.

If it doesn't show up in a repo file then it is a bit better.

Yes, but only marginally; You can get the environment of another process with the "ps" command trivially. If you're in a shared environment you just made it that much easier for other people to monkey with your stuff. Here's a great example of the repo file checkin fail though: http://bit.ly/10dLiDz

> If you're in a shared environment

The common wisdom seems to be that you can forget about security in a shared environment regardless. The "secret key in environment variable" technique is mostly useful at protecting against malicious employees since it's easy to limit access to the production server but not so easy to limit access to configuration files which are in a Git repository.

Re: A Better Way to Manage the Rails Secret Token

#27

Post by olalonde »

steveklabnik wrote: post #12

We've had discussions about this several times, and haven't come up with something that's satisfactory as a generic replacement, other than "configuration could probably be improved." For one example, see this from a year ago: https://github.com/rails/rails/pull/3777#issuecomment-289375... > If we ignore them, this means a recently created, pushed and then cloned project is not going to work at all. Some people repla…

Have you considered generating a key at first startup and storing it in a database? Or would that introduce too much unnecessary overhead while introducing an attack vector through the database?

Re: A Better Way to Manage the Rails Secret Token

#28

Post by bifrost »

olalonde wrote: post #26
bifrost wrote: post #19

Earlier quoted context omitted.

Yes, but only marginally; You can get the environment of another process with the "ps" command trivially. If you're in a shared environment you just made it that much easier for other people to monkey with your stuff. Here's a great example of the repo file checkin fail though: http://bit.ly/10dLiDz

> If you're in a shared environment The common wisdom seems to be that you can forget about security in a shared environment regardless. The "secret key in environment variable" technique is mostly useful at protecting against malicious employees since it's easy to limit access to the production server but not so easy to limit access to configuration files which are in a Git repository.

While I generally agree, there's a lot of shared environment out there that people seem to think is secure. I also would posit that its probably easier to get the calling environment through some flaw in bad programming vs getting a file off the filesystem. I would also posit that not having strong controls on your source tree is probably not a good thing as well...

Re: A Better Way to Manage the Rails Secret Token

#29

Post by davesims »

olalonde wrote: post #24
danielfone wrote: post #22

Earlier quoted context omitted.

> Session data is marshal-ed Ruby data, deserializing it has the same risks as YAML.load. http://daniel.fone.net.nz/blog/2013/05/20/a-better-way-to-ma...

That's a bit surprising. I'd be interested to read the reasoning behind this design decision as most frameworks I have used store session data in a database rather than directly in the cookie. Well I guess there is a pretty damn good reason given Rails' reputation.

Rails' default session is cookie store, highly recommended is DB. It's a config issue that depends on your app's particular DB setup, so default isn't DB. But in session_store.rb you'll see this comment recommending against the default:

  # Use the database for sessions instead of the cookie-based default,
  # which shouldn't be used to store highly confidential information
  # (create the session table with "rails generate session_migration")
  # ShopMobile::Application.config.session_store :active_record_store

Re: A Better Way to Manage the Rails Secret Token

#30

Post by maxk42 »

krapp wrote: post #15
bifrost wrote: post #7

Eh... Keeping that in the system environment isn't really any better than hardcoded in a file. There's a long history of "do not trust the system environment" when it comes to security so I can't say I'd recommend this. Last I checked it was also fairly trivial to dump this data out of a running program... Unless you're grabbing that key out of "secure memory", a HSM or a TPM then its not really particularly secure.

If it doesn't show up in a repo file then it is a bit better.

Yes, but any application running under the same UID can get the secret token -- or it can be grabbed from whatever file sets up the environment. This isn't necessarily an improvement in security and is probably a step backwards. It's more helpful to make sure you don't allow secret_token.rb into the repo than it is to make sure the token gets loaded from the environment.
Post reply on HN