Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94671
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: <CANaX5nccP6LBVow1oaO6jzU0PRjaruRSjdhiZ8kb=071gpiUTA@mail.gmail.com>
References: <CAGa2bXZn5HiOD6LsotYDmUJKhGxxpp0xTsMSE2bp5HO0fsCmtA@mail.gmail.com>
 <CANaX5nccP6LBVow1oaO6jzU0PRjaruRSjdhiZ8kb=071gpiUTA@mail.gmail.com>
Date: Sun, 24 Jul 2016 16:57:07 +0900
Message-ID: <CAGa2bXbnE5hwGksOb6-_1Q0aas63hyLOf6GTse+VPELA9bM=4w@mail.gmail.com>
To: Davey Shafik <davey@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][VOTE] Session ID without hashing - Reopened
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Davey,

On Sun, Jul 24, 2016 at 3:33 PM, Davey Shafik <davey@php.net> wrote:
> Just wanted to let you know I voted no because of the BC breaking change =
to
> the INI options that could easily break many custom session handlers =E2=
=80=94 any
> session handler that stores the sessions in a fixed-width column will be
> broken.
>
> I'm fine changing the defaults in the php.ini-*, but not changing the
> defaults in the code. Also, documenting the better values as recommended.
>
> Putting my RM hat on, I'm not comfortable merging this in 7.1 with an
> unnecessary BC breaking change. Changing the default is the BC break,
> regardless of the _ability_ to change the settings back to the previous
> values.

Fair discussion. I can understand very well.

The reason why I would like to increase number of bits in session ID is thi=
s.
https://www.owasp.org/index.php/Insufficient_Session-ID_Length
It suggests at least 128 bits session ID that includes at least 64 bits ent=
ropy.

We may assume very good entropy for current MD5 style session ID
string  (128 bits) with CSPRNG. It's not safe to assume fully random
bytes, let's assume 80 bits entropy. 80 bits entropy is strong
enough for most sites, but there were concerns about quality of PRNG
during discussion.

80 bits entropy for MD5 style session ID string and a web site

 - Allows 1K reqs/sec
 - 10M active sessions in system

It requires 1916739 years to guess a session ID on average.

Now, let assume bad PRNG only generates only 48 bits entropy for MD5
style session ID string and a web site

 - Allows 1K reqs/sec
 - 10M active sessions in system

It requires 14073 seconds to guess a session ID on average.

NOTE: If PRNG is bad like this, current way will results in the same
bad situation or worse. The proposed way is better.

Personally, I don't think any PRNG claims as CSPRNG would not generate
such bad random bytes, but the default is extended to 240 bits session
ID string for this reason. It should be very strong even with poor
PRNG and good enough for billions of active sessions and tens of
thousands guesses per/second.

I don't mind pausing vote to have consensus on how many bits for
session ID string is preferred.

Regards,

YFI. Current session module has collision detection when proper API is
implemented. Therefore, there is _no_ chance a user gets a session ID
owned by someone else.

--
Yasuo Ohgaki
yohgaki@ohgaki.net