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

From: Date: Tue, 18 Feb 2014 00:40:22 +0000
Subject: Re: [VOTE] Secure Session Module Options/Internal by Default
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Hi!

> Length check is trivial, then why not check  and discard by module instead

I don't really understand - what is the point of checking length? If you
have session adoption problem, checking length won't help since the
length is public. If you don't have this problem, checking length adds
nothing since the session won't be valid anyway. So why add code that
contributes nothing? Maybe I do not see some contribution, if so, please
explain.

> There is threat and it could be removed with length check.
> Let's have the check and forget about timing attack!

But there's no actual real-world threat - there is an imagined scenario
which requires use of antique filesystems with very specific and
unobvious properties (namely, directories stored sorted by name and
having linear checks), and even in this case length check does not help,
since again, session ID length is public and so nothing prevents one
from using the correct length from the start. So length check does not
fix the timing attack even in the unlikely case such attack would
actually exist. It's like putting a locked door in an open field, and
claiming it protects from robbers, despite there being nothing to be
robbed and the door can be easily walked around. I really don't see a
point here, especially as a user setting. I could see it as an internal
check - defensive coding and all - where length is pre-calculated and
checked internally. This is fine - but as a user setting that inevitably
will be set wrong and cause trouble - I just don't see the point.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227


Thread (19 messages)

« previous php.internals (#72671) next »