Re: Tuning libcrypt with Modular Crypt Format

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