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>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sVoolSkTfbVq0Vrw5RVoKS4a2XQlrFUFd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 administr= ator >>> >>> policy. >>> >>> Yes, but if you are moving to a different algorithm to improve securi= ty, not >>> coupling it with an eventual expiration of non-migrated accounts give= s a >>> false sense of security. Any admin worth his/her salt is going to wa= nt the >>> option of enforcing that sort of policy along with the transparent up= date.=20 >>> They should really be implemented together is all. >> >> Account expiration and password expiration are already present. There = is=20 >> absolutely no reason that password algorithm upgrade should be tied in= any way=20 >> to expiration. A transparent algorithm upgrade as proposed is *far* be= tter=20 >> than the forced password change method that is commonly employed. If t= he=20 >> administrator wants to force all accounts to migrate by a set deadline= , we=20 >> already have the expiration facilities in place to accomplish that. Ex= piring=20 >> accounts that have not been used in a long time, regardless of algorit= hm=20 >> changes, should be part of general housekeeping and may be covered by = existing=20 >> policy. Password expiration serves no purpose, EVER. Password expirati= on=20 >> encourages users to choose bad passwords because they are throwaway it= ems. >> >> 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 administrato= r. >=20 > I think you failed to understand my point. I am assuming that an admin= istrator > wants the transparent upgrade (which I think is useful) because they ar= e > assuming that the hash algorithm is compromised or inferior. To that e= nd, > they may wish to limit the time window for which they accept hashes gen= erated > using the suspect algorithm. This is separate (I believe) from the iss= ue Bruce > raises above. For example, in this case, the administrator is perfectl= y happy > for the actual plaintext to remain the same, the administrator simply w= ants to > enforce the new hash. >=20 > 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. >=20 > 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. >=20 > I suppose if you really were paranoid about the hash what you would wan= t is an > ability to set an expiration time on the hash algo itself where authent= ication > using that hash always fails after the expiration time. This doesn't n= ecessarily > 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 wa= rning > about the hash being expired on login via another mechanism.) >=20 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=3D15000 --=20 Allan Jude --sVoolSkTfbVq0Vrw5RVoKS4a2XQlrFUFd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----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----- --sVoolSkTfbVq0Vrw5RVoKS4a2XQlrFUFd--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5319DE84.3040602>