Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92217
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.68 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <570CB007.2080503@php.net>
References: <CAGa2bXY3Zdrq-vU6_gCJVC3smP7DooBsKFNmQpz=ksdKsQORbQ@mail.gmail.com>
 <5706EEF3.3050705@gmail.com> <CAGa2bXbQkw2ouDJf5FHk3dbA4Xea4DmCwPdHUt_WRQ7H=EMAeQ@mail.gmail.com>
 <570CB007.2080503@php.net>
Date: Tue, 12 Apr 2016 20:01:14 +0900
Message-ID: <CAGa2bXbPEM8vxEM=8AjvTRcs1iacPcvxKHYDEtBV=pX8YhgWDA@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Session ID without hashing
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

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