I have a dispute with my partner. He comes from a financial software background but I do not. He recommends that our web app should expire user's passwords after 6 months (and it has to be unique each time). However, our target audience will be in construction. I think it will annoy the users and not provide enough security to justify the annoyance.

Do you think passwords should expire?

  • 4
    It will probably depend on many factors. One thing being - what happens to the user if they don't use the system for 2 years and then come back and find it expired: how will they gain access again? If that process is simple then it's less of an issue than if the reset procedure is a PITA.
    – JonW
    Commented Jan 20, 2015 at 16:21
  • 31
    No, this is a User Experience issue so is fine on this site. It certainly wouldn't fit on SuperUser or ServerFault and would be clsoed off in an instant (so don't post there please). Perhaps the security.stackexchange site might be interesting, but they would have already covered this from a pure security point of view. But from a UX perspective there is no problem posting it here.
    – JonW
    Commented Jan 20, 2015 at 17:12
  • 12
    if not strongly engaged in a service, I would tend to give up on a service that asks me to choose a new password.
    – njzk2
    Commented Jan 20, 2015 at 19:44
  • 41
    Remember, "Security at the expense of usability comes at the expense of security." (security.stackexchange.com/a/6116/29865)
    – Ajedi32
    Commented Jan 20, 2015 at 20:06
  • 2
    OP, please consider carefully Roger Attrill answer. Specially the Information Security exchange link. That question won IT Security Question of the Week.. There is also on that question a lot of linked research that was done by professionals on the field on the topic - but remember - security at the expense of usability come with the price of security. Tread this problem carefully.
    – Malavos
    Commented Jan 21, 2015 at 12:54

13 Answers 13


A compromise is that when a user returns to the site after 6 months (or whatever period) then you might helpfully recommend that they think about changing their password - along with a link to why this can be a good thing for them.

This also allows you to put in a framework where you might want to bring forward the date at which this happens to a specific date for all users - eg because of a security scare, a fix to a system security exploit, or other good reason.

I don't think passwords should expire for no good reason, and because 6 months has passed is not really a good reason. It's a finger-in-the air kind of time period. Why 6, why not 7 or 8.

Making passwords unique every time raises the obvious issue that all the users previous passwords are stored in the system and even though hopefully hashed/encrypted, that really is not good from anyone's point of view!

See Also:

I highly recommend reading over the answers to these questions on the Information Security Stack Exchange:

How does changing your password every 90 days increase security?

Requiring regular password change but storing previous passwords?

Point of interest:

Instances of expiring passwords are not constrained to banks and other financial institutions. This example is from Northern Virginia Community College

enter image description here


I once worked at a company where we were required to enter timesheet and project status information into an internal centralized system.

This was intended to be done weekly, but the main requirement was that it was done monthly - prior to the monthly billing period. Additionally, passwords to log in to the system expired after 30 days. Any previous password could not be reused.

Monthly usage. Monthly expiry. New monthly password. At first, support was being inundated by people forgetting their passwords and having to have them reset.

So, unsurprisingly, it was almost universal that we all fell into a routine of using a password that was based on the current month and year because that was the easiest way to remember the current password and be sure it hadn't been used before.

That system is no longer running.

The moral is that people are only human. Not everyone is a security evangelist. We forget things easily, and so we try to make it easier for ourselves. We write stuff down or if there are many constraints, we make patterns to help ourselves. And patterns mean less security, invalidating the very reasons why the security was attempted to be improved in the first place.

  • 19
    not allowing previous passwords does NOT mean that the previous passwords are stored in the system, it could (should in a proper system) mean that a hashed version of the password is stored in the system - quite a difference from a security point of view. Commented Jan 20, 2015 at 19:48
  • 10
    @user2813274 so password1 bevcmes password2 - they will be far away in hash - is that really a gain in security?
    – mmmmmm
    Commented Jan 21, 2015 at 12:01
  • 3
    I think this example is a really good example on poor usability - The users of the system will end using 1A2b3C4D! or something like that, then in the next change, 1a2B3c4d. . And here we go.
    – Malavos
    Commented Jan 21, 2015 at 14:06
  • 8
    @Malavos Exactly. Every place I've worked at that requires frequent password changes always resulted in the following passwords: 123456a, 123456b... This wasn't just me we would frequently joke about it to each other. Commented Jan 21, 2015 at 16:38
  • 9
    This also ends with post-it with password on the screens of each employee computer.
    – Malavos
    Commented Jan 21, 2015 at 17:45


