Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:53592 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 58341 invoked from network); 27 Jun 2011 00:15:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Jun 2011 00:15:41 -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 207.97.245.143 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 207.97.245.143 smtp143.iad.emailsrvr.com Linux 2.6 Received: from [207.97.245.143] ([207.97.245.143:55099] helo=smtp143.iad.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 82/CF-01045-BD6C70E4 for ; Sun, 26 Jun 2011 19:55:10 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 976771A01A5; Sun, 26 Jun 2011 19:55:05 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp24.relay.iad1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 035311A01A3; Sun, 26 Jun 2011 19:55:04 -0400 (EDT) Message-ID: <4E07C6D8.7040509@sugarcrm.com> Date: Sun, 26 Jun 2011 16:55:04 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Pierre Joye CC: Rasmus Lerdorf , PHP internals References: <4E06EF9A.4030603@lerdorf.com> <4E07A696.2090602@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] todo: crypt_blowfish issue From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! On 6/26/11 4:31 PM, Pierre Joye wrote: > hi! > > I did not read the report, do you have the details about the breakage? > It could be acceptable in 5.3. The problem is that if the string has 8-bit chars in it, the hash ignores certain characters, making the password much less secure and generating high quantity of collisions. It also makes it incompatible with OpenBSD hashing, which may be lesser problem, depending on the use, and likely is, since nobody reported it beforehand. The solution implemented in the original patch and 5.4 is to fix the new hash and introduce a new hash type (starting with $2x and not with $2a as regular blowfish hash) that would use old, buggy hash type. This allows people that need to have password compatibility to have it at the cost of modifications on their data (which is possible without knowing the original passwords since only the prefix changes), while keeping the algorithm secure. However, it still has a chance somebody's data won't work after the update if he had 8-bit data hashed with old crypt(). He would need either to re-hash or to change prefix from $2a to $2x. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227