From owner-freebsd-security@FreeBSD.ORG Thu Jan 28 22:13:49 2010 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 457AE106568B for ; Thu, 28 Jan 2010 22:13:49 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2BF898FC18 for ; Thu, 28 Jan 2010 22:13:49 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp023.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KWZ00FHC9QU8160@asmtp023.mac.com> for freebsd-security@freebsd.org; Thu, 28 Jan 2010 14:13:43 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1001280197 From: Chuck Swiger In-reply-to: Date: Thu, 28 Jan 2010 14:13:42 -0800 Message-id: <75297887-C475-451D-B4A1-CB9D3A5BD2CA@mac.com> References: <20100128182413.GI892@noncombatant.org> <20100128135410.7b6fe154.wmoran@collaborativefusion.com> <20100128193941.GK892@noncombatant.org> <20100128151026.5738b6c1.wmoran@collaborativefusion.com> <20100128201857.GP892@noncombatant.org> <4B61FCFF.6040207@delphij.net> To: Garance A Drosihn X-Mailer: Apple Mail (2.1077) Cc: freebsd-security@freebsd.org Subject: Re: PHK's MD5 might not be slow enough anymore X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 22:13:49 -0000 Hi-- On Jan 28, 2010, at 1:56 PM, Garance A Drosihn wrote: >> On 2010/01/28 12:18, Chris Palmer wrote: >>> For backwards compatibility, which do people prefer: Creating a new $N$ >>> prefix every time we re-tune the algorithm, or using a new notation to say >>> how many times this password was hashed? For example: $1.1000$, $1.100000$, >>> et c.? >> >> I'd vote for $1.nnnn$, as a good side effect it would be tunable by the >> administrators who want to fine tune the round number as need. > > Might want to make it something like $1.nnn.bbb$, so the admin can specify > the number of bits as well as the number of rounds. And then pick some > algorithm where those two values make sense. :-) As Antoine points out in the link mentioned: > The integration into existing systems is easy if those systems already > support the MD5-based solution. Ever since the introduction of the > MD5-based method an extended password format is in used: > > $$$ >> > [ ... ] > For the SHA-based methods the SALT string can be a simple string of > which up to 16 characters are used. The MD5-based implementation used > up to eight characters.. It was decided to allow one extension which > follows an invention Sun implemented in their pluggable crypt > implementation. If the SALT strings starts with > > rounds=$ > > where N is an unsigned decimal number the numeric value of N is used > to modify the algorithm used. As will be explained later, the > SHA-based algorithm contains a loop which can be run an arbitrary > number of times. The more rounds are performed the higher the CPU > requirements are. This is a safety mechanism which might help > countering brute-force attacks in the face of increasing computing > power. > > The default number of rounds for both algorithms is 5000. To ensure > minimal security and stability on the other hand minimum and maximum > values for N are enforced: > > minimum for N = 1,000 > maximum for N = 999,999,999 > > Any selection of N below the minimum will cause the use of 1,000 > rounds and a value of 1 billion and higher will cause 999,999,999 > rounds to be used. In these cases the output string produced by the > crypt function will not have the same salt as the input salt string > since the correct, limited rounds value is used in the output. This seems to address the suggestion being made by Chris (and +1'ed by others) in a fashion that is compatible with other implementations.... Regards, -- -Chuck