Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95242
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <D3D87889.71240%fsb@thefsb.org>
References: <CAGa2bXaZhfXbU6N0-JGVPzkkxRdkcjEhkHP+YrQNH=XFX714-Q@mail.gmail.com>
 <CAPwsocFAMofROQE-OBfNiR4yrKKSss_owu0svu+Db66DmRbShw@mail.gmail.com>
 <CAGa2bXaxRA91q+ev-X3okKpNC=s3XEwC9deUYikTaUQPfOE-JQ@mail.gmail.com>
 <cc719c6c-598d-b103-96bf-eb3714a61365@thefsb.org> <CAGa2bXYNExeQLug=co8G1g+fdy6BXK9UbeyGkjss5s62R00Fdg@mail.gmail.com>
 <D3D49F41.70F4A%fsb@thefsb.org> <CAGa2bXYa-6gpyUH_yXwoob8aZA_UVjuRfzbrMxfdUp7j5jk8EQ@mail.gmail.com>
 <592333a7-2c73-38a4-b400-f3f2c7bf2f72@lsces.co.uk> <CAGa2bXYuO+y155BHG1hZSO75TzZqkH1RyU6C6jigEo9_goJoBA@mail.gmail.com>
 <CAGa2bXZoPtZ4anU=Q2RsgVssLW5O+a8f_-4sKAGj==MvJNrJ_g@mail.gmail.com>
 <c098dc4e-4d54-18d6-6c20-be4d3bee5c47@thefsb.org> <CAGa2bXa8kmdLDd8BqbB0dFTwSu4MAswxV26Tjm05ipHhiYoN8g@mail.gmail.com>
 <CAGa2bXYmtEGJJWtNW3J1oZzrny05PY7n6ns-SZ90R4DGYWN2iw@mail.gmail.com> <D3D87889.71240%fsb@thefsb.org>
Date: Wed, 17 Aug 2016 05:56:16 +0900
Message-ID: <CAGa2bXY8D6K2nHp-_tVoJR01qhw4qUNE9KQko9h7NWMfrhC_6g@mail.gmail.com>
To: Tom Worster <fsb@thefsb.org>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Tom,

On Tue, Aug 16, 2016 at 9:08 PM, Tom Worster <fsb@thefsb.org> wrote:
>>> I strongly disagree with this kind of attitude.
>>>
>>> If there are users who really do not want collision detection at all,
>>> they should do it by their own responsibility and risk.
>>
>>Above discussion is added to the RFC.
>>
>>The default 128 bits Session ID is large enough to ignore collisions
>>https://wiki.php.net/rfc/session-create-id#discussions
>>
>>It describes for an application, but PHP is a platform.
>>There are millions PHP apps or more and there could be billions of
>>active sessions. There could be tens of thousands new session IDs or
>>more are created. Apply the calculation for expected time of possible
>>collision.
>>
>>Do you still sure "There will be no collisions at all"?
>
> The calculation underestimates the difficulty of finding collisions by 38
> decimal orders of magnitude. The number of different SIDs in default PHP
> config is 2^192, not 2^64. So yes, I am still sure.

In theory, there wouldn't be collisions if CSPRNG is truly random that
will never has collided values at any given chunks. 128 bits session ID
would be far good enough.

Problem is we can measure CSPRNG is producing acceptable random
for apps requires randomness, but it is difficult making sure the random
stream will _never_ has collision.
(I'm not saying CSPRNG is not generating secure random. For most
usages of random stream do not require uniqueness. Session
module is special and requires collision free results for all CSPRNG.)

Solution is simple for session database. All we have to do is validating
newly generated session ID would not collide existing one. This is done
by session module currently. Why not for new API that is supposed to
generate 120% secure session ID?

If users do not want 120% secure session ID, but almost 100% secure
session ID is enough and would like to skip the validation. They may do

if (session_ status() == PHP_SESSION_ACTIVE) session_commit();
session_id(session_create_id()); // Session is inactive, no collision check
session_start();

by their own decision and risk.
IMHO, other way around should not be the default.

NOTE: Users will need to call session_create_id() for regenerating
session ID. Therefore, there should be active session already.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net