Archive for July, 2014

Do you still limit daily password changes?

Wednesday, July 30th, 2014

Once upon a time, password history enforcement used code that stored hashes of the “last N” passwords for each user.  N was typically a small integer – often less than 10.  Some users would figure out what N was and, when the time came to change their password, made N+1 password changes, where the last password reverted to their original password.

Such users are both smart and stupid.  Smart, because they figured out how the underlying security system worked and how to circumvent it.  Stupid, because they opted for static passwords and thus weakened the security of their own accounts.

Some organizations figured out that they had users using the “N+1 trick,” and found a low-tech way to make it painful for the offending users.  They limited the number of times a user could change his own password in the course of a single day, typically to just 1.  A user who wanted to use the “N+1 trick” would be obliged to do so over N+1 days, which pretty much eliminated the attractiveness of the scheme.

Unfortunately, limiting the number of password changes per day is unfriendly to users.  Say I change my password, then decide that the new password is not so nice after all, and want to change it again, to a better value?  What about if I change my password, forget it and need to reset it.  These are legitimate use cases and users should be able to change their password as often as needed.

Fast forward to the present, where N can either be very large (say 100) or simply open-ended (Password Manager supports  this).  In either case, we get the same benefit of the old “max once daily” rule, but without annoying users who just want to change their password again.

In this context, “max once daily” loses any conceivable benefit. There is no security advantage to preventing an authenticated user from changing his own password as often as he likes.  There is no benefit in the sense of stronger measures against password reuse, if the password history data is large or open ended.  There is only down-side.

I raise this because we still, occasionally, meet organizations that insist on enforcing this rule.  Get over it – open ended history is a better solution.  This rule should be abandoned to a curiosity of history, removed from enforced password security policies.  Use a product like Password Manager to enforce open-ended history or just set N to a large number.