On Mar 22, 11:42 pm, "Michael Koziarski" <[EMAIL PROTECTED]> wrote: > If you'd like to coordinate this, I'd definitely be glad to hear from > them....I'm not sure that there's a shared nothing way to take > care of that, but the crypto experts would know for sure. > > Please do investigate having someone conduct a review.
Will do - I'll speak to some of my contacts and see if they're willing to do a short review, pro bono. > I'm not sure that there's a shared nothing way to take > care of that Exactly. Basically, you can mathematically prove that the only way to avoid replay attacks is with some type of trusted store. Which of course needs to be shared. @Brad - Great work on setting up some code for benchmarking. I haven't reviewed your code, but doing nonces correctly gets into some sticky synchronization and concurrency. Basically, the system needs to make sure that: * The nonces used by all of the Mongrels are kept track of (eg one counter per Mongrel) * No Mongrel uses the same nonce (eg prefix the nonce with the Mongrel's pid) * That the issuing a nonce, restoring a session, and then invalidating the nonce are all done in the correct order. This can get very tricky: Specifically, we need to make sure that once the session has been modified, its nonce is invalidated immediately. At the same time, we can't invalidate it before a new session has been assigned, or those requests will be incorrectly rejected. This gets very, very tricky when you're dealing with multiple overlapping requests: invalidate too soon, and you've broken pipelining. Invalidate too late, and you're subject to replay attacks. Like I said, crypto is hard: amateur cryptosystems are usually broken with relish. @Jeremy - you're raising a good issue. I think it would be beneficial to define exactly what the goals of cookie sessions are. Performance? Less administrative setup? Simplicity (I think that's been lost already)? Not having to store dormant sessions? I'll add that, IMO, an attraction to coolness and clever code is *not* a goal worth pursuing. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
