Not exactly if you use environment variables with secret settings using deployment tools like Capistrano.
But I also don't see why a system admin shouldn't be trusted... Em 28/03/2014 20:47, "Michael Koziarski" <[email protected]> escreveu: > 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 <[email protected]>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 [email protected]. >> To post to this group, send email to [email protected]. >> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
