Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91891
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain paragonie.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CABHuAWzwxRQxohRca8MvChs4ZdHNk-xc9P5HW93dzkq1TRztoQ@mail.gmail.com>
References: <CAGa2bXauwspEZ4HYSHgVOyd+VEvKxoymWYFPG6NaOdCa+APfKQ@mail.gmail.com>
	<CABHuAWzwxRQxohRca8MvChs4ZdHNk-xc9P5HW93dzkq1TRztoQ@mail.gmail.com>
Date: Thu, 24 Mar 2016 10:43:12 -0400
Message-ID: <CAKws9z1ihtDyyDQORzs_gJVcOA7Z=A5QzgBf6w1UoP3pd2Ab6A@mail.gmail.com>
To: Chris Riley <t.carnage@gmail.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133423e44673b052ecc773c
Subject: Re: [PHP-DEV] [RFC][Discussion] Precise session data management
From: scott@paragonie.com (Scott Arciszewski)

--001a1133423e44673b052ecc773c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 24, 2016 at 9:55 AM, Chris Riley <t.carnage@gmail.com> wrote:

> 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 t=
o
> 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 crypt=
o
> 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 sessio=
n
> 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 destroy=
ed
> 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 th=
e
> race condition issue.
>

Could we also add HTTPS detection and enable the secure flag by default
when a session is established on an HTTPS endpoint?

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
=E2=80=8B

--001a1133423e44673b052ecc773c--