All you're doing is pushing the security requirement into the domain of the user when really it's your concern if the data you are protecting is serious. In this case it doesn't matter what you do with passwords, you must employ secondary measures, such as two-step verification (GMail, Github), session deletion (GMail, Github, Facebook), unusual account activity notification (GMail) or more sophisticated measures such as those employed by actual online financial services.

Passwords are at best a way of stopping opportunist account access, i.e. stopping anyone from visiting your profile link and editing your profile.

The result of overly complicated password policies, whether this is expiry or anything else, is to make things difficult for users to access accounts. Anecdotally, I now have accounts where I have been pushed so far down the road of unmemorable passwords that I have defaulted to using password reset to access the account.

What does it actually achieve, security-wise?

I'll leave you to read this in detail, though to summarise the top two answers: it has no effect on brute force attacks—regardless of how many times your user has changed their password, they will still suffer from this and this; it does help with possible old back-up data security breaches, but this is a UX question and I would say backup security is 100% your responsibility as system admin and so I refer to my first point about pushing security into the domain of the user.

Actual Financial Services Examples

It's interesting to look at how online financial services actually deal with account security: they rely so little on passwords that they seem to have quite lax rules.

Let's take PayPal as an example. Go and sign-up, you need just 8 characters with one number and one symbol. Not very secure, especially when you consider that most people will just append "1" and "!" on the end of a dictionary word. I can't source the following info with a link, but due to a professional situation I was involved in we had it explained to us directly from PayPal that they have a set of metrics they also employ to notify them of hacks, such as how fast you type your password and where you access from.

Alternatively, you could take my bank (Nationwide) as an example. They use three simple codes to get in, all of which could be easily brute forced. If I try to transfer any money to a new account, however, I have to use a hardware pin entry device with my chip-and-PIN card and my card PIN. Not only that, but my bank analyses each purchase and if it doesn't fit my purchase history they block the transaction. This has happened twice, and in both cases I had to phone up and have the account unblocked.

The point I'm trying to make here is that something serious like a bank doesn't just rely on passwords to secure an account and although it may appear that security and usability do clash, some of the biggest entities on the web prove that the two can work well even when dealing with very sensitive data.

  • 10
    "Anecdotally, I now have accounts where I have been pushed so far down the road of unmemorable passwords that I have defaulted to using password reset to access the account." Yes! I literally have no idea what my (assigned) username or (self-chosen but with many restrictions and requiring frequent changes) password are for one of my credit cards. Every time I want to look at it, I have to reset my password. Which is ridiculous.
    – KRyan
    Commented Jan 21, 2015 at 18:08
  • 1
    Nowadays, for a significant part of the long tail (in terms of how often I use them) of web sites that I have different passwords for, the "forgot password?" link and a reset is my primary means of accessing those sites. Commented Jan 23, 2015 at 20:26
  • 1
    I'm simply voting up this No answer. Primarily because I am a believer in not knowing most of your passwords and using a password vault or other system. As we encourage users to work around the weaknesses in traditional password systems (new hacks seemingly reported every week) using vaults or two-factor or biometrics, making you change the passwords in your vaults regularly doesn't help encourage use of those better systems.
    – Cade Roux
    Commented Jan 26, 2015 at 20:08
  • @CadeRoux that's an excellent point!
    – Toni Leigh
    Commented Jan 26, 2015 at 20:29
  • @KRyan, I do this as well. I guess it is more prevalent than it seems. Commented May 23, 2018 at 13:54

