I think Michael makes a very good point. We trust our admins with root access, so I can't imagine why we'd go extra mile hiding an app secrets from them when they are so powerful with root already. If I had a sysadmin that I couldn't trust handling this token properly, I would never hire him in the first place. As long as the secret accessibility is restricted to an appointed unix group (e.g. "deploy") - that should work, shouldn't it?
*From:* rubyonrails-core@googlegroups.com [mailto: rubyonrails-core@googlegroups.com] *On Behalf Of *Michael Koziarski *Sent:* Friday, March 28, 2014 4:47 PM *To:* rubyonrails-core@googlegroups.com *Subject:* Re: [Rails-core] Proposal: Dynamic secret_tokens If you wanted to attempt support for a dynamic secret, you could give it a go, but I feel I should correct one thing. Systems administrators will *always* be able to read your secret, there is *no* avoiding this, they can fire up rails console and run: irb(main):002:0> Rails.application.config.secret_key_base => "f1a4df910e88f985dd555dd4ad0210b4cc8e9ca8306ab8ae29164d4c8874b5yesthisisrandomnoisenotmysecret6ad01ac7762ede919f5f5c513bf866654d1355" Even if we tried to put in mitigations for this risk, there's always GDB. So if you want dynamic secrets for some reason, give it a go and see how the patch turns out, but don't do it to make your secret 'admin proof', that's not going to happen. On Sat, Mar 29, 2014 at 4:02 AM, Bert Goethals <bertgoeth...@gmail.com> wrote: Hi all, Security is always a hot topic, and in our company especially. We where looking into the secret tokens. And we think we can do a step better than an "secrets.yml" file. The fact is that system administrators still have access to the secret token, and that is not always acceptable. Replacing the secret token each time an admin leaves, is not a viable solution. So we fought, how about a dynamic token? Proposing to make the token "callable". Besides being a string, the token could be a proc or anything responding to call, receiving the request object. This allows the implementer to dynamically change the token. This can be useful to have a separate token per domain, very useful in multi tenant applications. If there is intrest in this, I'm willing to develop it as well! What do you think? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- Cheers Koz -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
