How can waiting 24 hours to change the password again be secure?

Question

So I managed to change my password on a service to the "wrong" password, for simplicity let's just say I changed it to an insecure password.

Now, I wanted to change it to a more secure password but instead I got a nice error message:

The password you entered doesn't meet the minimum security requirements.

Which was interesting, considering this new password was using more letters, more numbers and more special characters than the last password.

I did some research and found out that the service I am using has a security rule where you have to wait 24 hours before changing the password again.

I asked my provider if they could do the change in the accepted answer of that link, but they said they couldn't do it and that the 24 hour wait was "for security reasons".

Which leads to my question.

How can waiting 24 hours to change the password again be secure? What are the pros/cons of making a user wait before they can change their password again?

Answer 1

By itself, the rule of only allowing one password change per day adds no security. But it often comes in addition to another rule that says that the new password must be different from the n (generally 2 or 3) previous ones.

The one change per day rule is an attempt to avoid this trivial perversion:

• a user has to change his password because it has reached its time limit
• he changes it to a new password
• he repeats the change immediately the number of saved passwords minus one
• he changes it immediately back to the original one => hurrah, still same password which is clearly what the first rule was trying to prevent...

Ok, the rule could be the changing the password many times in one single day does not roll the last passwords list. But unfortunately the former is builtin in many systems while the latter is not...

Said differently, it is just one attempt to force non cooperative users to change their password on a timely manner.

---

Just a trivial probabilistic analysis after comments saying that allowing users to never change their password is not a security problem. Say you have a rather serious user and that the risk for his password to be compromised in one day is 1%. Assuming about 20 work days a month, the risk of being compromised in a quarter is of about 50% (1-(1- 1/100)^60)). And after one year (200 work days) we reach 87%! Ok, 1% may be high, and just start at 0.1% per day, only one on 1000, pretty negligible isn't it? But after 1 year (200 work days) the risk of begin compromised is almost 20% (18% to be honest). If it is the password for holidays photos I would not care, but for something more important it does matter.

It means that what is essential is to educate users and have them accept the rules because we all know that rules can easily be by-passed, and that if a user does not agree with them it will not be cooperative. But asking users to regularly change their password is a basic security rule, because passwords can be compromised without the user noticing that, and the only mitigation way is to change the (likely compromised) password.

Answer 2

Other answers have covered possible security benefits, however one significant drawback occurs to me: if an attacker takes control of an account and changes the password, they are guaranteed a minimum 24 hour window of access, during which the legitimate user cannot regain access to their account and lock out the attacker.

Worse, by changing the password every 24 hours, they can continue to maintain access indefinitely, unless the user gets very lucky with their timing.

Answer 3

When something like a password is changed on a distributed system, it may take a while for the change to take effect. If multiple change requests could be pending simultaneously, extra code complexity would be required to ensure that they are all resolved correctly, especially if the requests are required to include information about the old and new passwords [not necessarily including either, but perhaps just including some form of "delta"]. Such issues would not be insurmountable, but if if would be acceptable to require that any password change will have a chance to percolate through the system before another can be issued, that could avoid significant complexity.

Answer 4

I think it's correctly defined when they said it's for security reasons.

Supposedly if someone hacked into your account then you should be getting some sort of notification that sign in from a new device or workplace has been detected. In those terms this security feature will totally depend upon the support who follows your issue, and if they respond fast enough you will get a new changed password as per their policies of security in case of a hack.

But we can also assume that it's not the best policy, so they should impose more restrictions if they have kept a minimum time of 24 hours if you want to change your password again.

Answer 5

Lets add a real example why this can be a good security improvement.

Lets say your coworker or whoever found out about your webmailer password (say GMail 7years ago, without 2 factor). The attacker gets access into the webinterface to change your password (imagine some reasons) and via POP3 into your mails. Because Google is a huge network, it needs some time that old passwords are disabled for POP3 access. This gives the attacker the possibility to reset your password again and again. Even if you regain access with the reset function and validate yourself with your mailbox access on your smartphone or an reset strategy via SMS to your smartphone, the attacker (who still has access to your mailbox via POP3 with the old or his own passwords) can reset your password.

With such an attack the victim can't lock you out forever, because the attacker can't remove a reset strategy like a SMS number - but it surly states a very high risk.

This attack vector is easily preventable, if password changes are possible only every 24 hours.