Hi Mateusz,
On Thu, Mar 20, 2014 at 6:19 PM, Yasuo Ohgaki <[email protected]> wrote:
>
> On Thu, Mar 20, 2014 at 6:13 PM, Mateusz Kocielski <[email protected]>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 <[email protected]
>> >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
[email protected]