Date: Thu, 28 Jan 2010 14:13:42 -0800 From: Chuck Swiger <cswiger@mac.com> To: Garance A Drosihn <drosih@rpi.edu> Cc: freebsd-security@freebsd.org Subject: Re: PHK's MD5 might not be slow enough anymore Message-ID: <75297887-C475-451D-B4A1-CB9D3A5BD2CA@mac.com> In-Reply-To: <p06240808c787b7763922@[128.113.24.47]> 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> <p06240808c787b7763922@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
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: > > $<ID>$<SALT>$<PWD> >> > [ ... ] > 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=<N>$ > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75297887-C475-451D-B4A1-CB9D3A5BD2CA>