Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95117
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thefsb.org designates 67.192.241.155 as permitted sender)
User-Agent: Microsoft-MacOutlook/14.6.6.160626
Date: Sat, 13 Aug 2016 11:22:58 -0400
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <D3D49F41.70F4A%fsb@thefsb.org>
Thread-Topic: [PHP-DEV] [RFC][VOTE] Add session_create_id() function
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>
In-Reply-To: <CAGa2bXYNExeQLug=co8G1g+fdy6BXK9UbeyGkjss5s62R00Fdg@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function
From: fsb@thefsb.org (Tom Worster)

Hi Yasu,

On 8/12/16, 4:38 PM, "Yasuo Ohgaki" <yohgaki@ohgaki.net> wrote:

>Base 64 adds padding for extra bytes. The Padding char is "=" and it's
>illegal char as SID. Therefore trims is mandatory.

substr(base64_encode(random_bytes($n)), 0, $n). There is no "=" in the
value for any $n.


>Don't you think it's nice to make "PHP just works" without knowing such
>details?

Not in this particular instance, no. Anybody that takes on the
responsibility of designing a scheme for session ID generation needs to
know such details. The typical PHP programmer does/should not do such work
because its is difficult and dangerous and because the requirement seldom
arises. PHP should not try to patch up garbage session IDs by rejecting
IDs already in use.


>Session ID security is key factor of Web application security. There
>is huge difference between 'cannot happen' and 'very rare and almost
>cannot happen'. In addition, proving 'very rare and almost cannot
>happen' is difficult.

This is equivalent to saying that random_bytes() cannot be trusted as a
CSPRNG.


>NIST requires SHA2 or better hash for collision sensitive usage. SHA2
>has 256 bits or more. We only use 128 bits, i.e. MD5 and
>bits_per_character=5 now. (130 bits for 7.1 and later).

Hashing is not the same problem. It's different in some important ways.



>Therefore, I
>don't think collision check is needless. We should have 256 bits
>session ID at least which requires 52 chars with 5 bits_per_character.

I don't think NIST's hashing recommendations should be the basis for
saying how many random bits PHP session IDs should have. I think we should
make our own calculations from first principles.


>We know it's relatively easy to check if a PRNG meets NIST
>requirement, but requirement fulfillment does not mean PRNG is
>generating excellent random. Measuring quality of PRNG is difficult.
>(This does not mean we should add low quality entropy such as time and
>pid to create SID and hash it. We depends on PRNG security anyway, use
>of hash and low quality entropy only makes SID weaker. Thus I proposed
>raw PRNG usage for SID)

Since 7.0, PHP uses the best available practices to obtain random bytes
from the operating system's CSPRNG. These practices are generally
considered good enough for strong cryptography, which demands as much from
a CSPRNG as PHP sessions.

It doesn't make sense to distrust random_bytes() but at the same time
trust the host PHP runs on.


>These things make me think collision detection is mandatory to say
>"PHP session is secure".
>
>Anyway, I'm not a cryptographer and just following their advices. I
>suggest you do the same.

I don't agree with the conclusions you draw from NIST hashing
recommendations.

Tom