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 _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