The quick answer: Amazon, Google and my bank don't make me change my password every six months, or indeed ever. What do you do that requires more security* than they do?

Let's hope for your users' sake that that's a persuasive argument**, and you decide not to do that. The supplementary discussion point is: why do you need to store their password? Could you use OpenID or OAuth to sign them in, e.g. Sign in with Google? The reason is that it's more secure to let Google store their password than trying to do it yourself.

And good luck! I hope it takes off :)

*those in the corporate world often think that certain password practices are more useful than they actually are. It's very possible that in a room full of financial people, none of whom is an expert in security, no-one would be willing to call bull...stuff when practices such as these are brought up, because no-one wants to take responsibility just in case something they don't understand goes wrong.

**if not, see also:

  1. people will get annoyed with your system as they use it infrequently and why is yours the only one that does this?
  2. making people change their password just means they pick very similar ones, or ones which they write down somewhere; there is no getting around this behaviour
  • 4
    And if a site's password reset mechanism involves sending email to the email address on record, that site is already depending on Google's security to better than its own.
    – jamesdlin
    Commented Jan 22, 2015 at 19:33
  • The difference here is one word: liability. If an employer's system gets compromised because an employee wrote down their password and it was found and misused, the employer has a lot more at stake, legally and otherwise. Google/Amazon have no such liability.
    – trpt4him
    Commented Jan 27, 2015 at 0:18
  • @trpt4him the case where an employee writes down a password is much more likely when they have to keep changing it. Anyway, I'm not sure that the OP's question was to do with internal software; if so, they should be linking to a central AD or whatever and not providing their own password policies anyway.
    – Rob Grant
    Commented Jan 27, 2015 at 7:59

Accepted wisdom among security experts is that password expiration/forced changes do not, in general increase security, and often decrease it. Frequent changes do not make the password harder to guess, they do encourage unsafe actions by users (such as writing down passwords or using easy-to-guess patterns to generate them), and they only provides a benefit in the rare situation where an attacker who learns a password cannot immediately exploit that knowledge.


No, changing passwords every six months won't make the accounts more secure. You still use the same password rules (a Capital letter, a number, a symbol, a gang sign, a hieroglyph and the blood of a virgin). In fact if you require a change, the more likely that the user will write it down in an unsecured way.

More important than changing passwords on one site, is the reuse of passwords and usernames across your entire online presence. If you reuse passwords, it takes just one site to store your password in readable text, and your entire digital life is at risk.

The only problem is that we cannot check whether or not the user have used this password before. And that's wy we reach the only available security action we have left: password change interval. But advice your user to use a password keeping app on there smartphone/tablet/desktop and generate a new password for each site.

Then, and only then, you are more secure than password change interval.

  • @CodeMaverick True. But for the second time tonight, I don't make the rules :-). What we see on Apple, Google and Microsoft is drumroll password length of eight characters. That takes like a few hours to break, if you don't use 2-step verification which I activated this year. That's much harder to come by for your dumb fast computer. Commented Jan 20, 2015 at 20:34
  • That's actually a misnomer with respect to password rules. All that really matters is length. The world's fastest supercomputer in China does 33,860 trillion calculations per second. The password letter number symbol sign would take that supercomputer 200 quintillion or 200,230,945,989,547,900,000 years to crack it. A desktop PC doing 4 billion calculations per second would take a septillion or 1,694,954,957,801,523,000,000,000 years to crack it. Take that in contrast to !F4c3b00k! which the supercomputer would crack in 2 days and your desktop PC 58 years (same calculations per second). Commented Jan 20, 2015 at 20:34
  • 1
    LoL ... it's not my "dumb fast computer". That said, you don't have to make the rules for the facts to be what they are and the rules have needed to change for a long time, hence the multi-step verification systems that are being integrated nowadays on new sites. I was just disagreeing with your password rules. You didn't mention multi-step verification in your answer nor did you mention length. That's all. =D Commented Jan 20, 2015 at 20:47
  • @CodeMaverick True. Again. But I wouldn't recommend 2-step verification for average users either. Not on a regular site. But a longer password could be a good idea if you use a password manager. And most users don't use them either, unfortunately. It's a very hard to find a policy that have easy access and is secure Commented Jan 20, 2015 at 21:11
  • 1
    Yea ... I agree. Currently, I'm training my dad and my wife about the password manager method. It's not going too well. They like writing them all down on one single piece of paper. I don't get it, it's so easy. Commented Jan 20, 2015 at 21:17

