Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73322 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 68082 invoked from network); 20 Mar 2014 08:23:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Mar 2014 08:23:51 -0000 Authentication-Results: pb1.pair.com smtp.mail=shm@digitalsun.pl; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=shm@digitalsun.pl; 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:58244] helo=mail) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3D/75-33112-595AA235 for ; Thu, 20 Mar 2014 03:23:51 -0500 Received: from localhost (10000@localhost [local]); by mail (OpenSMTPD) with ESMTPA id 1db281ab; Thu, 20 Mar 2014 08:23:46 +0000 (UTC) Date: Thu, 20 Mar 2014 08:23:46 +0000 To: Yasuo Ohgaki Cc: "internals@lists.php.net" Message-ID: <20140320082346.GA61204@mail> References: <20140319080229.GA83863@mail> <20140319111131.GB83863@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 03:33:09AM +0900, Yasuo Ohgaki 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. Kind Regards, Mateusz Kocielski