Reminder: secret_token.rb is named so for a reason

http://biggestfool.tumblr.com/post/24049554541/reminder-secret-token-rb-is-named-so-for-a-reason

by Ryoku • 14 years ago

53 55 14 years ago

biggestfool.tumblr.com

JPKab• 14 years ago

Wow. Please, please tell me that these are just hobby projects which have this happening. I can understand a beginner who doesn't understand git ignore doing this, but if there are people building products with this ignorance, that is troubling. I can see why a lot of greybeards hate frameworks, because someone who builds web apps with a much more bare bones framework, (Sinatra, Webapp2, Express, etc) most likely understands the fundamentals of encryption/hashing simply because of the fact that lighter frameworks require understanding the fundamentals in general.

This isn't to say that a developer for one of these frameworks couldn't easily overlook adding the files with secret_tokens in them to the .gitignore.

iaw• 14 years ago

I consider this in the same realm as storing passwords to plain text. People do it out of ignorance until they're learn the hard way not to (or some kind soul saves them from that disaster).

ajross2• 14 years ago

How is this not considered a framework bug? "Secret tokens" are project-specific configuration more or less by definition. Putting them in something that lives in a source directory is simply asking for this kind of mistake.

Rails deployments aren't leaking their ssh keys or database content because that is stored separately. To paraphrase the title: these things are stored separately for a reason.

Get this thing out of the source, guys.

jrochkind12• 14 years ago

I could see lots of people doing it, only because Rails auto-generates the secret_token.rb file -- it's easy to just not think about it, forget it exists, put your whole source tree in the repo -- remember to keep database passwords and such out, but not ever even think about secret_token.rb, it just ends up in there.

Rails does the right thing by putting the secret token in it's own file that's even _called_ secret_token.rb (it could have just jammed it in the middle of config/application.rb or something instead, where it would be even easier to miss and/or not realize it should be kept private). So I don't know it's people who don't 'understand' it -- whether you understand it or not, the file is named "secret_token", if you actually look at a file listing and think about "should this be kept secret?", the answer is obviously yes even if you know nothing.

But... there's still a lot going on, and it's something easy to forget about, since you ordinarily _never_ need to think about the secret_token.

JulianMorrison• 14 years ago

A file named "secret_token.rb" looks to me like "ruby code to operate on secret tokens", just like a file called "sha256.rb" would be expected to compute hashes, not contain them.

Should have been called "secret_token.yml". Should live in the config, or even better, a "secret_config" top level directory, not a subdirectory.

dlisboa• 14 years ago

> I can see why a lot of greybeards hate frameworks, because someone who builds web apps with a much more bare bones framework, (Sinatra, Webapp2, Express, etc) most likely understands the fundamentals of encryption/hashing simply because of the fact that lighter frameworks require understanding the fundamentals in general.

Usually what ends up happening is people build less secure systems because they don't understand those basics. Giving people less tools don't equate in them building better solutions on their own.

omra3• 14 years ago

Note that this was published back in May 2012, so it's not entirely recent (which is OK, just thought I would note it). However, this seems to have been public by February 2011 (http://stackoverflow.com/questions/5132152/when-you-have-sec...). I don't think the issue is entirely widespread, and a different key is likely used for production.

Ryoku4• 14 years ago

Yes, it is an old issue, the problem is that it's still there. Developers keep doing it for production, it is common knowledge for people involved in security, but not for developers, which is worrying. Take a look at this results http://www.lmgtfy.com/?q=inurl:secret_token+filetype:rb#

omra3• 14 years ago

I have no problem with old issues or vulnerabilities being posted, of course, especially when they are very widespread such as in this case.

Note that not all of those results are necessarily vulnerable, for example, https://github.com/hotsh/rstat.us/blob/master/config/initial... loads the secret key from the environment, and https://github.com/GreenplumChorus/chorus/blob/master/config... loads it from an ignored file (like the article). I would estimate the real number of projects to be somewhere less than 3000, with about 1400 being on Github. This also assumes that these are all actually production keys.

Just to reiterate, I do believe that this is a legitimate problem even now, but I just wanted to note the age of the article and to refute the claim that this is the first mention of the issue.

cllns2• 14 years ago

It'd be nice if github would suggest adding secret_token.rb to .gitignore when it's uploaded.

jcoder3• 14 years ago

No thanks. The last thing I want is my version control host getting opinionated about my application domain.

beering• 14 years ago

What if they just gave you a onetime warning instead?

cllns2• 14 years ago

Care to elaborate on why?

Github's tagline is currently "Build software better, together." Wouldn't this help people create better software?

I'm not saying they should automatically add secret_token.rb to gitignore, just that they could let you know you might not want to do that.

untog2• 14 years ago