It depends.

What does your site do? What are the real consequences of a compromised account? Annoyance or stolen identity?


Do you have any good reason not to punt and let OpenID, Google, Facebook, Twitter, and Yahoo handle user identity and authentication?

Security has costs. Weigh them.

Honestly, why don't you require your users to login via smartcard coupled with fingerprint scanner, cryptographic token, and a 128-character-minimum passphrase that must be changed every five hours? You have to balance the costs and benefits of security.

Think outside the box.

Passwords suck. Don't use them just because everyone else is. How about something cool like Clef?


For a website with customers, the answer is always no.

This has nothing to do with security.

This is because every six months you will lose a significant percentage of users who just can't be bothered to deal with the hassle of making up a new password, recording it somewhere, etc.

Forced password changes are acceptable for employees and other captive audiences, but are terrible for customers.

  • 2
    +1 for "a website with customers" always being no. That's a critical distinction here -- employees using accounts with internal access, versus external customers.
    – trpt4him
    Commented Jan 27, 2015 at 0:23

The password expiration is a constraint for users. Therefore it should make sense for users; otherwise it will produce a bad experience.

So I think a key question is: how important is it for your users to secure their access to your web app?

If you provide financial transactions or just content to read, it won't be the same....


My bank account password doesn't expire as far as I know so from a UX perspective you are in one of the following situations:

  • You do not trust your users to keep their password secure
    • They write it down on their power tools or brag to their friends about how much they love Ovaltine
  • You do not have the proper infrastructure setup to handle intrusion detection.
    • Hey, you have not logged in from this computer before so we've sent you a text/email, please enter the verification code.
  • You're system is inherently insecure and brute force attempts do not get mitigated.
    • Does the account lock after 3-5 incorrect attempts?

If you are hard-pressed to do an arbitrary password expiration blah blah blah then my personal recommendation would be to allow them to log in once with the old password and display a screen which states "This password is over 6 months old, do not close this window and please change your password now or else it will be a complete PITA to change it later, have a nice day."

Overall passwords should not expire given all of the possible ways to mitigate intrusion attempts.

If you have none of this setup then by all means expire the password every single week.


We use passwords that don't expire every day now - they're called finger prints. What makes them work is dual or even tri factor authentication (must have a pin, must have the activated smartphone present). Granted, the problem is that this requires a blue collar audience to have smartphones, and you can't always rely on that.

How sensitive is your data? Can you do a partial login? Look at Amazon - you can browse, use your preferences, see your recommendations, and even add things to the cart without being forced to log in again. I'd also note that Amazon doesn't require a revolving password.

It's good practice, but unless you're complying with finance or HIPAA law, it's best to remember that security is the bane of usability.


Should passwords expire?

I have a 2-part answer because this deals with User Experience and Security, but first things first :

The answer is, yes!

I'll do the User Experience side of things first since that's the site we are on. This has been demonstrated by a very popular webcomic by xkcd everyone will probably recognize:

xkcd Password Strength

Now, let's test correct horse battery staple on HowSecureIsMyPassword :

On a normal Desktop PC performing at 4 billion calculations per second, you get :

desktop pc results

I know, you're saying,"Yea, but that's just a normal Desktop PC. What about something faster?"

OK. What about the world's fastest supercomputer that performs as 33,860 trillion calculations per second?

fastest supercomputer in the world results

That's a really long time! Impossible!

You must be saying, "Well hold on! Wait a minute! What about the other Tr0ub4for&3 password in the comic strip? Surely, it would take a long time to crack that too, right?"

