How can waiting 24 hours to change the password again be secure?
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.
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.
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.