On 3/21/07, S. Robert James <[EMAIL PROTECTED]> wrote: > IMO, we need to rethink moving to cookie sessions by default, then - > if a core member hadn't thought about, what can we expect from > beginners? Last thing we need is a reputation for being weak in > security.
I think that's a bit sensational. The cookie store has gone through a couple of evolutionary steps already and is ready for more, if need be. > Before everyone responds: "It will help performance, and good > developers don't store volatile data in the session, anyway!" I'll say > that we've seen lots of companies (who won't be named) sacrifice > security in order to gain out of the box performance or ease of use - > and it comes back to haunt them. Secure by default, and let the > advanced users make it less secure to improve performance - not the > other way around. Let's see a brainstorm of solutions and other potential vulnerabilities. > > > This is normally solved using something called nonce - each signing > > > includes a once only code, and the signer keeps track of all of the > > > codes, and rejects any message with the code repeated. > > > This sounds like something you could perform at the application level. > I don't think so - as long as step 2 (in my example) goes to one > Mongrel, and step 4 goes to another, the attack succeeds. I can try > repeatedly with a script until this happens. The only way to protect > is to use a shared backend like the DB or DRB - but then you've lost > the point of cookie sessions. To some degree. I'm sure there's more to this, though. I'm not a crypto expert. 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 rubyonrails-core@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
