Hello, By default FreeBSD uses MD5 to encrypt passwords. MD5 is believed to be more secure than e.g. DES but less than e.g. SHA512. Currently several major Linux distributions, uses a SHA512 mechanism. Suse Linux also offers a blowfish. Some Debian based distributions use MD5-based algorithm compatible with the one used by recent releases of FreeBSD - but mostly this variable (* MD5_CRYPT_ENAB*) is deprecated, and SHA512-based algorithm is used. Of course, in FreeBSD we can change the MD5 for example to BLF, but, it will be not a better solution to use SHA512 by default?
On Tue, Jun 19, 2012 at 10:10 AM, ian ivy <sidetripping@gmail.com> wrote:> Hello, > > By default FreeBSD uses MD5 to encrypt passwords. MD5 is believed to be > more secure than e.g. DES but less than e.g. SHA512. Currently several > major Linux distributions, uses a SHA512 mechanism. Suse Linux also offers > a blowfish. > > Some Debian based distributions use MD5-based algorithm compatible with the > one > used by recent releases of FreeBSD - but mostly this variable (* > MD5_CRYPT_ENAB*) > is deprecated, and SHA512-based algorithm is used. > > Of course, in FreeBSD we can change the MD5 for example to BLF, > but, it will be not a better solution to use SHA512 by default?This has been discussed recently in the following thread: http://lists.freebsd.org/pipermail/freebsd-security/2012-June/006271.html - Max
On Jun 19, 2012 3:16 PM, "Maxim Khitrov" <max@mxcrypt.com> wrote:> > On Tue, Jun 19, 2012 at 10:10 AM, ian ivy <sidetripping@gmail.com> wrote: > > Hello, > > > > By default FreeBSD uses MD5 to encrypt passwords. MD5 is believed to be > > more secure than e.g. DES but less than e.g. SHA512. Currently several > > major Linux distributions, uses a SHA512 mechanism. Suse Linux alsooffers> > a blowfish. > > > > Some Debian based distributions use MD5-based algorithm compatible withthe> > one > > used by recent releases of FreeBSD - but mostly this variable (* > > MD5_CRYPT_ENAB*) > > is deprecated, and SHA512-based algorithm is used. > > > > Of course, in FreeBSD we can change the MD5 for example to BLF, > > but, it will be not a better solution to use SHA512 by default? > > This has been discussed recently in the following thread: > > http://lists.freebsd.org/pipermail/freebsd-security/2012-June/006271.htmlThe 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
Hi Max, Thanks for the link. I did not notice, that it was already discussed. Best regards!
so what about bcrypt? http://en.wikipedia.org/wiki/Bcrypt On Thu, Jun 21, 2012 at 7:38 PM, Aaron D. Gifford <astounding@gmail.com> wrote:> 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. > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
On 6/19/2012 10:10 AM, ian ivy wrote:> By default FreeBSD uses MD5 to encrypt passwords. MD5 is believed to be > more secure than e.g. DES but less than e.g. SHA512. Currently several > major Linux distributions, uses a SHA512 mechanism. Suse Linux also offers > a blowfish.A late followup to this thread, but there was a decent fleshed out article on this issue http://arstechnica.com/security/2012/08/passwords-under-assault/ There are a few caveats/clarifications in the comments, but pretty good overall for a non hardcore crypto audience. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/