Fwd: Default password encryption method.

[Aaron Zauner]

so what about bcrypt?

http://en.wikipedia.org/wiki/Bcrypt

On Thu, Jun 21, 2012 at 7:38 PM, Aaron D. Gifford <astounding at gmail.com> wrote:
> On Tue, Jun 19, 2012 at 12:14 PM, Simon L. B. Nielsen <simon at freebsd.org> 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.
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"