This was discussed earlier in the thread. The problem is that such a nonce would require communication between the backend servers via DRb or the database, which removes any benefit from storing the cookies client-side. You might as well store the whole session in the database or DRb store.
As for the opt-in, if you're the type of user that would know enough about security to opt in to such a plan, you're probably not storing account balances in a client-side cookie. The discussion we are having concerns sensible defaults. On Mar 22, 2007, at 1:01 PM, Steve Longdo wrote: > This problem can be addressed in a lot of ways. One of the easiest > approaches would be to use a filter to process the validity of a > cookie. Have an after_filter that adds a "single-use" token to the > cookie after a request and a before_filter that checks for the > "single-use" token when a user makes a new request. That way a > replay attack wouldn't work. > > Bundling in something like this into Rails makes a lot of sense. > It would be opt in by adding the filters into application.rb and > not forced on anyone by default. > > On 3/22/07, Brad Ediger <[EMAIL PROTECTED]> wrote: > > On Mar 22, 2007, at 11:15 AM, S. Robert James wrote: > > > On Mar 22, 10:44 am, Brad Ediger <[EMAIL PROTECTED]> wrote: > >> This is the crux of the issue... of *course* it's a terrible > idea to > >> store sensitive or transient data in the session, but the > question is > >> one of API design. Do we want the penalty for ignoring best > practices > >> to be compromised security? > > > > It's even more complicated. Defining "sensitive or transient > data" is > > not at all trivial. > > > > The standard use case for a cookie session is store only flash and > > user id. Not sensitive or transient? Okay. > > > > Now, I click "Log Out", and get up from the library's computer, only > > to let the person waiting after me to retrieve the old cookie.... > That > > innocuous user id just became both sensitive and transient. > > > > The point is, answering these questions is hard. Witness the > > confusion in this thread alone. DIY cryptosystems are hard: > > professionals fail. WEP failed. Does it make sense to push all > these > > questions onto each new Rails developer's shoulders? > > And I think that is exactly what it comes to. That's kind of where I > landed with that post when I started considering what user_id really > meant. > > As neat as cookie sessions are, I don't think I'm going to use them > to store authentication info anymore. Too many question marks. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
