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. 3. The cryptographic algorithm could be compromised, which is always a possibility (however unlikely.) What do you think? Eric --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Feb 21, 5:06 pm, "Eric L." <eli...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Feb 21, 5:06 pm, "Eric L." <eli...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---