Date: Fri, 7 Mar 2014 13:25:35 -0500 From: John Baldwin <jhb@freebsd.org> To: Tom Evans <tevans.uk@googlemail.com> Cc: Matthew Rezny <matthew@reztek.cz>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: Feature Proposal: Transparent upgrade of crypt() algorithms Message-ID: <201403071325.35755.jhb@freebsd.org> In-Reply-To: <CAFHbX1JQXNtXxQNS4ht9_RTv1TfcL_1axO5_2UFD=DqTvGAmTg@mail.gmail.com> References: <2167732.JmQmEPMV2N@desktop.reztek> <201403070913.30359.jhb@freebsd.org> <CAFHbX1JQXNtXxQNS4ht9_RTv1TfcL_1axO5_2UFD=DqTvGAmTg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, March 07, 2014 10:34:40 am Tom Evans wrote: > On Fri, Mar 7, 2014 at 2:13 PM, John Baldwin <jhb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201403071325.35755.jhb>