From owner-freebsd-current@FreeBSD.ORG Fri Mar 7 14:38:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD0867F2 for ; Fri, 7 Mar 2014 14:38:07 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 867017AF for ; Fri, 7 Mar 2014 14:38:07 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7F1F3B9AE; Fri, 7 Mar 2014 09:38:06 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Feature Proposal: Transparent upgrade of crypt() algorithms Date: Fri, 7 Mar 2014 09:13:30 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <2167732.JmQmEPMV2N@desktop.reztek> In-Reply-To: <2167732.JmQmEPMV2N@desktop.reztek> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201403070913.30359.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 07 Mar 2014 09:38:06 -0500 (EST) Cc: Matthew Rezny 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: Fri, 07 Mar 2014 14:38:07 -0000 On Wednesday, March 05, 2014 3:09:30 pm Matthew Rezny wrote: > > > Password expiry is an orthogonal issue and should be up to administrator > > > > policy. > > > > Yes, but if you are moving to a different algorithm to improve security, not > > coupling it with an eventual expiration of non-migrated accounts gives a > > false sense of security. Any admin worth his/her salt is going to want the > > option of enforcing that sort of policy along with the transparent update. > > They should really be implemented together is all. > > Account expiration and password expiration are already present. There is > absolutely no reason that password algorithm upgrade should be tied in any way > to expiration. A transparent algorithm upgrade as proposed is *far* better > than the forced password change method that is commonly employed. If the > administrator wants to force all accounts to migrate by a set deadline, we > already have the expiration facilities in place to accomplish that. Expiring > accounts that have not been used in a long time, regardless of algorithm > changes, should be part of general housekeeping and may be covered by existing > policy. Password expiration serves no purpose, EVER. Password expiration > encourages users to choose bad passwords because they are throwaway items. > > Bruce states it well enough I need not elaborate further > https://www.schneier.com/blog/archives/2010/11/changing_passwo.html > > Anyone who fails to understand the above should NOT be an administrator. I think you failed to understand my point. I am assuming that an administrator wants the transparent upgrade (which I think is useful) because they are assuming that the hash algorithm is compromised or inferior. To that end, they may wish to limit the time window for which they accept hashes generated using the suspect algorithm. This is separate (I believe) from the issue Bruce raises above. For example, in this case, the administrator is perfectly happy for the actual plaintext to remain the same, the administrator simply wants to enforce the new hash. As far as I can tell, there is nothing in /etc/login.conf to allow for automatic account expiration if an account is idle for more than N days. OTOH, even that is probably not sufficient for the original case since a user might login with a different authentication method (e.g. ssh key) that would reset the idle timer without updating the hash. I suppose if you really were paranoid about the hash what you would want is an ability to set an expiration time on the hash algo itself where authentication using that hash always fails after the expiration time. This doesn't necessarily expire the entire account (e.g. ssh key auth would still work), though it might be a bit surprising to the user to find that the next time they attempt to use password authentication it doesn't work. (You would at least want a warning about the hash being expired on login via another mechanism.) -- John Baldwin