Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92241
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.182 as permitted sender)
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
References: <CAGa2bXY3Zdrq-vU6_gCJVC3smP7DooBsKFNmQpz=ksdKsQORbQ@mail.gmail.com>
 <5706EEF3.3050705@gmail.com>
 <CAGa2bXbQkw2ouDJf5FHk3dbA4Xea4DmCwPdHUt_WRQ7H=EMAeQ@mail.gmail.com>
 <570D1E89.4050702@gmail.com>
 <CAGa2bXbjGuZ5R2hSAaVJSnQV_2zxtGLY4myOy3SaSXo4ppvABQ@mail.gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <570DC1EF.4010100@gmail.com>
Date: Tue, 12 Apr 2016 20:50:07 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbjGuZ5R2hSAaVJSnQV_2zxtGLY4myOy3SaSXo4ppvABQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Session ID without hashing
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> Yes and no.
> Patch uses php_random_bytes(), so it uses appropriate PRNG for the system.
> php_random_bytes() is supposed to be available always.

True, but is it always OK to export its state to anybody who asks, on
demand, in unlimited numbers? I'm not so sure.

> Experts say secure PRNG like /dev/urandom is safe.

What's "like /dev/urandom"? Each PRNG can have different properties.

> Why shouldn't?
> It's just a use case in the wild.

If you want to test use case, test on real application, not on
microbenchmark. And by real application I mean one currently used, of
which none regenerate session IDs on every request, and none have
reasons to. Optimizing for narrow use case which doesn't even exist yet
against thousands of apps that already do makes no sense to me.

> If time stamp based session management is used, there is no worries
> updating session ID on every request.

Of course there are worries, it would generate huge traffic to session
storage which is completely unnecessary. Moreover, many application
would be broken under such model. Of course, you are free to build your
own app using such model, but it's in no way a best practice and it does
not deserve to be target of global optimization of session module for it.

> Discussion is based on FUD.
> AFAIK, I saw papers state PRNGs are secure enough, but opposite.
> (We can safely ignore side channel attack issue, I suppose)

We can't claim both PRNG are secure and PRNG aren't secure. So which is it?

In any case, I don't see how this mandates turning on strict sessions. I
know you want it to be the default, but it doesn't seem to be related to
this topic.

> There is no BC.
> Removed INI are just ignored if users are used.

But users used them for something. If that something doesn't happen,
then it's broken.

> Question is "Current session ID is generation is optimal way?" or "Is it
> better than proposed one?" If so, why?

Yes, it's better - it does not export PRNG state needlessly, and it's
already proven to work by thousands of applications. I'm OK with adding
a non-hashed option, for people that want to try it out, and eventually
if everybody ends up using it and nothing bad happens, we could phase
out the hashed ones then. But just dropping them out of the blue and
making non-hashed the only option does not look like a good solution.

> Crypto experts say "secure PRNG is safe", why should we care too much
> about secure PRNG vulnerability? Why we should invent our own entropy
> added random value and take hash of it?

We should not invent our own PRNG. Hashing it though seems like a
reasonable precaution.
-- 
Stas Malyshev
smalyshev@gmail.com