Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94379
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.161.170 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZ=DiqQ4PozYntvGApZHdkjWyTBQhk_Udy5Y3_m0ry9Lw@mail.gmail.com>
References: <CAGa2bXaSkozJLLtycujwmHyas9TofRw5s6JzG0EQQvPyU0pxNQ@mail.gmail.com>
 <CAGa2bXZ=DiqQ4PozYntvGApZHdkjWyTBQhk_Udy5Y3_m0ry9Lw@mail.gmail.com>
Date: Tue, 5 Jul 2016 01:36:07 +0100
Message-ID: <CA+kxMuQT=XMSGuJ2jen9-8AzpdMdTTD5+uw67tEn6eTT2favvA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>, Dan Ackroyd <danack@php.net>, 
	Stanislav Malyshev <smalyshev@gmail.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [RFC][VOTE] Session ID without hashing
From: danack@basereality.com (Dan Ackroyd)

Hi Yasuo,

> Could you share the reason why against this change?

The RFC is doing separate things:

* Using a proper random number generator - which is probably a good
thing, and I probably would vote/support that change by itself.

* Removing old stuff for performance reasons - probably a bad thing,
as minor performance improvements don't justify changing the ini
settings imo.

* Slipping in a change to make 'session.use_strict_mode' be enbled by
default. I actually agree with this change, but I don't like how it's
been combined into an unrelated RFC.

* Exposing information that could be useful to an attacker, from the RFC:

> If PRNG has vulnerability that generates predictable value, exposing
> raw PRNG state helps attackers. Although, this is unlikely with modern PRNGs, but
> risk is there.

I don't agree that faster session generation is worth exposing the
random number generator in a completely known way to the outside
world. Reading an extra 60 bytes almost certainly does nothing to
mitigate that exposure.

> cryptographers recommends
> not to reinvent crypt related functions/features.

They also recommend reducing your attack surface as much as possible,
not opening it up to the point where you're relying on the CSPRNG to
work perfectly to avoid having a security hole.

But more importantly, as I wrote before
(http://news.php.net/php.internals/90940) I don't think the session
extension is in a state where incremental improvements are a good way
to proceed:

> The problem is that you're trying to build on a foundation of sand.
> The session handling works but is incredibly fragile.

> To me, there are two good ways to proceed:

> i) Develop a new session extension, that doesn't depend on magic
> behaviour of globals and leave the current session handler as it is.
> The new session extension could be shipped as a 'work in progress' when
> it's good enough, before PHP 8. Then when it's stable, we could figure
> out how to transition users from the old extension.
>
> ii) Develop a session handler in userland code only. PHP is powerful
> enough to support this. Although obviously there are big benefits to
> shipping a session handler with PHP, I don't see any need for it to be
> done internally other than we don't currently have a way of shipping
> userland code with an extension. I'm hoping that before PHP 8, the
> ability to ship PHP code as part of extensions would be in place.

cheers
Dan