Around 2012[1] we made the brave switch from md5crypt to sha512. Some people were asking for bcrypt to be default, and others were hoping we would see pbkdf2 support. We went with compatible. Additionally, making password hashing more In light of this new article[2] I would like to rehash (pun intended) this conversation and also mention a bug report[3] we've been sitting on in some form for 12 years[4] with usable code that would make working with password hashing algorithms easier and the rounds configurable by the admin. I'd also like to see us to pull in scrypt if cperciva doesn't have any objections. It's good to have options. PS: Why does "compatibility" matter for a default algorithm? Having a default different than Linux or Solaris isn't a bad thing as long as we implement the industry's common hashes which would permit any management tools twiddling the master.passwd manually to still be able to insert the password hashes in a common format... [1] https://lists.freebsd.org/pipermail/freebsd-security/2012-June/006271.html [2] https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/ [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182518 [4] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=75934 is the original report about the issue -- Mark Felder ports-secteam & portmgr member feld at FreeBSD.org
I recommend adding support for Argon2. https://en.wikipedia.org/wiki/Argon2 On Wed, May 23, 2018, 5:42 PM Mark Felder, <feld at freebsd.org> wrote:> Around 2012[1] we made the brave switch from md5crypt to sha512. Some > people were asking for bcrypt to be default, and others were hoping we > would see pbkdf2 support. We went with compatible. Additionally, making > password hashing more > > In light of this new article[2] I would like to rehash (pun intended) this > conversation and also mention a bug report[3] we've been sitting on in some > form for 12 years[4] with usable code that would make working with password > hashing algorithms easier and the rounds configurable by the admin. > > I'd also like to see us to pull in scrypt if cperciva doesn't have any > objections. It's good to have options. > > PS: Why does "compatibility" matter for a default algorithm? Having a > default different than Linux or Solaris isn't a bad thing as long as we > implement the industry's common hashes which would permit any management > tools twiddling the master.passwd manually to still be able to insert the > password hashes in a common format... > > [1] > https://lists.freebsd.org/pipermail/freebsd-security/2012-June/006271.html > [2] > https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/ > [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182518 > [4] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=75934 is the > original report about the issue > > -- > Mark Felder > ports-secteam & portmgr member > feld at FreeBSD.org > _______________________________________________ > freebsd-security at freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org > " >
On Wed, May 23, 2018, at 16:40, Mark Felder wrote:> Additionally, making password hashing more >Mailman came to the door and my barking dog interrupted my train of thought :-) I believe what I was going for was in reference to the bugzilla report, so I'll try again: Additionally, making password hashing more configurable/pluggable gives us more room to experiment with implementing new hashes and makes it easier to solve these problems. It appears that the patch languishing in bugzilla would help alleviate this issue. -- Mark Felder ports-secteam & portmgr member feld at FreeBSD.org
On 18-05-23 05:40 PM, Mark Felder wrote:> In light of this new article[2] I would like to rehash (pun intended) this conversation and also mention a bug report[3] we've been sitting on in some form for 12 years[4] with usable code that would make working with password hashing algorithms easier and the rounds configurable by the admin. > > [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182518I'd also like to add relevant reference to the public discussion regarding this patch: https://lists.freebsd.org/pipermail/freebsd-security/2015-February/008175.html (which also links to previous discussion on -current) as some additional context at this time. Derek
Mark Felder wrote this message on Wed, May 23, 2018 at 16:40 -0500:> Around 2012[1] we made the brave switch from md5crypt to sha512. Some people were asking for bcrypt to be default, and others were hoping we would see pbkdf2 support. We went with compatible. Additionally, making password hashing more > > In light of this new article[2] I would like to rehash (pun intended) this conversation and also mention a bug report[3] we've been sitting on in some form for 12 years[4] with usable code that would make working with password hashing algorithms easier and the rounds configurable by the admin.I'd like to see it set where we set a time, say 50ms or so, and on each boot, we set the rounds based upon this. (obviously configurable), w/ a minimum maybe for slower systems... This allows us to autoscale to faster cpu systems... I believe that there are patches/review for making the default password hash algorithm configurable via login.conf or something similar.. so some of the work has already been done..> I'd also like to see us to pull in scrypt if cperciva doesn't have any objections. It's good to have options.Yes, pulling in scrypt and/or argon2 is a great idea... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
> > I believe that there are patches/review for making the default password > hash algorithm configurable via login.conf or something similar.. so some > of the work has already been done.. > > > I'd also like to see us to pull in scrypt if cperciva doesn't have any objections. It's good to have options. > > Yes, pulling in scrypt and/or argon2 is a great idea... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-security at freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"Dag-Erling Smrgrav wrote this message on Thu, May 31, 2018 at 00:38 +0200:> John-Mark Gurney <jmg at funkthat.com> writes: > > I believe that there are patches/review for making the default password > > hash algorithm configurable via login.conf or something similar... > > You mean like r64918?No, I don't. Sorry, I wasn't specific enough in my comment, but you also dropped the context of that statment: John-Mark Gurney wrote this message on Sun, May 27, 2018 at 16:14 -0700:> Mark Felder wrote this message on Wed, May 23, 2018 at 16:40 -0500: > > In light of this new article[2] I would like to rehash (pun intended) this conversation and also mention a bug report[3] we've been sitting on in some form for 12 years[4] with usable code that would make working with password hashing algorithms easier and the rounds configurable by the admin. > > I'd like to see it set where we set a time, say 50ms or so, and on each > boot, we set the rounds based upon this. (obviously configurable), w/ a > minimum maybe for slower systems... This allows us to autoscale to faster > cpu systems...r64918 does not allow you to set default number of rounds... there is a patch in bugzilla or phabricator that allows you to set this.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."