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

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