Hi- Thanks for the levelheaded response. I'm sorry if I was a little inflammatory before. Occupational hazard. :-)
Comments follow. On Mar 27, 2007, at 10:24 AM, Neil Wilson wrote: > I understand the distinction very well. I would suggest that you have > ascribed more capability to 'session' than the semantics of that > facility allow. > > What I'm saying is that now you have client side session data, you > have exposed the limited semantics of 'session' and there is an issue > that was simply masked by the server side stores. (snip) > Why not switch to session side stores and mask the issue, or implement > an AuthenticatedSession that does what you want it to do (and release > it as a plugin if you so desire). Complex cookie encryption might be > an interesting technical puzzle, but is it really required by default? I think we're on the same page here, but maybe coming at it from opposite directions. I think the session abstraction, as exposed by the server-side stores, worked fine. I don't think it was masking anything -- I wouldn't say that every aspect of an application's semantics needs to be captured explicitly in the model. As an abstraction, the server-side stores provided everything that developers needed, even considering sensitive and volatile data (i.e., authentication information). The problem comes when you try to change the abstraction. Storing sensitive data with an untrusted client is always tricky -- it's the reason that ATM cards are fundamentally more secure than any anonymous e-cash system. "Complex cookie encryption" covers a lot of ground... the HMAC will definitely be required if you want any integrity at all, and some sort of nonce is (provably) required if replayed sessions can hurt you in any way. However, I think that it is too much to ask of new developers to implement the whole AuthenticatedSession thing (along with the requisite security analysis) themselves. As Robert James pointed out in this thread, security analysis is really tricky -- there are N ways to get it wrong and 1 way to get it right. And forcing developers to consider security at this level isn't too friendly, IMO. I believe that CookieStore should be either (1) secure against replay attacks by default, or (2) not the default session store. Anything else is asking too much of non-security-aware developers. --be --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
