so what about bcrypt? http://en.wikipedia.org/wiki/Bcrypt
On Thu, Jun 21, 2012 at 7:38 PM, Aaron D. Gifford <[email protected]> wrote: > On Tue, Jun 19, 2012 at 12:14 PM, Simon L. B. Nielsen <[email protected]> > wrote: > ..snip... >> The FreeBSD Security Team is also looking at (/poking people to look at) >> solutions which will improve the the time it takes to brute force passwords >> significantly more. >> >> -- >> Simon > > I'd love to see PBKDF2 as a password hashing method. Yes, it's meant > for deriving key material, but it can function similarly. It has the > flexibility of allowing different hashes being used for the HMAC PRNG > portion, and the ability to vary/specify the number of iterations. > No, it's not memory complex like scrypt, but personally I prefer to > not yet have memory usage involved. I could foresee PBKDF-HMAC-SHA512 > or PBKDF-HMAC-SHA256. I would select the quantity of output to match > the hash size selected (i.e. if I use HMAC-SHA512 for the PRNG portion > of PBKDF2, I would have PBKDF2 generate 512 bits of output to store in > my password database). > > PBKDF2(pseudo-random-function, password, salt, iterations, output-size) > > I'd offer HMAC-SHA256 and HMAC-SHA512 initially for the > pseudo-random-function parameter. > > And I'd select output-size as mentioned above, 256 bits for HMAC-SHA256, etc. > > As for iterations, how hard would it be to allow for more variation in > the base-64 encoded salt field in the master password database such > that for a PBKDF2 scheme, the field used as salt would actually be > three fields, an 4-bit pseudo-random-function selector and a 32-bit > unsigned integer number of iterations (or 36 bits, which base-64 > encoded would be 6 characters) followed by a variable length salt > (i.e. any length permitted by the master password database structure > up to the '$' character delimiter)? > > Or one could simply define separate algorithms for each PRF > (pseudo-random-function) available. > > But, storing the number of iterations with the stored salt has the > benefit of not requiring a new algorithm be defined when one wants to > increase the default security level of hashed passwords. One merely > need to change a system setting to default to use more iterations. > And password databases from other systems with a higher or lower > setting would still be readable and usable. > > Brainstorming session over... for now. > > Aaron out. > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "[email protected]" _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"
