Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92215
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sensational.ch designates 195.226.6.199 as permitted sender)
MIME-Version: 1.0
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 10:38:12 +0200
Message-ID: <CAGKNXQGJ9a5AmsN-GV4N1yKh2Q4SH+4-Dfi9vfgX2top11F8Fg@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, 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: phofstetter@sensational.ch (Philip Hofstetter)

Hi

On Tue, Apr 12, 2016 at 10:21 AM, Michael Wallner <mike@php.net> wrote:
> On 08/04/16 04:17, Yasuo Ohgaki 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... :)

however, if a vulnerability is found in /dev/urandom, that would be a
stop-what-you're-doing-and-patch moment anyways because so much stuff
depends on /dev/(u)random not producing predictable output.

If /dev/urandom is not to be trusted, you have to bring your server
offline right then. The fact that PHP would continue to produce more
secure session IDs won't help you much.

>> 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?

if it is, it's really worth considering this change as, again, a
vulnerability in /dev/urandom would be devastating enough to
immediately bring down the machine anyways.

Philip