Version control being hard-coded with an exception for a particular framework of a particular language... I see the benefits, but I am deeply wary of it. What if the filename changes in the future? Does GitHub somehow have to detect versions?

jlarocco• 14 years ago

I'm not sure if you're joking. Ruby on Rails projects aren't the only ones that have files that shouldn't be made public on GitHub.

GitHub will already generate a .gitignore file when you create a repository on its website. It would be nice if the .gitignore file was based on the type of project being created. And it would be nice if it gave a warning when files that are in the default .gitignore were being pushed to the repo.

If the filename changes in the future, who cares? It defaults to the current situation where no warning is given, but potentially improves security in many cases. And it's not a big deal to add another file to a list.

Tichy• 14 years ago

Or rails could suggest additions to .gitignore (and equivalents for svn).

bigiain2• 14 years ago

Or,since we're proposing changes to Rails* how about the Rails people fix it properly, and put the configuration somewhere outside the source tree?

*(which is much more sensible than proposing changes to git/github in response to a Rails default configuration problem)

enkrs• 14 years ago

Maybe not so intrusive, but they could add it to https://github.com/github/gitignore/blob/master/Ruby.gitigno... . Not sure how many people use that repo tough.

joevandyk4• 14 years ago

Would be even better if secret_token.rb's data was kept in the database.

maximegarcia• 14 years ago

Exactly!

https://github.com/LePartiDeGauche/pgonror/issues/2

bgdam2• 14 years ago

What is the advantage to hashing a user id and storing it in the cookie over simply generating a random session code and storing it in a db table against the user's id and then checking every request? Is the overhead of an extra db read the only reason people don't do this? (Honest question, not trying to be smart)

dustingetz• 14 years ago

that would couple session to db. Play Framework, for example, is able to provide support for sessions using encrypted cookies, without having to provide adapters to all sorts of potential databases.

Ryoku4• 14 years ago

Well, in order to protect the hashes in said cookies you would end up doing something similar to prevent malicious users from just spoofing them. If you use id/hash tables the way you propose the hash is acting just like an id and is then vulnerable to the same issues. The problem is not that the id is there, but that you need a method to make it hard to spoof.

bgdam2• 14 years ago

No, you have mosunderstood me. I'm NOT storing a hash in the cookie. Instead im storing a random string. Because this string is random, there is no way that a malicious user can guess what the session code will be for a particular user id.

kawsper2• 14 years ago

> Is the overhead of an extra db read the only reason people don't do this?

Yes, and using secret_token.rb is also way faster.

bgentry2• 14 years ago

As hgimenez said, the best way is to not store your secrets in your source tree at all (12factor.net style). Keep them in the environment. Here's a great example:

https://github.com/democrats/voter-registration/commit/2fa87...

nodata• 14 years ago

Is that a good example? It doesn't warn if the env isn't set.

bgentry2• 14 years ago

No, it doesn't warn, it raises an error and prevents the application from booting: https://github.com/democrats/voter-registration/commit/2fa87...

prezjordan• 14 years ago

Why doesn't rails add this to the .gitignore generated from `rails new myapp`? And maybe include a rake task to generate a new secret token. That's why I've been doing ever since I found out about this.

bigiain2• 14 years ago

Because that doesnt solve the problem properly. Perforce users are still vulnerable, and Mercurial users, and (assuming any still exist) CVS users.

Secrets (keys, passwords, tokens, etc) don't belong in the source tree. If you put them there by default, one day you (or one of your users) is going to "forget" and be in a world of hurt.

michaelmior• 14 years ago

I would argue this is even worse for Django projects. Django secret keys are in the settings file by default, which definitely needs to be put under revision control.

joevandyk4• 14 years ago

Why don't more people keep configuration / api keys / etc in the database?

1. Your configuration is backed up along with your data.

2. You can share configuration with multiple applications easily.

3. Use postgresql's LISTEN/NOTIFY to tell your applications about new configuration changes in real-time.

4. Your configuration is as secret as your data.

krapp2• 14 years ago

If you're vulnerable to a sql injection or something similar, though, then you've potentially made all of that data web accessible.

joevandyk4• 14 years ago

If you are vulnerable to sql injection, you are completely screwed anyways.

dice• 14 years ago

Where do you store the configuration for where and how to access the configuration database?

joevandyk4• 14 years ago

That's the only thing I keep as an env var (as DATABASE_URL: ie "postgres://monkey:pass@localhost/tanga_dev")

juandazapata• 14 years ago

We use the Figaro gem to setup ENV variables per project without messing with your system Path.

It also pushes your ENV vars to Heroku with one command. Pretty neat and simple.

In case you want to check it out https://github.com/laserlemon/figaro

Reminder: secret_token.rb is named so for a reason

Related Stories