Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73297
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain digitalsun.pl from 176.31.254.40 cause and error)
Date: Wed, 19 Mar 2014 08:02:29 +0000
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <20140319080229.GA83863@mail>
References: <CAGa2bXYJqGqegGy=rYcDBXd8RmFFR9j=p2m63ZVSADoga+vwhg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAGa2bXYJqGqegGy=rYcDBXd8RmFFR9j=p2m63ZVSADoga+vwhg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [PHP-DEV] [RFC] [Discussion] Secure session_regenerate_id()
From: shm@digitalsun.pl (Mateusz Kocielski)

On Wed, Mar 19, 2014 at 04:12:54PM +0900, Yasuo Ohgaki wrote:
> HI all,
> 
> I think most of concerns for session_regenerate_id() is discussed.
> I would like to finish this RFC.
> 
> Following RFC was made to change session_regenerate_id(TRUE) by default.
> I was initially tried to remove old session data immediately with this RFC,
> but
> it turned out we should care about reliability more in real world
> environment.
> 
> Secure session_regenerate_id()
> https://wiki.php.net/rfc/session_regenerate_id
> 
> The time stamp could be outside of of $_SESSION. It requires BC
> modification in
> serializer and/or save handler. It would be complex and possibly slower
> depend
> on implementation.
> 
> I hope it's precise enough and easy to understand idea behind it.
> If you have suggestions, it would be appreciated.
> Names can be anything, especially.
> 
> If I'm missing something, please let me know.

Hi Yasuo,

[...]
Errors may be raised for either legitimate user or attacker. If error is
raised for legitimate user, legitimate user could know they are under attack.
(Possibly network is dangerous or app has vulnerability) If error is raised
for attacker, attacker could know they might be caught by illegal access. 
[...]

I wonder how many legitimate users will realize they're under attack. For
average user it will look like application does weird things (i.e. logout
immediately). If network is dangerous or app has vulnerability then we cannot
fix the problem - you can't make n-th layer secure if (n-1)-th layer is
insecure.

[...]
Stealing session ID is easy regardless of HTTPS. Attacker can set up fake
router by ARP spoofing. Most networks do not have ARP spoofing prevention,
even detection. For HTTP, attacker can view session ID simply. For HTTPS,
attacker can set up transparent HTTPS stripping proxy and steal session ID.
Most users do not care much if they are connecting via HTTPS or not. 
[...]

What if application uses secure attribute on session cookie? We've got already
session.cookie_secure setting which seems to solve the issue. I don't see how
by introducing your proposal will make situation better. If application allows
login and operates as user without HTTPS, then it's not our problem.

[...]
 Problem of immediate old session deletion:

    Make session ID regeneration unreliable. (Unacceptable)
[...]

I haven't found single issue in
bugs.php.net that session_regenerate_id(TRUE) is a problem to any user.

[...]
    Remove alarm for possible attacks. (No detection = Insecure)
Make sure old session is deleted certain period and Raise
error/exception for invalid access provides much better security than
current way or immediate deletion. 
[...]

 What you mean by "No detection = Insecure"?

Kind Regrads,
Mateusz Kocielski