I'm not a crypto person, but what if a version number were embedded with every write to the cookie session? Of course, check the data +version against a hash to make sure they didn't tinker with the version.
On Mar 21, 2:26 pm, "Jeremy Kemper" <[EMAIL PROTECTED]> wrote: > 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 [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 -~----------~----~----~----~------~----~------~--~---
