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?

  • 48
    "You can only change the password once every 24 hours" is business for `Users will (hopefully) only bother our helpdesk once a day"
    – xDaizu
    Commented Apr 3, 2017 at 15:43
  • 18
    i think it keeps someone from changing it while you're at lunch, doing a ton of bad things, and changing it back before you return none-the-wiser.
    – dandavis
    Commented Apr 3, 2017 at 17:51
  • 23
    @dandavis: But that scenario requires them to know your original password, so they wouldn't need to change it at all. Commented Apr 3, 2017 at 19:23
  • 42
    In orgs I've worked for, this was to prevent people getting around password history requirements. If you can't repeat your last 20 passwords, then people would apparently reset their passwords over and over going through 20 iterations and then they'd be able to set it back to their preferred password. Commented Apr 3, 2017 at 23:55
  • 9
    @music2myear The simple solution to that is to make password history time-based, not iteration-based. i.e. "You can't reuse any password from the last 6 months" rather than "You can't reuse any of your last 20 passwords". Commented Apr 4, 2017 at 7:27

5 Answers 5


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.

  • 112
    Just small caveat: forcing users to change passwords for no reason also adds no security.
    – Agent_L
    Commented Apr 3, 2017 at 13:16
  • 40
    No, actually those are same risks present since day 0. There is only more exposure to same risk. On the other hand, too many constrains force users to invent very simple algorithms in order to remember them, like Password1, Password2, Password3 or 1January, 2February, 3March, so the repeated exposure risks are hardly mitigated, but the complexity is lost.
    – Agent_L
    Commented Apr 3, 2017 at 13:31
  • 64
    @AgapwIesu: The user can always invent a new trivial change algorithm that the rules don't know about, and they will do so. Password expiration policies are just extremely harmful. Commented Apr 3, 2017 at 14:18
  • 10
    @SergeBallesta If the user is stubborn enough to reset their password 20 times in a row, trying to force them to improve seems hopeless. Commented Apr 4, 2017 at 11:54
  • 7
    The math in your example doesn't work. Since the probability of compromise is the same on day 1 as day 30 changing your password every day will result in the same 18% chance of compromise. The only benefit this has is limiting the useful window in which a password could be used by the bad guys.
    – Ukko
    Commented Apr 5, 2017 at 14:29

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.

  • 5
    This is a bit naive. When the user becomes aware that their account is compromised, they simply call support to have the account locked down. Commented Apr 4, 2017 at 10:29
  • 14
    @DmitryGrigoryev Contacting Customer support to lock down an account takes a lot longer then resting the password to regain control. And depending on the provider they will need information from the account that the attacker can change making it harder to regain control.
    – Joe W
    Commented Apr 4, 2017 at 13:43
  • 1
    @DmitryGrigoryev Under 24 hours? Why should it take longer then a phone call to lock down an account? The fact is that a customer should be able to reset the password and regain control of their account on their own and quicker then having to call into customer support to get help. Having to sit on the phone and wait 30 minutes to a few hours to regain control of the account is not good when the attacker could be causing damage that could take a significant amount of time and effort to undo.
    – Joe W
    Commented Apr 4, 2017 at 14:23
  • 2
    Nonsense. If the attacker changes the password, the legitimate user cannot regain access by themselves in a million years, because they don't have the new password. The attacker in any case has indefinite access, until the admin changes the password or locks out the account. Commented Apr 4, 2017 at 14:58
  • 10
    Often Customer support is only open certain hours. What if I discover the account has been compromised over the weekend? What if I discover it in the evening after working hours? Also, preemptively changing the password in case of compromise is sometimes useful. What if I suspect the password/account might have been compromised, but am not certain? It's easy enough to change the password just in case, but a call to customer care (and waiting on the phone in a queue to reach a live person) is a higher bar to surmount.
    – D.W.
    Commented Apr 4, 2017 at 15:57

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.

  • 2
    I wouldn't excuse any modern distributed system from taking 24 hours to perform replication, however there are a lot of legacy applications in the financial industry that use mainframes as backends which do their batch processing overnight. Since we can't predict when your transaction will have been processed, we just ask for 24 to be on the safe side.
    – Ivan
    Commented Apr 3, 2017 at 23:21
  • 3
    @Johnny: Even taking legacy systems into account, I wouldn't expect that password updates would normally take anywhere near 24 hours, but some database servers may sometimes be taken down for maintenance, system upgrades, or failure recovery, and banks might not want to publicize when that's going to happen.
    – supercat
    Commented Apr 4, 2017 at 18:44

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.

  • 4
    But the OP asked support to change the password and they wouldn't.
    – schroeder
    Commented Apr 3, 2017 at 14:59
  • There is a very rare chance of support denying to help the OP in case of hack. When authentication is done correctly they got no reasons to deny OP requests coz of that security questions and and phone number are registered and in some cases fingerprint too, thats why i also mentioned that there should be an even tighter policy defining all those restrictions in terms of an emergency situation like hacking of an account. Commented Apr 4, 2017 at 16:54
  • @GamerD: If an account has an "access blocked" flag separate from the password, the difficulties with issuing a password-change request while another is in progress would not apply to account-blocking requests except when another account-blocking or unblocking request was in progress.
    – supercat
    Commented Apr 4, 2017 at 18:51
  • You're absolutely right and it relates to the real time algorithms which the modern databases imposes so as I said policies are one important thing to define and in this case the admin of that database have to step in or the technical support will just forward the query to the admin and he will in turn come out with a feasible solution which will much certainly not let the hacker to manipulate access flags or any other loopholes which the hacker could possibly exploit. Commented Apr 6, 2017 at 16:46

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.

  • This rule only makes sense in a corporate environment. In such an environment, when something goes wrong, you just have to call the IT support team and an administrator will be able to solve it. Commented Mar 16, 2023 at 15:07
  • @SergeBallesta well, this is long ago since I wrote this. And more than 15y since I pulled this stunt with gmail. Today I would say that a lot more was broken with gmail back than. The described method "password change only 24h" SHOULD NOT be the required solution to prevent my scenario. It just would've been a measurement to prevent that specific case. I guess I will remove it or at least add a hint that, while there can be an argument where this hypothetical "makes $X safer", this should never be the sole reason. Commented Mar 16, 2023 at 15:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .