107

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?

Anders
  • 64,406
  • 24
  • 178
  • 215
ZN13
  • 928
  • 2
  • 6
  • 10
  • 6
    Generally, I'd agree, sounds stupid. But every security measure should be a response to a specific threat model, so maybe they have specific threats posed by people or attackers changing their password more often. More likely, they have some administrative, non-automated effort when you change a password, and don't *want* to change. Even more likely, it's a bad practice that is somehow "historically proven!!!!!". See the answer to https://security.stackexchange.com/questions/139594/why-do-the-large-majority-of-big-organizations-have-known-bad-password-policie/139602#139602 – Marcus Müller Apr 03 '17 at 09:57
  • 2
    Its worth nothing that the service provider could have updated their password policy after you've set your original password. I've been registered to many sites that no longer would let me use the password I'd be currently using just because its 6 lower case symbols. – Иво Недев Apr 03 '17 at 15:01
  • 47
    `"You can only change the password once every 24 hours"` is business for `Users will (hopefully) only bother our helpdesk once a day" – xDaizu Apr 03 '17 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 Apr 03 '17 at 17:51
  • 1
    @dandavis you should submit your answer as a full answer below so we can vote on it. That's the only non-administrative, non-user related scenario provided here so far, and a very plausible scenario at that. – Stephan Apr 03 '17 at 18:18
  • 23
    @dandavis: But that scenario requires them to know your original password, so they wouldn't need to change it at all. – user2357112 Apr 03 '17 at 19:23
  • @user2357112: i was thinking it would stop certain notifications/confirmations from being pushed, but they would probably see other errors about being signed out, so you're right, that's not a good justification. – dandavis Apr 03 '17 at 19:41
  • 3
    Anytime you're limited by a 24-hour waiting period, there's either a mainframe or an idiot involved somewhere in the stack. – Ivan Apr 03 '17 at 20:43
  • 41
    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. – music2myear Apr 03 '17 at 23:55
  • 8
    @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". – Micheal Johnson Apr 04 '17 at 07:27
  • 2
    @dandavis what benefit does an attacker gain from changing the password in the first place? If I already know the original password, I already have access. If I'm trying to avoid detection, changing the password hurts my efforts (what if they try to log in during, say a boring bit of lunchtime conversation?) The one benefit I see to changing the password is if somehow my evil plan would be harmed more by being interrupted than detected (and avoiding detection is only a secondary goal). – user371366 Apr 05 '17 at 00:52

5 Answers5

130

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.

Glorfindel
  • 2,235
  • 6
  • 18
  • 30
Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • 112
    Just small caveat: forcing users to change passwords for no reason also adds no security. – Agent_L Apr 03 '17 at 13:16
  • 5
    @Agent_L: it is admitted that the longest time a password is used the more risks for it to be compromised, because for example of a co-worker eavesdropping over your shoulder willingly or not. Or typing it in a wrong prompt and having it send to an application and logged there. Or... – Serge Ballesta Apr 03 '17 at 13:19
  • 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 Apr 03 '17 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. – R.. GitHub STOP HELPING ICE Apr 03 '17 at 14:18
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/56528/discussion-on-answer-by-serge-ballesta-how-can-waiting-24-hours-to-change-the-pa). – Rory Alsop Apr 04 '17 at 09:07
  • Note that this policy is is easily enforced without a delay: remembering 20 or so last passwords makes this tactic pretty impractical. – Dmitry Grigoryev Apr 04 '17 at 10:31
  • @DmitryGrigoryev: you don't have to remember them, just take 20 different words in your favourite newspaper, use one at a time, and then enter back your initial password. If no delay is involved it should be done in few minutes. – Serge Ballesta Apr 04 '17 at 11:50
  • 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. – Dmitry Grigoryev Apr 04 '17 at 11:54
  • @Agent_L's point doesn't seem controversial; there are good reasons to force a password change, but if they aren't applicable to your application then don't do it for no reason. – user371366 Apr 05 '17 at 00:45
  • 3
    @serge-ballesta Your probabilistic analysis doesn't prove that changing the password regularly reduces the likelihood of compromission. – A. Hersean Apr 05 '17 at 12:02
  • @A.Hersean: You are right. It just proves that a password that does not change will be compromised and that the attacker will be able to use it since that moment. Changing the password just shortens the window of useability of the compromised password by the attacker. – Serge Ballesta Apr 05 '17 at 12:28
  • Does an attacker really need 6 month to exploit a password? This "solution" of forcing users to change password does not solve any security issue. – A. Hersean Apr 05 '17 at 12:39
  • 1
    @A.Hersean The only secure system is a system with no keyboard, no screen, no network connection, no user, and switched off inside a physical safe. All what remains is just risk analysis and mitagation... – Serge Ballesta Apr 05 '17 at 12:45
  • 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 Apr 05 '17 at 14:29
  • @Ukko: The math says that after one year, the risk of occurence of a password compromission is no longer neglectible. It is has not been changed during the period, the risk of compromission of the current password is that value and will continue to increase. If the password has been changed every month, the risk that the current password is compromised is much lower and it falls down to 0 after each reset. I don't worry for compromised password is they are no longer in use. I agree with you on the only benefit, but for me that benefit does matter. – Serge Ballesta Apr 05 '17 at 14:37
  • A site or system cannot not know what other passwords you can use on other systems/sites, so it cannot control whether they are or not different. But it is good practice to use different passwords for different (classes of) sites or system. Password vaults like Keepass can help here... – Serge Ballesta Apr 05 '17 at 15:50
  • @Peter: my only goal is to say the a never changing password daily used is a compromised password in only several months or few years. A psychologic analysis of how the casual user manages his/her passwords is far beyond this answer and my abilities... And no my passwords are not derived that way. – Serge Ballesta Apr 05 '17 at 20:30
  • @Peter: Is it more clear now? – Serge Ballesta Apr 05 '17 at 20:56
  • @SergeBallesta Its clearer. I'll be deleting my comments now – Peter Apr 05 '17 at 21:35
  • 5
    If the risk for his password to be compromised in one day is 1% then when he changes his password (assuming the new password is of comparable entropy) the new password also has the same risk of being compromised, so the long-term risk is the same as if the password never changed. The only thing forcing a password change every few months accomplishes is limiting the time the attacker can use the password before it's changed out. If he can do his damage quickly, it won't even make any practical difference at all. – Monty Harder Apr 06 '17 at 15:36
24

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.

user371366
  • 436
  • 3
  • 8
  • 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. – Dmitry Grigoryev Apr 04 '17 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 Apr 04 '17 at 13:43
  • @JoeW If a customer support fails to lock down a compromised account account under 24 hours, they serve little purpose. And if the attacker can change account information, they will make sure a legitimate user won't be able to simply reset the password and regain control. – Dmitry Grigoryev Apr 04 '17 at 13:51
  • 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 Apr 04 '17 at 14:23
  • @JoeW It shouldn't; that's what I'm trying to tell to dn3s. – Dmitry Grigoryev Apr 04 '17 at 14:28
  • 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. – Reinstate Monica -- notmaynard Apr 04 '17 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. Apr 04 '17 at 15:57
  • @DmitryGrigoryev One thing I'd be curious about is whether even low-level support staff would be able to override the window; the wording of the question, and the linked answer suggest quite a bit of escalation may be required before reaching someone with the authority to do this. – user371366 Apr 05 '17 at 00:22
  • 1
    To me, the comments about calling support remind me that there is no single answer, and that the scenario I described is not universally applicable. Some organizations will have a small userbase or large support budgets, where a support call and the opportunity to document the breach may be preferred. Others have to focus on reducing support load. Some threat models will consider breaches exceptional and emphasize prevention, others will see them as routine and emphasize fast recovery. But by default, my gut reaction is against policies that disempower users from protecting their own accouts. – user371366 Apr 05 '17 at 00:42
  • @iamnotmaynard Unless there's a "forgot password" button next to the login. Which just shows how security measures interact with each other. – Peter Apr 05 '17 at 20:27
  • @Peter Right, unless the attacker is aware of that and has changed the email and security questions (which I would expect would happen if the attacker is at all familiar with the system he's broken into). – Reinstate Monica -- notmaynard Apr 05 '17 at 20:57
  • @iamnotmaynard this is true, provided of course that the site allows for changing email, which not all do! (most do however) – user371366 Apr 05 '17 at 21:36
8

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.

JDługosz
  • 1,138
  • 2
  • 7
  • 12
supercat
  • 2,029
  • 10
  • 10
  • 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 Apr 03 '17 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 Apr 04 '17 at 18:44
1

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.

Peter Mortensen
  • 877
  • 5
  • 10
Jibin Philipose
  • 21
  • 2
  • 4
    But the OP asked support to change the password and they wouldn't. – schroeder Apr 03 '17 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. – Jibin Philipose Apr 04 '17 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 Apr 04 '17 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. – Jibin Philipose Apr 06 '17 at 16:46
1

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 be 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.

Ludwig Behm
  • 296
  • 1
  • 2
  • 8