Ok, let's see what China does with that!

enter image description here

Just 4 hours!?!?!

Yup! Just remember :

Length and easy to remember > complexity!

Now, it is true, you need to also remember, two-factor authentication is the way to go nowadays and Clef has an awesome setup in that direction.

Now, as far as Security side of this, this specific question has already been question asked (different wording, but roundabout the same thing) by Bill the Lizard♦ on Security.SE :

How does changing your password every 90 days increase security?

It might be noteworthy to that in his question, he edited it to state :

This question was IT Security Question of the Week.
Read the Jul 15, 2011 blog entry for more details....

This was the accepted answer from Justin Cave that Bill the Lizard♦ chose :

The reason password expiration policies exist, is to mitigate the problems that would occur if an attacker acquired the password hashes of your system and were to break them. These policies also help minimize some of the risk associated with losing older backups to an attacker.

For example, if an attacker were to break in and acquire your shadow password file, they could then start brute forcing the passwords without further accessing the system. Once they know your password, they can access the system and install whatever back doors they want unless you happen to have changed your password in the time between the attacker acquiring the shadow password file and when they are able to brute force the password hash. If the password hash algorithm is secure enough to hold off the attacker for 90 days, password expiration ensures that the attacker won't gain anything of further value from the shadow password file, with the exception of the already obtained list of user accounts.

While competent admins are going to secure the actual shadow password file, organizations as a whole tend to be more lax about backups, particularly older backups. Ideally, of course, everyone would be just as careful with the tape that has the backup from 6 months ago as they are with the production data. In reality, though, some older tapes inevitably get misplaced, misfiled, and otherwise lost in large organizations. Password expiration policies limit the damage that is done if an older backup is lost for the same reason that it mitigates the compromise of the password hashes from the live system. If you lose a 6 month old backup, you are encrypting the sensitive information and all the passwords have expired since the backup was taken, you probably haven't lost anything but the list of user accounts.

But to me, the best answer, and the one I voted up, was by Hendrik Brummermann♦ :

