- 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, and instead generate and deploy it by other ways (such as symlinking like database.yml or PaaS variables), since having it in the source put an onus on people having access to the source code (such as freelancers/contractors, or other team members without deploy access etc). This should be treated sensitively!
- in today's practice of having the key in the source code, some staging environments would currently also have the same key by default, and sometimes these are less secure or up-to-date compared to production environment, providing another attack vector maybe.
* 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...
if Rails.env.production? && ENV['SECRET_TOKEN'].blank? raise 'SECRET_TOKEN environment variable must be set!' end
secret_token = ENV['SECRET_TOKEN'] || 'safdasfjlkj...'
Would be an absolute pain for users of things such as Github who deploy several times a day.
You are required to configure my app anyway, and I can store it inside of a config file that doesn't need to be made public or stored in version control.
I don't like this.
Otherwise, not a bad exploration.
This is not to say that leaving a private key world-readable is necessarily a horrible idea; it can certainly ease deployment, and there are always tradeoffs. But it does mean that this key is only as secure as your most vulnerable user account - including unprivileged user accounts running riskier services (unless they are genuinely sandboxed).
Making it readable only by a certain group is going to be better, security-wise, and shouldn't be too much more difficult, and so may generally be a better idea, but my key objection was that it sounded like a statement of policy: "we're only deriving keys from this, so we don't need to be careful with it" - which is bad policy without considering the protection the needed by the specific keys. The article does talk about this some later on but not (IMO) clearly or generally enough.
