This is a basic distributed systems problem. There is no way to do a secure shared nothing approach on the client side without creating server side tracking/coordination overhead. I know cookie sessions look simple and appealing at first but we're trading scalable simplicity (db store), for complexity. For security and reliability some sort of token (timestamps or nonces) would have to be coordinated across all server instances and it needs to be perfectly coordinated to work effectively.
http://www.cs.vu.nl/~ast/books/ds1/toc.html (chapters 5, 6, and 8 are good backgrounders) The downsides of the cookie approach: *) It causes more lookups/coordination overhead on the server side. You still need a db or distributed transaction coordinator lookup (each server in a cluster needs to know some sort of cluster protocol for token or timestamp management), so we're not saving a db lookup and have to maintain coordinator and recovery logic. *) It puts state unencrypted in a client device we have no control over (open to attack, reduces the usefulness of the store if we can't put anything we want in there and feel safe about it) *) It puts state in an unreliable device (browsers crash - especially firefox with a few add-ons ;) that would require recovery logic What is so broken that requires all of this messy overhead and limitations? In my mind there needs to be an overwhelming pain to justify the cost and I can't see/feel the pain to justify this effort and wasted time on the core list. SamB On Mar 23, 11:18 am, "Jeremy Kemper" <[EMAIL PROTECTED]> wrote: > On 3/23/07, Jeremy Evans <[EMAIL PROTECTED]> wrote: > > > On 3/23/07, Jeremy Kemper <[EMAIL PROTECTED]> wrote: > > > Let's talk about practical fixes rather than whether we should write > > > it off entirely. > > ... > > > > This requires one additional database query on logout to invalidate > > > future reuse of that session and no additional per-request queries. > > > This assumes you are doing a query per request anyway, and basically > > piggy backing on it for the security. If your application is already > > doing a query for the current user for every request, sure, there's > > almost no additional cost. However, if your application isn't doing a > > query per request, you have to add one to get the security, which > > makes the cost the same as using the database for session storage. > > That assumption is stated at the beginning of the example: > > > > An application-level solution to user_id replay: > > You reason that touching the database "makes the cost the same as > using the database for session storage" which is likely wrong and > certainly unsubstantiated. > > Criticism is great and welcome, everyone, but let's add some > creativity and code to the mix, please. > > > IMO, this is not a problem that the application developer should need > > to deal with manually, any more than application developers should > > handle database transactions manually. If cookie based session > > storage is going to remain the default: > > We all agree on this. We're working on it. > > > 1) There should be a configurable timeout set automatically, with a > > reasonable default (to partially mitigate the replay issue) > > 2) It should be documented that replay attacks are still possible > > 3) Advice on creating application specific solutions such as the one > > you mentioned should be included in the documentation > > Good ideas. > > > Note that timeouts provide only slight additional security, as they > > only protect against attackers who get access to a session cookie > > after it has already expired. If an attacker gets access to any > > session cookie before it expires, they can keep that session open > > indefinitely. > > Not in the scenario above: the legitimate user logging out invalidates > the attacker's session, which is the same behavior as a server-side > session. > > jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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-core?hl=en -~----------~----~----~----~------~----~------~--~---
