Re: Feature Proposal: Transparent upgrade of crypt() algorithms

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.)

-- 
John Baldwin