Before answering, whether it does help or it does not help, it makes sense to look at specific scenarios. (That's often a good idea when dealing with security measurements)

In what situations does a forced-password-change mitigate impact?

The attacker knows the password of a user but has no backdoor. He does not want to be discovered, so he does not change the password himself.

Let's see if this scenario is likely:

How might he have learned the password?

  • The victim might have told him (e. g. a new intern who should start working before he gets his own account setup, another person who should level an account in an online game
  • The attacker might have watched the keyword
  • The attacker might have had access to another password database in which the user used the same password
  • A one time only login using a computer owned (prepared) by an attacker.

What might have prevented him from setting up a backdoor?

  • The service in question may not provide a way for backdoors, for example an email inbox or common web applications
  • The privileges of the user may not have sufficient permission to install a backdoor
  • The attacker might miss the required knowledge (in the online game Stendhal most "hacks" are done by angry siblings who just want to destroy some toy)
  • The attacker might not have turned evil, yet. (e. g. an employee that will be fired next month but does not suspect anything at the moment).

Why not use forced password expire?

It can be very annoying to users causing them to just add a counter at the end. This might decrease the entropy of passwords. According to my experience it generates additional support costs because people forget their new password more often than usual. I guess that is caused by the change password prompt catching them off guard while they are busy thinking about something else.

To conclude

It is far from a cure-all and it has a negative impact on usability, but it does make sense to balance that against the likelyhood and impact of scenarios similar to the one I described above.

  • This is a web app so I'm not sure what a shadow password file is or if it applies to my situation. Can you explain?
    – jrjensen
    Commented Jan 22, 2015 at 23:09
  • With web apps you typically use a salt and hash technique where the salt is unique per user and encrypted on the server. From memory, I believe the hash is created using the salt and password. You encrypt and store that on the server. So basically to check if the user submitted the correct password you perform all of the above using the stored salt and see if the resulting hash is the same. For more info read: crackstation.net/hashing-security.htm Commented Jan 22, 2015 at 23:42
  • Ok yes, we'll do that. However, once they have access to the database, why would they try to brute-force a login attempt when they can see the contents of the database?
    – jrjensen
    Commented Jan 22, 2015 at 23:58
  • Sorry, I was on the train. Umm, I don't know. If they can see your database, they don't need attack your website unless they are simply trying a DoS attack just to shut you down. Using any network profiler, you'd be able to see if they were flooding you with requests. If you have your private info in your database encrypted with good asymmetric / symmetric keys, you should be good. There's a lot that goes into security in a web app that people don't think about. The real question is, what do you have in your database that's worth stealing? Commented Jan 23, 2015 at 0:21

I am not a security expert, but I agree with the majority of the answers that say you should not force users to periodically change their passwords.

As noted above, all it does is make it more difficult for the user. This is especially true when there are very strict password requirements. Passwords are not effective security against many types of attacks. They will generally deter the casual intruder, but a highly skilled and determined hacker would be able to breach nearly any form of security.

There are a number of websites such as Facebook that log the IP address that their users log in with and send an email to the account holder if it was accessed by an unknown device. This at least gives a fighting chance to catch the fraud or attempted fraud sooner than later. Also, any account changes should also send an alert such as password changes, etc.

As far as brute force hacking goes, a password lockout policy could be effective. If someone tries to enter an invalid password for a specific user more than x number of times, then the account should be locked. This number should be determined by a security expert. As Mark noted, an automated password reset could be exploited by using social engineering. However, this would also require the attacker to have access to the email account as well to intercept the reset password.


Yes, in a perfect world passwords should expire and users should invent and memorize new ones.


Security reasons only. Expiration makes sure password changes periodically, and that prevents someone using hacked/leaked/stolen account credentials. It is good for user identity verification and authentication (low level, not real time).

Password expiration should not be thought as automatic real time security measure, since it's exactly same as credit card's expiration date. Both doesn't prevent an unauthorized user using them while the expiration date is in the future. If your credit card gets stolen/lost, you should call your bank to close the card. Same should go with your password, if it's suspected/known to be stolen/lost, you should change it.

  • If someone finds your expired credit card, it's useless.

  • If someone finds your password, you better hope it's expired -> useless.

As a real time security measure you should use other types of user identity verification / authorization with the password - if needed.

A blog or SOME account probably don't need too much authorization. But for example my bank lets me log in with my credentials, without the need of changing password ever, but to see any details of my accounts or transfer money I need to verify my identity with a physical list of keys on every transfer. It's not the best user experience, but it's safe experience, as long as the list of keys stays locked in my safe. ;-)

The thing to decide is the frequency, in finance it's more important to have short period of time to reset your password, then again in something that isn't holding any financially or personally critical data not maybe so often.

But then again in real life I've seen users getting frustrated in too tight password expiry frequencies, which usually lead to even worse security (physically), since users are having their hard-to-remember password on a POST IT sticker under their keyboard...

  • 3
    Your users put the Post-Its under their keyboards? LUXURY! Commented Jan 20, 2015 at 22:07
  • 10
    The average attacker, once they learn a password, will use it immediately -- to install a backdoor, if nothing else. Unless the every-six-months expiration happens to fall in the fraction of a second between learning and using, expiration gains you nothing.
    – Mark
    Commented Jan 20, 2015 at 22:34
  • @Mark Good point. I think I may suggest 2 factor authentication if we need that extra layer of security.
    – jrjensen
    Commented Jan 21, 2015 at 22:27
  • Unfortunately, the difference between a credit card number and a password is that one is chosen for the user - the other other is chosen by the user. Having the user’s old password is not useless - it gives you an insight into what their current password might be (this is because an average user won’t use a completely new password, rather one that evolves from their old one). Which means, if you don’t make users choose a completely new password, the payoff for password expiry is not worth the added security.
    – Jack B
    Commented Jul 15, 2018 at 14:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.