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

On Friday, March 07, 2014 10:34:40 am Tom Evans wrote:
> On Fri, Mar 7, 2014 at 2:13 PM, John Baldwin <jhb_at_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