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."
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to