A.J. Kehoe IV (Nanoman) wrote this message on Mon, Mar 10, 2014 at 18:12 -0400: > Derek (freebsd lists) wrote: > > [...] > > >On 03/07/2014 07:36 PM, Xin Li wrote: > >>On 03/07/14 14:50, A.J. Kehoe IV (Nanoman) wrote: > >>>Xin Li 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 > > [...] > > >My reasons for this were first to see if there was any interest > >from a committer to take this further. Much more likely to have > >a 15 or so line patch looked at, than one that touches stuff all > >over the place - I think. > > > >We are now at least having a conversation about it. > > > >It seemed to be a lot of work to specify rounds via > >login_setcryptfmt, with a bunch of changes also required in > >libcrypt. > > > >I don't have the resources to test for regressions in libcrypt, > >beyond the scope of whether login.conf works as expected > >(specifically, the ports tree, yp, ldap, or any other areas that > >I don't know about). > > > >If other developers were willing to work together on the api/abi > >changes, I would feel a lot better about spending my time there > >and doing it right. Without support from other, more > >knowledgeable people (as far as what will break if we do XYZ), > >who will eventually merge productive changes, I would be wasting > >my time. > > > >I don't want to be the libcrypt api changing pixie, scattering > >patches into /dev/null. :) > > So far, I've seen five people say that they want this functionality: > > 2005-01-08: Steven Alexander Jr. > 2012-12-05: Derek > 2013-07-07: me > 2013-10-29: jmg@ > 2014-02-27: Allan Jude > > There will surely be more, and I think it's fair to say that none of us are > sufficiently familiar with the many things that depend on libcrypt and > libutil. To avoid breaking something, we need feedback from the people who > would ultimately be committing these changes. Is this the correct mailing > list to discuss this proposed feature?
I'm willing to commit these changes once the proper parties have signed off on them... We should probably include secteam@ too... I'm glad we have as much interest as we do... :) > >>My suggestion is that we either have: > >> > >>a) passwd_format and passwd_round (so that they don't conflict), or > >> > > > >I recommend against this. By example, based on current scrypt > >modular crypt RFCs, there are multiple tunable parameters. It's > >conceivable that other future algorithms will have different > >functional and named parameters. > > > >Additionally, I think having all the parsing code for this > >scattered about actually makes things less clear. For example, > >$2a$08$ means a lot more to people (across different *nix > >backgrounds) than blf, is concise, and is/already should be well > >documented in crypt(3). Likewise with sha512. Looking at > >login.conf, you can't tell exactly what it means. > > > >Modular crypt is something that developers are working to stay > >compatible with (e.g. $5$, $6$, $2y$, etc), is understood outside > >of the context of FreeBSD system administration, and would be > >understood by people who are knowledgeable enough to seek to > >change this aspect of their system. > > This is exactly what I meant. I completely agree. > > >>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. > >> > > > >As jmg suggested, by supplying the modular format for > >passwd_format, we eliminate this conflict, and make it obvious. > >I definitely support this notion. > > Option C gets my vote too. Modular crypt is pretty standard across all > implementations, whereas options A and B would require additional > proprietary parsing, which I feel would be an unnecessarily more complex > change. > > >That means touching login_setcryptfmt and friends, I think. > > > >>>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. > >> > > > >Specifically: > > > >The makesalt aspect can/should be put into libcrypt, refined > >appropriately, and exposed publicly. It is a terrible little > >piece of code as it is now, twice (or more!), and it could be > >cleaned up considerably. This could be a nice little api. You know, I was very confused how it even worked, how providing a random salt and the _setdefault code works... it's a bit ugly IMO, but I guess it does work... It also isn't thread safe... > >Secondly, since the digests are used externally, I think it would > >be good to push the custom base64 code out to a library > >somewhere, so there is the standard way to do it, documented. > >Maybe libcrypt is the right place for this function too, since > >that is the context in which I have seen it. I forget for sure > >now, but I think each algorithm is also responsible for base64 > >encoding their output. Not that I'm saying we should just rip it > >out, but it might be worthwhile to look case by case, if it's > >appropriate. > > This is how I envision it too. The idea is not to have libcrypt depend on > libutil, but rather the opposite. Currently, there are at least two places > where this code is being used, and in my opinion, libcrypt would be a > better place for it. > > >As far as autotuning the work-factor, I think that just being > >able to set it at all is a huge improvement, and autotuning is > >Just Details. We can see that this will be fraught with problems > >establishing consensus, and could stall making progress with the > >other good work. Even if every couple of years, the default in > >login.conf gets bumped to whatever. When people run mergemaster, > >it'll show, and the admin can decide then. As it is right now, > >rounds are fixed, that's not appropriate for any use-case, small > >or large. > > > > > >Finally, I agree the ability to auto-update existing digests is > >desirable. That and the other policy stuff can happen totally > >separate from the discussion around exposing the tunables. > > I agree that these would be nice to have, and I agree that these should be > discussed after we get the basic functionality. Like Derek said, we > currently lack the ability to set this at all, or at least not without > patching our systems first. Let's start with manual tuning. I agree... Once we have the knobs to be able to tune the various things, then we can decide what the best defaults should be, or if they should even be changed... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"