31–40 of 60 posts
> if Rails.env.development? or Rails.env.test? I hate code like this that is explicitly aware of the environment. The code says what it will do in an environment, rather than the environment saying what the code should do in it.
I wish Rails supported two secrets the way Rack::Cookie does by always signing with the first, but accepting either. That way you can rotate the secret without signing everyone out.
[1]: http://www.gorillatoolkit.org/pkg/sessions#NewCookieStore
The entire principle behind HTTP - what enabled it to conquer and dominate the internet, is its statelessness. Storing and trusting things in cookies is a fundamental security design flaw.
Your environment is not secure. The solution for this type of problem (keeping secrets out of source control) is to create a deployment-specific configuration file that is not kept in source control. It can be created out of a generic version that is kept in source control. Then, OS-level permissions are applied so the file is only readable by the processes that need access.
> 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?
Earlier quoted context omitted.
> 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...
Don't trust your environment.
I'm not sure I understand what dotenv does (or why you would need it to do it).
It loads environment variables from a .env file when starting your app so that you don't have to do $ SECRET_TOKEN=abcdef SOME_OTHER_VAR=hello rails s or pollute your .profile with a bunch of app-specific variables. You don't need it to do it; it just makes it easier.
secret_token = File.read('secret_token_dont_check_in')
Earlier quoted context omitted.
It loads environment variables from a .env file when starting your app so that you don't have to do $ SECRET_TOKEN=abcdef SOME_OTHER_VAR=hello rails s or pollute your .profile with a bunch of app-specific variables. You don't need it to do it; it just makes it easier.
Couldn't you just read the file directly? e.g. secret_token = File.read('secret_token_dont_check_in') I fail to see how loading the file into the environment and then into the variable is anything but worse.