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: signature.asc
Description: OpenPGP digital signature

Reply via email to