From owner-freebsd-current@FreeBSD.ORG Tue Mar 11 07:06:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBCD323C; Tue, 11 Mar 2014 07:06:39 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9CBF9B6E; Tue, 11 Mar 2014 07:06:39 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s2B76cIu082207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2014 00:06:38 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s2B76Wbb082206; Tue, 11 Mar 2014 00:06:32 -0700 (PDT) (envelope-from jmg) Date: Tue, 11 Mar 2014 00:06:32 -0700 From: John-Mark Gurney To: "A.J. Kehoe IV (Nanoman)" Subject: Re: Tuning libcrypt with Modular Crypt Format Message-ID: <20140311070631.GO32089@funkthat.com> Mail-Followup-To: "A.J. Kehoe IV (Nanoman)" , "Derek (freebsd lists)" <482254ac@razorfever.net>, freebsd-current@freebsd.org, secteam@freebsd.org References: <201403070913.30359.jhb@freebsd.org> <5319DE84.3040602@allanjude.com> <20140307161313.GA49137@nanocomputer.nanoman.ca> <531A2CC1.8080802@allanjude.com> <20140307215223.GB49137@nanocomputer.nanoman.ca> <531A42F3.5020207@delphij.net> <20140307225050.GC50880@nanocomputer.nanoman.ca> <531A660D.3040101@delphij.net> <531BE33B.4010504@razorfever.net> <20140310221200.GA69840@nanocomputer.nanoman.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140310221200.GA69840@nanocomputer.nanoman.ca> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 11 Mar 2014 00:06:38 -0700 (PDT) Cc: "Derek \(freebsd lists\)" <482254ac@razorfever.net>, secteam@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 07:06:39 -0000 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."