Good point. I realized risk #1 could be reduced by storing the secret in a secure place on the deployment server rather than under source control.
On Feb 21, 3:20 pm, Frederick Cheung <[email protected]> wrote: > On Feb 21, 5:06 pm, "Eric L." <[email protected]> wrote: > > > Should I be concerned if I am using the default cookie-based session > > storage for a high security application? Nothing sensitive will be > > stored on the cookie, but it's critical that one user cannot gain > > access to another user's account. The security risks I see with > > cookie-based storage are: > > > 1. There is a single point of failure. If the secret key is stolen > > (for example, by a rogue developer), the person in possession of the > > key can log into any account he wishes. > > > 2. It's not been as widely used as database-backed session, and > > therefore not as tested. > > given that it's been the default for well over a year I would question > that. > > > 3. The cryptographic algorithm could be compromised, which is always a > > possibility (however unlikely.) > > While the risks in 1 and 3 do exist I don't think it's a game changer > compared to the other risks involved (people setting weak passwords, > the cryptographic algorithm securing your ssh or ssl sessions being > compromised and data being leaked that way, the rogue developer > harvesting data straight from the database, cookies being stolen via > XSS attacks etc.) > > Fred --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
