Re: [VOTE] Secure Session Module Options/Internal by Default
Hi!
> When "use_strict_mode=on", attacker sends short session ID many times to
> see if the char matches part of session ID or not. When underlying data
> storage is vulnerable to timing attack, timing is leaked. i.e.
> stat(session_data_file_name) could be timing unsafe.
Why would they send short ID if they could send full-length ID and
easily defeat your checks?
> htree is safe. Weak hash could be issue. Most of us remember hash
> collision attack few years ago. (e.g mm save handler uses very simple
Hash collistion attacks have nothing to do with this, they rely on the
fact that hash we are using is not perfect and it is easy to generate
colliding strings, thus producing degenerate performance. However, in
this case we're talking about completely different scenario.
> With minimum length, attacker must guess char combinations of that
> length regardless of underlying session data storage.
Not really. The whole point of timing attack is that the underlying
mechanism must not use all chars of the string for comparison.
> Minimum session ID length solves all issues/anxieties and we may leave
> timing attack behind as long as users set appropriate value to it.
I still don't see even one issue it solves. Timing attack would still
work the same if underlying mechanism uses comparison where time of
comparing aaaa to bbbb (assuming length is 4) if different from timing
of comparing aaaa to aaab. Different length is not required here, and
since length is public, it won't be the factor in the attack anyway.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Thread (19 messages)