From owner-freebsd-current@FreeBSD.ORG Fri Mar 7 18:48:19 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 3604B594 for ; Fri, 7 Mar 2014 18:48:19 +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 0C41799 for ; Fri, 7 Mar 2014 18:48:19 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C457AB94C; Fri, 7 Mar 2014 13:48:16 -0500 (EST) From: John Baldwin To: Tom Evans Subject: Re: Feature Proposal: Transparent upgrade of crypt() algorithms Date: Fri, 7 Mar 2014 13:25:35 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <2167732.JmQmEPMV2N@desktop.reztek> <201403070913.30359.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201403071325.35755.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 07 Mar 2014 13:48:18 -0500 (EST) Cc: Matthew Rezny , freebsd-current 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 18:48:19 -0000 On Friday, March 07, 2014 10:34:40 am Tom Evans wrote: > On Fri, Mar 7, 2014 at 2:13 PM, John Baldwin wrote: > > 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.) > > > > All of this is orthogonal to adding a way to upgrade hashes. Yes, all > of the points you mentioned are relevant to general password security, > but doesn't explain why a feature that provides transparent hash > upgrades cannot be added without first adding the features you are > asking for. What I didn't say is that I think adding hash expirations is much more of an edge case and not very useful generically, so probably not worth the hassle. Also, I had originally suggested expiring accounts, but expiring accounts isn't really a good proxy for expiring hashes. Anyway, I think the original idea is good so long as it is optional. -- John Baldwin