Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73314 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 40172 invoked from network); 20 Mar 2014 01:26:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Mar 2014 01:26:33 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.67 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.67 smtp67.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.67] ([108.166.43.67:37167] helo=smtp67.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3D/71-33112-8C34A235 for ; Wed, 19 Mar 2014 20:26:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 2295C149274; Wed, 19 Mar 2014 21:26:30 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id D2D251491D1; Wed, 19 Mar 2014 21:26:29 -0400 (EDT) Message-ID: <532A43C5.309@sugarcrm.com> Date: Wed, 19 Mar 2014 18:26:29 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Yasuo Ohgaki CC: "internals@lists.php.net" References: <5329E37C.5000106@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] [Discussion] Secure session_regenerate_id() From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > I'm recognizing reliability/availability as a part of security. > ISO 27000 defines it's a part of security. Let's not parse semantics here. Declaring something that is not security issue - i.e. would not lead to unauthorized access, data disclosure, etc. - as security issue only makes real security issues drown in the noise and not get proper priority. And mislead people into thinking that existing ways - which are fine - are somehow insecure and make them not use them. > Secure behavior by default is the way to go. IMO. > There are too many pitfalls in web application. We should try to > mitigate them > as many as possible where it could be done. We're not implementing web application in the engine. It's the task for the developers and libraries. Implementing something that can easily be implemented in userspace in the core only makes it less flexible and makes core more heavy to maintain. We're not really saving much code there - in fact, we're adding more code as now the developer has to deal with exceptions. If the session would be silently deleted, it would probably be ok, even though still a narrow use case whcih I don't think should be in the engine, but throwing hard errors doesn't look useful at all. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227