Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92231
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.171 as permitted sender)
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
References: <CAGa2bXY3Zdrq-vU6_gCJVC3smP7DooBsKFNmQpz=ksdKsQORbQ@mail.gmail.com>
 <5706EEF3.3050705@gmail.com>
 <CAGa2bXbQkw2ouDJf5FHk3dbA4Xea4DmCwPdHUt_WRQ7H=EMAeQ@mail.gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <570D1E89.4050702@gmail.com>
Date: Tue, 12 Apr 2016 09:12:57 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbQkw2ouDJf5FHk3dbA4Xea4DmCwPdHUt_WRQ7H=EMAeQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Session ID without hashing
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> 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.

That assumes we use /dev/urandom directly and it is always available on
all systems and always accessible to PHP. I don't think it is the case
now, is it?

> 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)

We have pretty good way of removing this problem. It's called hashing.
Now we are inventing our own crypto tricks to not use existing and
proven method of doing it. This looks like bad idea to me. We do not
have expertise to even evaluate if it's safe.

> 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)

My point is it does not matter. Nobody cares if session ID generation
takes 1 ms instead of 2 ms.

> 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.

No they won't. Even if they change session ID on every request (which
sounds extremely weird, I have never seen anybody doing it and would
never recommend doing it) the different would still be unnoticeable if
the application does anything beyond generating session IDs. Unless you
can show speedup on real apps, I don't think this point is worth ever
mentioning again.

> We cannot control PRNG behavior. It's enabled for broken PRNG
> insurance. use_strict_mode=1 (detecting session ID collisions) is
> mandatory, anyway.

If we are assuming broken PRNG, it surely is unsafe to export its state
to the whole world. Either we assume PRNG is safe and sound, or not. And
I really don't like the idea of grouping unrelated changes together.

> has comment for keeping hash/PRNG related INIs? I would like to remove
> hash/PRNG related INIs if not many of us insist.

I think removing existing INI entries is completely unnecessary and just
creates BC problems without any benefit.

-- 
Stas Malyshev
smalyshev@gmail.com