Date: Fri, 07 Mar 2014 09:58:12 -0500 From: Allan Jude <freebsd@allanjude.com> To: freebsd-current@freebsd.org Subject: Re: Feature Proposal: Transparent upgrade of crypt() algorithms Message-ID: <5319DE84.3040602@allanjude.com> In-Reply-To: <201403070913.30359.jhb@freebsd.org> References: <2167732.JmQmEPMV2N@desktop.reztek> <201403070913.30359.jhb@freebsd.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 2014-03-07 09:13, 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.) > 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 -- Allan Jude [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTGd6HAAoJEJrBFpNRJZKfjZcP/i5I5ocPcurxwyfnWr2jRt21 A/xCtnXYCzdiiK7anLs7pAT8DBc5Htanxt2IHfksWBXG9urYMpP82MA1RyW1clt8 /ZPJem4MUvzt+RNyj+QeIDbvAeTlLUg0QEminCuT1Bo9PrxXwJXK7bfV8gaJ2NxX JPkriJ9lQ/l5mOEI1Gxnv/1bZ6w6g3m9ZvE26B1bE5E2AggLnHUjneMfCv3gVUhn ltaRA60jxQ8JG57jkraMW1Mkza1rBegsQRBS6mwdbHY175liLr7X8N2I8jYDHvvK uwN7eKb/LbUixbU6/RRCIKAgBZv/M8F6USuRmBCpD5hBAgIgc2htBz9IWo3gVleL MtaJ9DyP4hJIHUSuIQF7AQvQ3JaIuvrneeQZWtt82BkPaofOL6tOIQZ/FeeEwksY hbGBAh7/l1+ufpcRWPmrAfNK2EnaDcgBV0XDBStwXU1GLD5ZMBn0V/V2FWgPIUKG bqimAw4AjCt0Ak4NxSDARR3AUa01wckB/q6oO0papsMvvK+Z8pUSL5wlOU/NfLcb RmyRHHpg2EYxXRt0aci+utskYLbWOJo/tlfatE8tQrmFDzOxxmRaUBkxH0ExtZEd wCjl0VEjn+ZNNTMAB55xKWVej0CRa1eZgEaaD4AT1Q36w7qh1j4UgwfnMQesNm+Z H+1+X4w2SiyHJqypzBWw =b8Qe -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5319DE84.3040602>