Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73347
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.43 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <532B482F.90207@sugarcrm.com>
References: <CAGa2bXYJqGqegGy=rYcDBXd8RmFFR9j=p2m63ZVSADoga+vwhg@mail.gmail.com>
 <5329E37C.5000106@sugarcrm.com> <CAGa2bXaDA=EhqgxZLqkBjTJqPyeogma1oC8L8NiTKx3WKp-rUg@mail.gmail.com>
 <532A43C5.309@sugarcrm.com> <CAGa2bXb74KKizUbN_CuEVJwOFDUBUBYe_6deWLk1A9CBhGHZbg@mail.gmail.com>
 <CAEZPtU4TaWSxnYqvceVKPgZJivheRK_M3ynpvasnh+a6+1ps0w@mail.gmail.com>
 <CAGa2bXbJNu0TxAD8FHuVs9nguwj1X=o4khV6FkqebMhU4y=QVg@mail.gmail.com> <532B482F.90207@sugarcrm.com>
Date: Fri, 21 Mar 2014 07:28:57 +0900
Message-ID: <CAGa2bXZXkWvHFXimFcbersWA8DrbZ-wG3N4-MhZSvCwYJYdFGA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Pierre Joye <pierre.php@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133a6020563b204f5114eac
Subject: Re: [PHP-DEV] [RFC] [Discussion] Secure session_regenerate_id()
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1133a6020563b204f5114eac
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Fri, Mar 21, 2014 at 4:57 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > Anyway, I don't want to write code that wouldn't be accepted.
> > I think "serializer wrapper" might be alternative choice. It works as
> > follows.
>
> As a PECL extension that provides configurable serializer option - sure,
> why not. As the part of the core - I don't see common enough use case.
> If this extension proves popular and everybody would be using it, we can
> merge it into core then.


It requires session module modification. Session module should have flag to
enable/disable
serializer wrapper, should pass additional parameters, should maintain
internal state.
I guess you mean PECL session manager extension. It may be a good start.

This way, I don't have write number of RFCs and care about
misunderstandings like
"Trying to solve that is unsolvable", "Excluding XHR is solution", etc. For
precise/secure
session management, not only session_regenerate_id() but also expiration
handling, etc
should be handled more strictly to be secure than now.

Current session module does not manage session precisely/securely. This is
true since
users _must_ write number of codes to manage session precisely. All of them
cannot be
performed by session manager. Example is how to handle exceptions. However,
most
of them can be done in session manager.

I choose session_regenerate_id() to discuss, since it is mandatory for
session security
and it is easy to understand what's wrong with it now. i.e. Which one is
secure
"Leave obsolete session indefinite period vs. Invalidate obsolete session
with certain period"
is clear to me. I think this is clear for you, too.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1133a6020563b204f5114eac--