Re: [RFC] [Discussion] Secure session_regenerate_id()

Hi Mateusz, On Thu, Mar 20, 2014 at 6:19 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > > On Thu, Mar 20, 2014 at 6:13 PM, Mateusz Kocielski <shm@digitalsun.pl>wrote: > >> On Thu, Mar 20, 2014 at 05:30:36PM +0900, Yasuo Ohgaki wrote: >> > Hi Mateusz, >> > >> > On Thu, Mar 20, 2014 at 5:23 PM, Mateusz Kocielski <shm@digitalsun.pl >> >wrote: >> > >> > > > > I agree. But we've got more factors here, it's not a simple >> > > > > tool >> for >> > > > > detection >> > > > > of crimes. If we let "old session" live for x secs, what will >> happen to >> > > > > changes done to the old session? How do you want to resolve that? >> We >> > > should >> > > > > find a balance between complexity and security. >> > > > > >> > > > > >> > > > Currently we have poor mitigation. My proposal provides better >> > > mitigation. >> > > >> > > I still don't see how you want to handle inconsistency between >> sessions. It >> > > seems that your RFC silently ignores that issue. >> > >> > >> > I'm not sure which inconsistency. Could you specify/describe it? >> >> Consider following scenario: >> >> 1. session_regenerate_id(..) is called >> 2. request to /update_session with old session id is done (some key-value >> in >> session is changed) - with your change this request will succeed >> --- from here user uses only new session - >> 3. updated key-value is missing in new session >> >> (same scenario can be triggered now if old session is not deleted) > > > This race condition will not change with or without my proposal. I should be more precise. This race condition will be problem with future RFC not written yet. Problem is a little differ, though. It's addressed and there is solution for it. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net