I have always wondered why it is that bad to reuse old passwords; it should not be the end of the world if we happen to use an old password that we previously used.

After all, I believe most of the time that we change our passwords isn't because of real threats (it will usually be because our internal paranoia). But while it is true that at some point, one of those threats will be real, and we will succeed in saving our accounts, is not likely that the hacker will store the unsuccessful password and try again.

But as I always say, companies don't bother thousands of users for no good reason, the pros are clearly outweighing the cons for them.

However, I am involuntarily covering important details with my fingers when I take this photo, anyone that have the complete picture mind to tell me what did I miss? (I have really large fingers.)


6 Answers 6


The first question is: why do some services require passwords to be periodically changed. The answer is "Risk Mitigation".

Corporate governance requires IT security policies to be defined in accordance to a risk management plan. One of the question that risk management plans ask is how can one mitigate a risk if it occurs. In the context of passwords, the question is how can we limit the damage of a password leak.

If the system administrator is aware of the leak then users can be notified and other steps can be taken. To reduce the damage cause by a password leak of which the administrator is not aware, the lifetime of passwords is limited so that any leaked password can be used only for a short period of time.

So services require periodic changing of passwords. The problem is that users really don't like changing their passwords. So what users used to do when forced to change their password was to change it twice - once to some temporary password and then a second time back to the original password. This of course nullifies the purpose of the policy to require passwords to be changed.

So the next thing administrators did was store the last two passwords and check that the new password is different than the previous two passwords. The wily users countered that by changing the password three times - two temporary passwords and back to the original password.

You might think that users wouldn't go to all that trouble just in order to not change passwords, but this is what actually happened. A administrator friend of mine once compared the hashed passwords in his system after a year and found that almost all passwords were the same - despite the fact that that password policy forced users to change passwords every three months.

So the administrators started storing the last 10 passwords. And the users countered by using a fixed password plus a single changing digit at the end for a cycle of 10 passwords. And thus we've reached the situation today where many systems store all previous passwords.

Having said all that, the real value of these policies is dubious. Human beings have a limited capacity for remembering passwords and if it's wasted on remembering these rapidly changing passwords it can't be used to keep different passwords on different sites (which is much more important).

  • 7
    Indeed, there is even the chance that users switch to weaker passwords, because nobody can remember tons of strong passwords. By the way, your friend's system is not worth changing the password, if it used a unique salt, there would be no way telling that the user reused the old password. Commented Sep 24, 2012 at 6:49
  • For systems like this, I now use a password plus a suffix that indicates the year or month (depending on how often the password needs to change). I use meaningless passwords of random letters, numbers and symbols. I refuse to remember a completely new one of those every 3 months, especially when I already have several of these for different services. Like you I'm not sure what administrators are thinking they will achieve with policies with this. I think it's more likely to be counterproductive
    – Joren
    Commented Sep 24, 2012 at 10:26
  • 1
    I could see this doing more harm than good though. Users will typically have a couple go-to passwords they as a result of this, and by storing them all, if your database is compromised, you're giving them all the hashed passwords they've used instead of just one. That could conceivably be easier to crack as well, as users reacting to this policy will probably use variations of the same password, as @Joren mentioned, giving you more targets to possibly guess. Once one of them is guessed, it can be broken down to key tokens and the rest of the passwords more easily guessed.
    – TimE
    Commented Feb 6, 2014 at 20:41
  • 5
    "Risk mitigation" is a nice marketing term that they indeed use in corporate environments, but "desastrous failure" is a better term. The typical knee-jerk reaction that you provoke from a normally security-aware user towards an admin dickhead who imposes "security policies" like forced logoff when you're on the phone for 2 mins (or talking about a PPT slide... really WTF?) and requiring a password change every 30 days with history is to simply use "fuckyou1" through "fuckyou20". Which is what I've been doing on such a corporate laptop for 15 years. They're not my trade secrets, you know.
    – Damon
    Commented Oct 28, 2014 at 15:49
  • 1
    There is a good allegory to that in the 1951 movie Captain Horatio Hornblower: "Flogging only makes a bad man worse, Mr. Gerard... but it can break a good man's spirit". That's what is going on with password policies in practice, too.
    – Damon
    Commented Oct 28, 2014 at 15:55

Because bureaucrats love to be bureaucratic. They think they are adding value by imposing all of these restrictions. In reality, not so much. It's not clear that there is any value to requiring people to change passwords or prevent reuse of old passwords on a routine basis. But what can you do?

These policies are often imposed by non-technical people, who are not used to thinking through a careful risk analysis in a logical, systematic way. If it feels right, then they go with it. And I can understand why imposing this kind of requirements feels like a good thing: it feels like you're "doing something". And surely doing something has to be better than nothing, right? Or so the thinking goes, anyway. (The thinking is probably wrong, but never mind that.)

Alternatively, sometimes there are external compliance requirements that may force system administrators to impose these kinds of requirements. Those compliance requirements may not actually be useful or sensible, but if they exist, there is no choice: you have to comply.

I'd like to point you to a fantastic research paper on this topic:

The paper examines 75 different web sites, ranging across a wide variety of audiences and security requirements: from online financial sites, government sites, educational sites, commerce and entertainment, and so on. It surveys their password requirements.

