Re: [RFC][DISCUSSION] Session ID without hashing
| From: | Yasuo Ohgaki | Date: | Tue, 12 Apr 2016 11:01:14 +0000 |
| Subject: | Re: [RFC][DISCUSSION] Session ID without hashing | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-92217@lists.php.net to get a copy of this message | ||
Hi Michael,
On Tue, Apr 12, 2016 at 5:21 PM, Michael Wallner <mike@php.net> wrote:
>> PRNG like /dev/urandom is supposed to be secure, but fair point. It
>> may be good idea keeping old hash based session ID just in case
>> someone find vulnerability. I suppose it's unlikely with modern PRNGs,
>> though.
>
> I've come to think that "unlikely" is still a bad precondition with
> regards to security... :)
Yes.
Almost all of crypt relies on "unlikely", though.
So issue is how "unlikely" it is.
I suppose almost all crypt experts agree
/dev/urandom and friends are secure enough.
(Except side channel attacks)
>> If we have to care about PRNG state exposure, code may be changed to
>> read random length from RPNG. This would be good enough mitigation. I
>> would like to hear from PRNG experts if this is good enough. (or not
>> needed)
>>
>>> Second, I do not see why we need to do maximum
>>> breakage change if we could just make an identity "hash" function and
>>> support both cases. "Session generation performance" does not have a lot
>>> of meaning here - I'd be very surprised to see any application that is
>>> bound by the speed of generating session IDs.
>>
>> w/ Patch: Requests per second: 2278.59 [#/sec] (mean)
>> w/o Patch: Requests per second: 899.36 [#/sec] (mean)
>> (This is CLI server and "ab -c 20 -n 100000" result on Core i7 4770s Linux)
>>
>> I didn't expect this much difference, but this is the result. Since
>> security experts advise to change session ID relatively high frequency
>> (few minutes to half an hour), this difference may be noticeable apps
>> returning cached JSON. I know apps that change session ID on every
>> request. (This should be done with caution. Otherwise, you may
>> experience lost sessions a lot due to race conditions) Such apps will
>> see performance gain.
>
> This RPS change is the result of just omitting hashing of the session id?
and changes "session.use_strict_mode" default INI value to 1.
I haven't added code to read random length from PRNG also.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net