Date: Thu, 21 Jun 2012 13:38:16 -0600 From: "Aaron D. Gifford" <astounding@gmail.com> To: freebsd-security@freebsd.org Subject: Re: Default password encryption method. Message-ID: <CAGDxMR7_wEus5zTpP8PNPkNrouO%2ByFu49J%2B%2BbzPN4ZfEkuhDtA@mail.gmail.com> In-Reply-To: <CAC8HS2FAzkLiN1Km-hCSWV9wWvm40tmqsA=61NDEA0WnnkswjQ@mail.gmail.com> References: <CAASvXNt7oT4g9YaNtMyheMkFyb_0ASfD-ErvCfJBRpuPqkrEwQ@mail.gmail.com> <CAJcQMWfrVbDUOp0-Qi48V0kBrwrHx8P98XX7U3NASLY08RKEmA@mail.gmail.com> <CAC8HS2FAzkLiN1Km-hCSWV9wWvm40tmqsA=61NDEA0WnnkswjQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 19, 2012 at 12:14 PM, Simon L. B. Nielsen <simon@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGDxMR7_wEus5zTpP8PNPkNrouO%2ByFu49J%2B%2BbzPN4ZfEkuhDtA>