-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/07/14 14:50, A.J. Kehoe IV (Nanoman) wrote: > Xin Li wrote: >> Hi, >> >> On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote: >>> Allan Jude wrote: >>>> On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote: >>>>> Allan Jude wrote: >>>>> >>>>> [...] >>>>> >>>>>> Honestly, my use case is just silently upgrading the >>>>>> strength of the hashing algorithm (when combined with my >>>>>> other feature request). Updating my bcrypt hashes from >>>>>> $2a$04$ to $2b$12$ or something. Same applies for the >>>>>> default sha512, maybe I want to update to rounds=15000 >>>>> >>>>> Like this? >>>>> >>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=182518 >>>>> >>>>> Request for comments: >>>>> >>>>> http://docs.freebsd.org/cgi/mid.cgi?20140106205156.GD4903 > > [...] > >> Speaking for adding rounds, the only problem that needs to be >> fixed is that the proposed patch makes it possible to create >> conflicting configuration (passwd_format and passwd_modular can >> use different hashing algorithms) and need to be fixed and >> polished. I like the idea of making it possible to use more >> rounds though. > > This was deliberate for backward compatibility. passwd_format will > be used by default if passwd_modular isn't defined. If > passwd_modular is defined as "disabled", then passwd_format will be > used.
Well, my point is that the two shouldn't be allowed to exist together if they can mean something conflicting. Allowing passwd_format=sha512 AND passwd_modular=$2a$08$ in the same configuration creates confusion and it's not good. My suggestion is that we either have: a) passwd_format and passwd_round (so that they don't conflict), or b) extend passwd_format in a compatible manner to allow specifying a round, or, c) make passwd_format and passwd_modular conflict so we don't silently accept it and instead bail out when doing pwd_mkdb. > What do you think of the idea of putting this into libcrypt instead > of pam_unix.c, and then patching pam_unix.c and pw_user.c to > reference libcrypt? Which part of the idea? I think it's a bad idea to make libcrypt to depend on libutil (for login_cap(3)) but we should probably provide new wrappers in login_cap(3) to do the common things when requested for various password manipulating tools to reduce duplicated code. Cheers, - -- Xin LI <delp...@delphij.net> https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTGmYMAAoJEJW2GBstM+nsDJ8QAJ+SM9WuRCXo1KYERj+/NJsC VoP8psjZDZ7+hGOnG7iSwREYTLpxSEAw+sPnIhMgEy1Tg5jCcPvnIhCN/n+XPvaR HG0o0TdTXL5ZVU4HyKuhNH6JGF9sWWua7Ki/jFguqE+1rdmivcbhrHMZNqOy8Djc N/dnoCD/eN8K2/FiwP+KjTsYeSyisKFMyiGimQNcuPA7boF4ZBgJmmJqPASHzO9M DVccoVPrDUip/6BdM+CNx/rNTry1sW3lMFSAuJkx+LENgulbhFz5R0aRGglzwGnJ LocXVCZlTv0QB37qp9VIHCtTO5n8GxOx43dEtgjWF1cjDs+s+iKjEylX8NguUi0x SjYu5WOw8xXNdE48QtqpT0N5aHSw9+CCwbrocGaOVYy11voGzo+r3C7jXprhQl8a pgeiXH5pyBpo9Eh7+/aZdN3WcBjpaOVDnX8We7A9my1lVjxyuLXFyhC3q2OqUjvl dX4ywKIjiFHSOz0ivzi+uQPx6PD05UuyrWUDING2PvMD/oMtg/hHbR5IxOHdmgPq j7brHNOk7gxu1f/NFft/yfJAKem6JXjlX68z6/9jMrwxZ8jwTWWAtHrVBjo9/u2i 7ShSZlsEi62GewoIKRRVKvKmdX7Xl+Of/p/DZMTNGCJ9K5NnhEnLKWSp+I5VF0LN fVQkTqpRaXglMVa/iRkG =xSx1 -----END PGP SIGNATURE----- _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"