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?
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
Anecdote:
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.
No.
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.
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:
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.
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
It depends.
What does your site do? What are the real consequences of a compromised account? Annoyance or stolen identity?
Outsource.
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.
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:
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:
Now, let's test correct horse battery staple on HowSecureIsMyPassword :
On a normal Desktop PC performing at 4 billion calculations per second, you get :
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?
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!
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.
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.
Why?
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...
