8

Today when trying to change my voicemail pin, I noticed the system has a rule in place which prevents users from changing their voicemail pin too soon after the previous pin change.

This was with a popular enterprise-level telephony system.

I can think of several drawbacks to any system imposing this type of restriction e.g. if I know my pin is compromised, I would want to change it right away, and this type of restriction could hinder that practice, depending on the timing.

What would be the reason(s) for implementing this type of "can't change your password too frequently" policy?

GWR
  • 1,203
  • 2
  • 9
  • 11
  • 1
    If your password/pin is compromised within the "too soon" period after you've just changed it then either you need to stop putting that sticky note on your phone or computer monitor or the system is thoroughly insecure. – MonkeyZeus Apr 06 '18 at 17:31
  • 1
    @MonkeyZeus or, perhaps, someone simply sees you change it or use it within that time period. – maxathousand Apr 06 '18 at 17:45

3 Answers3

25

The main reason this type of policy is implemented is to be paired with a no/limited password reuse rule and password expiration and prevent user bypassing the reuse limitation by changing their password enough time in a row that they could continue to use their old one.

Say you have a policy that forbids to reuse the last 5 passwords but I want to keep my "p4ssw0rdverystronk", I could change it to "zxcvbn", "qwerty", "password1", "sefa_pass" "idonthaveanymoreidea" and back to "p4ssw0rdverystronk" in a few minutes.

Glorfindel
  • 2,263
  • 6
  • 19
  • 30
Sefa
  • 1,744
  • 1
  • 9
  • 16
5

As Sefa says in their answer, it's to prevent password rotation -

If a password is compromised, you want users to change it.

Typically you will require a user to not reuse a password than is identical to the pass n passwords.

Naive users will find that annoying and want to keep their already-memorized passwords.

Clever, naive users will change their password n times, so that they can arrive back at their old password.

If you set a minimum password age (typically 1 day or so), it becomes more difficult to rotate all the way through, rather than just keeping your new password.

Ergo, it is more secure to set a minimum password age than to not do so, because it saves users from their own naivete.

As to your point of "I know my new password is compromised, but I just changed it. Now I'm stuck with a compromised password.", you are correct - that is an issue. When the minimum password age recommendation was devised, it was believed that this was a smaller risk than users rotating back to their old password. Additionally, if a user knows their current PIN is compromised, hopefully they will contact the administrator and have a forced reset performed.

Monica Apologists Get Out
  • 4,031
  • 1
  • 15
  • 22
  • 2
    This makes sense. Wouldn't a better way to achieve this be to implement something like "can't use last 10 passwords and cant use any password previously used some number of months" - this would still allow for the change of PW at any time if, say, I know my password has been compromised. – GWR Apr 06 '18 at 14:57
  • Yes but I imagine the implementation is more complicated. – Monica Apologists Get Out Apr 06 '18 at 15:02
  • the number of password you used in the last few month is potentialy unbounded as opposite to the last X which is set – Sefa Apr 06 '18 at 15:03
  • 5
    @GWR I would argue that it's actually a *good thing* to force your users to contact an administrator when they know they are compromised, this means that as an administrator you can perform a check if the compromised credentials have been misused yet or not. If the user 'solves the problem themselves' through a password reset then you may never even notice if these credentials were actually misused or not. – Cronax Apr 06 '18 at 15:09
  • 9
    I agree with your explanation, but I disagree that this is a good thing. Password expiration is a bad thing, compromising security to enforce it is even worse. – Anders Apr 06 '18 at 15:17
  • 3
    Why would you call those people naive? I have nearly unique passwords for every website (have a formula that changes my password for every website based on different factors), so I consider it pretty secure. And it's easy for me to remember the password (even though it is quite complex) because I know the formula that I use to create a unique password. It is **so annoying** when a website forces me to use a new password AND not to re-use a previous one. I don't have another password for the website!!! Because my formula is screwed the next time I visit I have to always reset the password. – kiradotee Apr 06 '18 at 15:50
  • @kiradotee I don't mean naive as an insult. I work in InfoSec, I know that the average user prefers ease of use over security, unless you teach them otherwise. It's human nature, not a character flaw. – Monica Apologists Get Out Apr 06 '18 at 16:15
  • 4
    @kiradotee I also want to point out that formulaic passwords are troublesome if more than one of your passwords get leaked. I'd strongly advise only using formula substitution passwords for sites you aren't really concerned about. Your banking, email, and work passwords should all be completely distinct from each other. – Monica Apologists Get Out Apr 06 '18 at 16:16
  • @Adonalsium I agree in general (the way I've seen people typically do formulaic passphrases, even one compromise provides a great chance of guessing passphrases to other logins). If your "formula" takes proper advantage of the way the human brain works you can produce an end result that is sufficiently non-obviously connected to the thing, to the point that you're basically doing a crude but naturally-human form of hashing - where the hashing algorithm is your life experience and natural thought patterns and the passphrase is the output. Most people don't go that far, but seems worth noting. – mtraceur Apr 06 '18 at 18:23
  • 2
    @GWR At a certain point, you *have* to have a cap on how many passphrases you retain, because otherwise it's a DoS attack vector: If I can write an automated tool to keep submitting new passphrases to your system as fast as possible, I would eventually fill whatever storage database is being used to store the passphrase hashes. That said - I think you have a good idea there, because you can still make a reasonably high-for-humans limit like a 1024 passphrases total remembered cap before blocking you - but this *does* increase implementation complexity a little, which is its own security risk. – mtraceur Apr 06 '18 at 18:29
  • 1
    @kiradotee what do you do if your password is stolen if you are not able to create a different password for the website? Your method is flawed and as others have pointed out probably not as secure as you think. Use a password manager. – Ben Apr 06 '18 at 22:51
  • I agree with @kiradotee that calling them naive is an unnecessary insult. One may be naive, or one may have a better threat model than the IT and security people who put the rules in place, potentially because that one is an outlier whose usage patterns do not fit the model IT and security used when they set the rules. – Cort Ammon Apr 07 '18 at 07:21
0

Another factor not yet mentioned is that in some systems there isn't a single database of passwords, but there are instead multiple databases that aren't always on-line simultaneously. Changing one's password will result in the new password propagating throughout the system over a period of time. Although newer systems shouldn't have trouble ensuring that issuance of multiple requests will eventually hold in everyone holding the latest password, some older systems had trouble, and some policies were set very conservatively to ensure that no new password request could be issued while any changes might still be "in flight".

supercat
  • 2,049
  • 11
  • 10
  • Good point... agreed this could be a reason we would see such a requirement, but I'd argue that these details should never expose themselves to the user... Also, if the replicated DBs can be out of sync once (e.g. immediately after the first PW change) then what difference would it make if the user changes their password again immediately... in both cases the "other" instances would still be out of sync with the "online" or primary version – GWR Apr 09 '18 at 12:05