Re: [VOTE] Secure Session Module Options/Internal by Default

From: Date: Mon, 17 Feb 2014 13:22:37 +0000
Subject: Re: [VOTE] Secure Session Module Options/Internal by Default
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-72657@lists.php.net to get a copy of this message
Hi, On Mon, Feb 17, 2014 at 11:40 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > Hi Andrey, > > On Mon, Feb 17, 2014 at 5:11 PM, Andrey Andreev <narf@devilix.net> wrote: >> >> I didn't want to interrupt a vote, but this 'id_length' setting was >> not initially a part of the RFC and it's just now that I see it. > > > I noticed possible attack during timing attack discussion. Therefore, > I've added this. User defined, 3rd party session or certain system's > save handler could be vulnerable. > > Simplest one would be file system with liner directory search. It would > be possible to get 1st session ID on the system with timing attack. > I suppose this scenario is possible with embedded systems. If it is > affected, it would be very easy to attack by timing. We cannot assure > system, 3rd party or user save handler is timing safe because we > cannot control implementation. Setting minimum length removes > possibility of the attack. > > I might post mail in different thread, sorry. > >> I don't see how it relates to timing attacks. >> If it is about comparing at least N characters of the session ID >> before rejecting one, then why not just compare all of them? ID length >> is public information, anybody can see what it is by simply looking at >> what the application gives them. >> And finally, the setting name itself is misleading - it doesn't make >> it clear that it's about minimum length. > > > I agree. Java has similar name setting with different semantics. > Name could be anything. Better name would be appreciated. This still doesn't explain how it would work. And why is it necessary as a setting instead of auto-detecting it? The valid length should be easy to calculate. Regards, Andrey.

« previous php.internals (#72657) next »