Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92153
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.65 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <5706EEF3.3050705@gmail.com>
References: <CAGa2bXY3Zdrq-vU6_gCJVC3smP7DooBsKFNmQpz=ksdKsQORbQ@mail.gmail.com>
 <5706EEF3.3050705@gmail.com>
Date: Fri, 8 Apr 2016 11:17:11 +0900
Message-ID: <CAGa2bXbQkw2ouDJf5FHk3dbA4Xea4DmCwPdHUt_WRQ7H=EMAeQ@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: "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 Stas,

On Fri, Apr 8, 2016 at 8:36 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> Session module does not require hashing to generate session ID. This
>> RFC removes hashing from session module and enable use_strict_mode as
>> an insurance for broken RNG.
>>
>> https://wiki.php.net/rfc/session-id-without-hashing
>
> I'm not sure why that should be the default. First of all, I'm not sure
> exporting the state of the PRNG is that good an idea, there may be
> vulnerability in the PRNG that could be opened (or made easier) for
> exploit with direct access to its output. I'd rather not provide this
> opening unnecessarily.

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.

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.

> Also, I don't see how use_strict_mode change is related to the hashing.
> Could you explain?

We cannot control PRNG behavior. It's enabled for broken PRNG
insurance. use_strict_mode=1 (detecting session ID collisions) is
mandatory, anyway.

Regards,

P.S. Code may be changed so that user can choose raw PRNG and old
hashing. We have to keep old and new INI settings in this case. Anyone
has comment for keeping hash/PRNG related INIs? I would like to remove
hash/PRNG related INIs if not many of us insist.

--
Yasuo Ohgaki
yohgaki@ohgaki.net