Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72674 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 34394 invoked from network); 18 Feb 2014 04:11:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Feb 2014 04:11:20 -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.91 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.91 smtp91.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.91] ([108.166.43.91:50544] helo=smtp91.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4F/CD-64799-76DD2035 for ; Mon, 17 Feb 2014 23:11:19 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 6E6111407EB; Mon, 17 Feb 2014 23:11:16 -0500 (EST) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 16BAB1407D1; Mon, 17 Feb 2014 23:11:16 -0500 (EST) Message-ID: <5302DD63.1050704@sugarcrm.com> Date: Mon, 17 Feb 2014 20:11:15 -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 CC: "internals@lists.php.net" References: <5302ABF6.60407@sugarcrm.com> 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! > When "use_strict_mode=on", attacker sends short session ID many times to > see if the char matches part of session ID or not. When underlying data > storage is vulnerable to timing attack, timing is leaked. i.e. > stat(session_data_file_name) could be timing unsafe. Why would they send short ID if they could send full-length ID and easily defeat your checks? > htree is safe. Weak hash could be issue. Most of us remember hash > collision attack few years ago. (e.g mm save handler uses very simple Hash collistion attacks have nothing to do with this, they rely on the fact that hash we are using is not perfect and it is easy to generate colliding strings, thus producing degenerate performance. However, in this case we're talking about completely different scenario. > With minimum length, attacker must guess char combinations of that > length regardless of underlying session data storage. Not really. The whole point of timing attack is that the underlying mechanism must not use all chars of the string for comparison. > Minimum session ID length solves all issues/anxieties and we may leave > timing attack behind as long as users set appropriate value to it. I still don't see even one issue it solves. Timing attack would still work the same if underlying mechanism uses comparison where time of comparing aaaa to bbbb (assuming length is 4) if different from timing of comparing aaaa to aaab. Different length is not required here, and since length is public, it won't be the factor in the attack anyway. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227