That's essentially what a nonce is, but: 1) Nonce is random and can't easily be guessed 2) It still doesn't solve the multiserver problem: how does one server know what the current version number is when there are 10 Mongrels?
On Mar 21, 2007, at 6:28 PM, Sandofsky wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
