Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91890
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXauwspEZ4HYSHgVOyd+VEvKxoymWYFPG6NaOdCa+APfKQ@mail.gmail.com>
References: <CAGa2bXauwspEZ4HYSHgVOyd+VEvKxoymWYFPG6NaOdCa+APfKQ@mail.gmail.com>
Date: Thu, 24 Mar 2016 13:55:31 +0000
Message-ID: <CABHuAWzwxRQxohRca8MvChs4ZdHNk-xc9P5HW93dzkq1TRztoQ@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113c80d4b5337f052ecbcc1f
Subject: Re: [PHP-DEV] [RFC][Discussion] Precise session data management
From: t.carnage@gmail.com (Chris Riley)

--001a113c80d4b5337f052ecbcc1f
Content-Type: text/plain; charset=UTF-8

On 24 March 2016 at 02:34, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi all,
>
> Since the vote for
> https://wiki.php.net/rfc/precise_session_management
> is declined 15 vs 11.
> https://wiki.php.net/rfc/precise_session_management#vote
>
> We have to come up with other solutions for
>
>  - Session loss by race conditions
>  - Method to make session abuse harder
>
> I'm open to implement better solution than proposed RFC.
>
> These issues are serious issues that cannot be ignored.
> Looking forward alternative implementation ideas!
>
> Thank you.
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I'm disappointed this RFC failed as improving session security should be a
high priority. I'd propose that we focus on items which will improve
session security overall. This jumped out at me to start with: "This RFC also
includes minor security improvements like httponly cookie, better hash
function."

Perhaps a first RFC for improving session security can start with those
items: Set the session cookie to be httponly (or provide an ini setting to
do so, defaulting to on) instead of using a better hash function for the
session id, why not generate it from random_bytes()? Then the id is crypto
secure.

I'd then consider a second RFC setting out the extra internal data that
would be required to kill off old sessions correctly. That would require to
keys under ['__PHP__SESSION__'] (could the key name be an ini setting to
preserve BC?) 'destroyed' and 'expires', the latter would be a bool flag
stating if the session had been explicitly destroyed. (A destroyed session
could no longer be used, could throw an exception or just have no data in
it) the expires key would be used in a similar manner, being set to
Time+cookie expiry time on each read/write to the session. (again an
expired session would not be accessible and would function like a destroyed
one)

The combination of the two would resolve most of the security issues and
establish the __PHP__SESSION__ key which could later be used to handle the
race condition issue.

--001a113c80d4b5337f052ecbcc1f--