It has some surprising findings. For instance, the degree of security sensitivity, the value of the resources protected, and the number of users don't tend to correlate with the strictness of the site's password requirements. As the paper says, "Some of the largest, highest value and most attacked sites on the Internet such as Paypal, Amazon and Fidelity Investments allow relatively weak passwords." Even sites that have a lot to lose from security breaches often have weak security requirements.

Why is that? This might seem a bit of a puzzle.

The paper starts to provide some hints when it observes that government and educational sites tend to have strict password requirements, but sites that accept advertising or gain more revenue per user tend to have laxer security requirements.

The paper finally draws the following conclusion: for educational and government sites, their users have no choice. Their users cannot defect to a competitor site. Therefore, those kinds of sites can get away with unnecessarily strict password requirements; they have no incentive to improve usability. In contrast, the commercial sites where users have a choice have done their own risk tradeoff and decided that the usability loss of strict password requirements outweighs any modest security benefit from strict password requirements. Indeed, even those commercial sites that potentially have a lot to lose from security breaches -- e.g., online banking and financial sites -- often have relatively weak password requirements. If you assume those sites know what they're doing and have done the cost-benefit analysis, this suggests that the security benefits from strict password requirements are outweighed by the usability costs.

It's a great paper. You should read it.

By the way, I know the paper talks about strength requirements, as opposed to password-change policies or password-reuse policies, but the same conclusions apply equally (actually, with even more strength) to the latter. Password strength requirements quite plausibly do have some security benefit. In contrast, it's not clear whether there is any rational risk model that implies any benefit for policies that mandate password changes (and prevent reuse of old passwords). This suggests to me that strict password-change policies and password-reuse probably don't make sense.


It is not bad to leave passwords live long.

However, some people consider that password renewal is important and improves security. In all honesty, I am a bit at a loss when it comes to understanding what kind of reasoning goes in that assertion; at best, forcing regular password changes may have benefits if we consider that some passwords have already been stolen -- changing all passwords would be like superficial cleaning, a way to make a rotten situation more tolerable.

Nevertheless, if a system administrator wants users to change their passwords, then forbidding password reuse is quite logical: if users reuse old passwords, then they are not really changing their passwords. Whatever benefits could be obtained from password change, would be canceled by old password reuse.

  • Wouldn't that mean, that the system would have to keep a log of every single password, ever used by this one user? Doesn't that increase the chance that he's using passwords he used before, and makes this a high value target, to obtain and crack the passwords? Say we know user X uses this app. Hack this app, obtain a huge list of passwords, for this one user, crack them, and try them?
    – Kao
    Commented Sep 24, 2012 at 6:32
  • 1
    @Kao all you would need to do is keep a list of the hashes of passwords and verify that the hash of a changed password does not already occur in the list. If you use a proper hashing function, with salts, the usual, the list is worthless to an attacker.
    – Joren
    Commented Sep 24, 2012 at 10:18
  • @Joren But how long would it take to bruteforce, them if you actually dump the database, and there's maybe, 20 passwords for this one user? Is this not an added vector of attack?
    – Kao
    Commented Sep 24, 2012 at 10:45

I basically agree with what Thomas Pornin and David Wachtfogel said. What I want to add is that sometimes this policy is enforced in some applications by reasons that are not quite technical. For example if a company wants to certify for a PA-DSS compliance it should meet certain requirements:

The payment application keeps password history and requires 
that a new password is different than any 
of the last four passwords used.


I've recently seen such implementations. If the password hashing is weak (e.g. MD5) this may reduce the overall system security in my opinion. Further if people are often forced to change their passwords they end up in writing them on paper, notes, text files etc. Or they simply change one digit or character within the password. On the other hand PA-DSS does not prevent usage of weak algorithms to store passwords (e.g. MD5, SHA2 hashes instead of PBKDF2 or bcrypt/scrypt).

I'm really failing to find and understand any strong arguments for such policies.

  • Note that does not really answer the basic question in itself. There is still someone who decided that you should have a policy with rules X, Y, and Z and whether these rules make any difference, probably not... Commented Dec 25, 2015 at 6:32

Changing passwords is a good practice, in my personal opinion. We are sometimes not allowed to use one of old passwords, just in the case we had disclosed it in past and do not remember - this increases the chances of security breach in your account.

And some websites do not let you do this to force its user to change the password ( In plain English, to prevent somebody to type in the same password as existing even if he/she is feeling lazy to change one, otherwise they will type in the same password as their current password.)

  • I think that you should never disclose your passwords to anyone anyway... that being said, I have had many customers give me their password so I could fix something in their account. Life is weird in this way. Commented Dec 25, 2015 at 5:51
  • 1
    @AlexisWilke Well, there could be scenarios e.g. you're working remotely and for some reason you need your colleague's help log you in your computer from the office. On a tangent - If customers had to give you their passwords, chances are - the software was not done right or was not tested properly. In principle there should be an admin or root or superuser ( whatever we prefer to call it ) account which could fix other's accounts.
    – Ablaze
    Commented Dec 28, 2015 at 2:51
  • In most cases, it is because they want help with a website / app. I do not control and that system does not offer 3rd party support. But I agree that there is a lot to do in many areas of the web. Commented Dec 28, 2015 at 3:37

I'm surprised no one has said it yet. From a website administrators point of view, changing passwords on a regular schedule (even if they are secure) is a good idea incase an attacker has already breached your database. If you force your users to regularly change their passwords, we hope that most if not all of the passwords will have been changed by the time the attacker learns the plaintext version of your hashed password (that he had previously stolen).

You must log in to answer this question.

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