From owner-freebsd-current@FreeBSD.ORG Sat Mar 8 00:36:35 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 99588123; Sat, 8 Mar 2014 00:36:35 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 78217226; Sat, 8 Mar 2014 00:36:35 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 89DB016E54; Fri, 7 Mar 2014 16:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1394238989; bh=L9G5QXRAQBhJqVw6rltWsaDy0AwSKzW3buYXhZNEqZg=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=FH9jmW7b/d1c1W0GnsTd1qG7/l9IVUN20HVe5Edexzsl+4Ivfs3QhW1IUqHq70Whk LIQ+KGIWSkNFEIJ2s2JSHuZjTTaRebse6i34rsqohslgHgR5iomOqZdH1JGvjQY6Cr lnOae5vI1qGO4HV0AJQJd+3CKwQdmsruxlNuVwug= Message-ID: <531A660D.3040101@delphij.net> Date: Fri, 07 Mar 2014 16:36:29 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: nanoman@nanoman.ca, d@delphij.net Subject: Re: Feature Proposal: Transparent upgrade of crypt() algorithms References: <2167732.JmQmEPMV2N@desktop.reztek> <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> In-Reply-To: <20140307225050.GC50880@nanocomputer.nanoman.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org, secteam@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 00:36:35 -0000 -----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 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-----