34

Is there a security reason to disallow a user to change their password as frequently as they want? I have found this security policy in a site and I am not sure why it is enforcing it.

One reason I can imagine is that the change password functionality is a 'costly procedure', and changing it multiple times in a row can provoke a DoS on the site or produce too much traffic in the mail server that sends an email each time a password is changed.

Any other reason?

Note: I have found a similar question here: Is there any conceivable reason to prevent a password change in an authentication system?

Community
  • 1
kinunt
  • 2,759
  • 2
  • 23
  • 30

3 Answers3

37

The real reason why such policies are in place is because they are in place by default. That's how things go in Active Directory:

  • Passwords expire after 42 days.
  • When changing his password, the (non-admin) user cannot reuse one of his 24 previous passwords.
  • User cannot change his password twice within the same 24-hour frame.

So you will encounter such things a lot, mostly because it would require efforts and understanding to set them otherwise. Most people go through their life in a state of blissful ignorance and laziness, and sysadmins are no exception.

When a rationale for the third property (24 hours between password changes) is needed, the oft-cited reason is what @bobince says: to prevent a snarky user from cycling through 23 dummy passwords to get back at his initial password, because that would contradict the first rule (no password reuse).

Of course, such rules won't prevent users from using "sequence passwords": Password37, Password38, Password39... which somehow defeats the purpose of forcing password expiry (purpose which is already of very dubious value). And preventing the user from changing his password as often as he wants also means that the user cannot change his password as often as he needs: if the user notices a shoulder surfer who just stole his password, a security aware user would like to quickly change his own password, which would be, in that case, a very good idea. The rule against password change may prevent that.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 4
    Well I guess there is no point in commenting this here, but limits like these are just so annoying. In general I'm very much for burst rates: let the user change the password three times in 72 hours. You can't get back to the original any faster than you can with 1/24h, but at least you can correct something if you've made a mistake (capslock on or whatever)... – Luc Jul 10 '13 at 15:35
  • 1
    I agree that password expiry has as many drawbacks as advantages, but there is at least an arguable case for it. Minimum password time, on the other hand, is pretty much useless as a practical measure. It seems more like a reactionary attitude, treating password standards as a goal in themselves and getting cross that someone might circumvent them (even with good reason). Password standards are supposed to block the common, lazy-convenient cases of password weakness... but someone cycling their password a dozen times to avoid changing it is **not** a common cause of password weakness. – bobince Jul 10 '13 at 19:54
  • the 24-hour rule also makes sense in large AD environments, as replication across forests and even just DCs can take a long time in a highly-populated, or heavily-used AD setup. (I've personally witness 20-22 hour replication lag times in the past in a few different installs.) – warren Jul 12 '13 at 19:14
29

Typically it is used in combination with a password history policy, eg “you can't re-use any of your last 12 passwords”. Without a minimum-change-period it would be possible to circumvent this by changing your password 12 times in a row, back to the original.

It is IMO of pretty doubtful value.

bobince
  • 12,494
  • 1
  • 26
  • 42
  • especially if they use salt as they should... – Tobias Kienzler Jul 10 '13 at 14:10
  • 1
    @TobiasKienzler What does that have to do with this? – Luc Jul 10 '13 at 15:36
  • 1
    @Luc I meant that by using a salt the hash the same password used every now and then is different, which at that moment I considered reason enough to abandon the "change your password regularly" policy in general - but on second thought re-salting a password every now and then does not help against someone at one point obtaining your password and using it regularly. I was probably a bit tired... – Tobias Kienzler Jul 10 '13 at 18:18
10

No, I don't think there's any sensible security reason for having a limit on the number of password changes. The only limit that should be enforced is part of a general limit on expensive operations to throttle DoS attempts, such as 'no password changes more than once every 5 seconds*', or 'no login attempts more than once every 10 seconds*'.

However, there's one exception I can think of - sometimes changing the password is really expensive. For example, when large amounts of data are encrypted with a key derived from the user's password. When the password changes, the data needs to be encrypted with the new password and the old encrypted files needs to be removed then probably propagate through backups and so on. Even then, it's not a good idea to have a very restrictive limit because you don't know when your user's password might be compromised.

* The numbers are arbitrary.

Adi
  • 43,808
  • 16
  • 135
  • 167
  • Changing passwords might also be expensive in a distributed system where components need to use (or prove knowledge of) the password to communicate with each other. If it's necessary to have systems that communicate be aware of every password that other parts of the system might be expecting to use, changing passwords multiple times before the earliest changes have fully propagated could require systems to hold multiple intermediate passwords. – supercat Dec 08 '14 at 21:21