Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72671 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 20772 invoked from network); 18 Feb 2014 00:40:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Feb 2014 00:40:28 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.99 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.99 smtp99.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.99] ([108.166.43.99:32834] helo=smtp99.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 54/5B-64799-BFBA2035 for ; Mon, 17 Feb 2014 19:40:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id A96D31B0AA6; Mon, 17 Feb 2014 19:40:23 -0500 (EST) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 33BC21B0B56; Mon, 17 Feb 2014 19:40:23 -0500 (EST) Message-ID: <5302ABF6.60407@sugarcrm.com> Date: Mon, 17 Feb 2014 16:40:22 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Yasuo Ohgaki , Andrey Andreev CC: "internals@lists.php.net" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE] Secure Session Module Options/Internal by Default From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Length check is trivial, then why not check and discard by module instead I don't really understand - what is the point of checking length? If you have session adoption problem, checking length won't help since the length is public. If you don't have this problem, checking length adds nothing since the session won't be valid anyway. So why add code that contributes nothing? Maybe I do not see some contribution, if so, please explain. > There is threat and it could be removed with length check. > Let's have the check and forget about timing attack! But there's no actual real-world threat - there is an imagined scenario which requires use of antique filesystems with very specific and unobvious properties (namely, directories stored sorted by name and having linear checks), and even in this case length check does not help, since again, session ID length is public and so nothing prevents one from using the correct length from the start. So length check does not fix the timing attack even in the unlikely case such attack would actually exist. It's like putting a locked door in an open field, and claiming it protects from robbers, despite there being nothing to be robbed and the door can be easily walked around. I really don't see a point here, especially as a user setting. I could see it as an internal check - defensive coding and all - where length is pre-calculated and checked internally. This is fine - but as a user setting that inevitably will be set wrong and cause trouble - I just don't see the point. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227