On Friday, March 07, 2014 10:34:40 am Tom Evans wrote: > On Fri, Mar 7, 2014 at 2:13 PM, John Baldwin <j...@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 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"