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 [email protected] to get a copy of this message
Hi,

On Mon, Feb 17, 2014 at 11:40 AM, Yasuo Ohgaki <[email protected]> wrote:
> Hi Andrey,
>
> On Mon, Feb 17, 2014 at 5:11 PM, Andrey Andreev <[email protected]> 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.


Thread (19 messages)

« previous php.internals (#72657) next »