Default password hash, redux

[Mark Felder]

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
fe...@FreeBSD.org
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[Yonas Yanfa]

I recommend adding support for Argon2.

https://en.wikipedia.org/wiki/Argon2

[Mark Felder]

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.

[Benjamin Kaduk]

On Wed, May 23, 2018 at 05:50:04PM -0400, Yonas Yanfa wrote:
> I recommend adding support for Argon2.
>
> https://en.wikipedia.org/wiki/Argon2

Yes, Argon2 seems like a no-brainer at this point.

-Ben

[Derek (freebsd lists)]

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=182518

I'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

[John-Mark Gurney]

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."

[Dag-Erling Smørgrav]

John-Mark Gurney <j...@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?

DES
--
Dag-Erling Smørgrav - d...@des.no

[John-Mark Gurney]

>
> 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-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

Dag-Erling Smrgrav wrote this message on Thu, May 31, 2018 at 00:38 +0200:

> John-Mark Gurney <j...@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..