Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73327 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78461 invoked from network); 20 Mar 2014 09:13:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Mar 2014 09:13:30 -0000 Authentication-Results: pb1.pair.com header.from=shm@digitalsun.pl; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=shm@digitalsun.pl; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain digitalsun.pl from 176.31.254.40 cause and error) X-PHP-List-Original-Sender: shm@digitalsun.pl X-Host-Fingerprint: 176.31.254.40 turing.digitalsun.pl Received: from [176.31.254.40] ([176.31.254.40:60990] helo=mail) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F6/A7-33112-931BA235 for ; Thu, 20 Mar 2014 04:13:30 -0500 Received: from localhost (10000@localhost [local]); by mail (OpenSMTPD) with ESMTPA id fdc8a564; Thu, 20 Mar 2014 09:13:26 +0000 (UTC) Date: Thu, 20 Mar 2014 09:13:26 +0000 To: Yasuo Ohgaki Cc: "internals@lists.php.net" Message-ID: <20140320091326.GA65574@mail> References: <20140319080229.GA83863@mail> <20140319111131.GB83863@mail> <20140320082346.GA61204@mail> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Thu, Mar 20, 2014 at 05:30:36PM +0900, Yasuo Ohgaki wrote: > Hi Mateusz, > > On Thu, Mar 20, 2014 at 5:23 PM, Mateusz Kocielski wrote: > > > > > I agree. But we've got more factors here, it's not a simple tool for > > > > detection > > > > of crimes. If we let "old session" live for x secs, what will happen to > > > > changes done to the old session? How do you want to resolve that? We > > should > > > > find a balance between complexity and security. > > > > > > > > > > > Currently we have poor mitigation. My proposal provides better > > mitigation. > > > > I still don't see how you want to handle inconsistency between sessions. It > > seems that your RFC silently ignores that issue. > > > I'm not sure which inconsistency. Could you specify/describe it? Consider following scenario: 1. session_regenerate_id(..) is called 2. request to /update_session with old session id is done (some key-value in session is changed) - with your change this request will succeed --- from here user uses only new session - 3. updated key-value is missing in new session (same scenario can be triggered now if old session is not deleted) Kind Regards, Mateusz Kocielski