Should I force my users to change passwords every n days/weeks/month?

Question

Question says it all. We are designing a system where security is very important. One of the ideas someone had was to force users to change passwords every 3 months. My take on this is that while its more secure because the password changes often it also forces our users to remember ever changing passwords and makes it more possible that they will just write it down somewhere to help remember.

In the same idea is it really good to force users to use a super hard to guess password. Force them to use ?%&% and uppercase lowercase letters. I know its quite the hassle to invent such a password and then remembering it.

Then again we do not want anyone using 12345.

So. Is there any whitepapers about this subject? Good practice?

I am talking about a website created with PHP. MySQL in a lamp environment if that changes anything.

Answer 1

I think I might be in the minority on this (based on my limited experience dealing with IT departments at school and work), but I think mandatory, time-based password change policies are worthless at best, and harmful at worst. People tend to be very bad at choosing good passwords and keeping them secret. Password expiration policies are designed to mitigate this by limiting the amount of time any one password can be cracked/social engineered/stolen; however, they fail to achieve this in practice, primarily because they force users to relearn their password on a continuous basis. By making it harder for user to commit their passwords to memory, you end up causing many of them to choose weaker passwords, and/or write their passwords down someplace where prying eyes can find them.

Furthermore, when forced to change their password on a regular basis, many users will choose passwords that follow a very recognizable pattern, such as [base string][digit]. Let's say a user wants to use their cat's name Fluffy as their password. They might start out with a password of fluffy, then change it to fluffy1, fluffy2, fluffy3 and so on. In this case, the policy doesn't really help security; even if the user chooses a more secure base string than fluffy, and even if they keep their password safely memorized, the single suffix character that changes every few months does very little to mitigate cracking or social engineering attacks.

See also: Password Expiration Considered Harmful, a short article (not written by me) which I think gives a good introduction to these problems.

Answer 2

My large organization (15000+ users) implemented "password changes" every 120 days in the Fall of 2009. It's a huge IT headache and waste of support resources. Every time that 120 day window rolls around we have thousands of users forced to change their password....which many of them either do incorrectly and lock their account....or forget the next day. Our helpdesk gets swamped with password calls even though we tried to make as much of it as self-service as possible.

If you want your users/customers to hate you....and your front line IT staff to burn you in effigy every chance they get...implement password changes.

Password change policies are a checkbox in some IT Manager howto book somewhere...and it was written 15 years ago. No one in the trenches who actually implements or supports the policy will ever tell you it's a good idea.

I argued here for "pass phrases" instead of passwords....fat lot of good that did...that light at the end of the tunnel WAS an oncoming train. :)

A pass phrase is a long almost unguessable string that is very easy to remember like, "MyCatIsFromSpainAndICallHimElGato". Or maybe a line from a poem or song.

If you want to make it really difficult to crack....mess with the case, add some punctuation, change some ones to ells, ohs to zeros, a to @, etc... But keep it remember-able....that's the key. There's even ways to pick them so they flow easily from your fingers to the keyboard....so you're not bouncing all over between hands or with SHIFTs and weird punctuations.

So...

• Use long "pass phrases".
• Test them internally for strength.
• Implement "single sign-on" across your entire infrastructure so customers only have to use it once or twice a day.
• Never force them to change it.
• And educate, educate, educate on their proper use.

Matt

EDIT: 8/24/2011 XKCD agrees and said it better than I did.

Answer 3

No. My personal opinion is that it's unnecessary and even counter-productive. I ranted on my blog, but you can hunt that down if you're interested.

In short, it comes down to two reasons:

1. Forcing a user to constantly change their password leads to bad passwords.

There will be no shortage of anecdotal evidence on this, but it makes sense that if I'm forced to remember a new thing every x days, I'll make those things easy to remember, and probably related to each other.

Users are far more likely to choose "guessable" passwords like "Jan2010" or "Password05" if they know it'll have to change soon. Enforcing a strict policy on characters is likely to just result in an added exclamation mark or a fully-spelled name rather than an abbreviation. There's a big difference between a technically complex password and one that won't be guessed.

2. Forcing regular password changes doesn't prevent attacks, it only reduces risk (and not by much)

Think about it - if your password is guessed or discovered somehow, how long would it take an attacker to use that information? Put yourself in the shoes of the attacker. You've just discovered a password. Would you not log in and extract every bit of information you could straight away just in case someone finds out? In 30 days time, you've already got everything you want.

My recommendation:

• Force an exceedingly strict password policy (like 15 characters with upper, lower, numbers, and special characters, with no english words > 3 characters)
• Never make the user change their password. If they have to write the password on a piece of paper and keep it in their wallet, that's actually fine. People are good at securing pieces of paper, but not so good at remembering random strings of characters.

Answer 4

From a user's point of view, having to change my password is incredibly inconvenient. I absolutely hate having to do so, and will only begrudgingly use sites that I absolutely need if they require me to change my password.

There has also been some discussion about whether this is really a good practice, since some people end up having to write down their passwords in order to remember them.

You could implement one of those widgets that show people how strong (or weak) their password is while they're filling it in--I find those to be (sorta) useful, though I don't know if they actually result in stronger passwords.

Answer 5

As a user of a quite-strict password policy environment ("super hard to guess passwords" and password changing alike) my opinion is that only the hard-password is needed. Although it will take a bit for your users to get accustomed to it (specially if they're the 12345 kind of users) they should be able to recall and type it easily within a week.

However, I can predict uncomfortable end-users if you're having such strong passwords AND forcing your them to change.

Answer 6

From an IT administration standpoint, your best option is to investigate the possibility of letting your application use the single-sign-on capabilities of the existing authentication scheme that your customers are using. Obviously Active Directory is a big player, but if your application works with the policy that onsite IT has already configured, you don't have to worry about reinventing the wheel.

Since so much debate cropped up about whether or not enforced password changes are a good idea (though I think that was secondary to your main question), I thought you might enjoy some of the ideas & links here. For most situations, if you're not going to enforce a password complexity & change schedule, you may as well not have passwords at all - but the way it's implemented (training, management support, etc) is more important than I can stress.

Answer 7

Changing passwords often may lead to having user writing them down. Which is not such a bad idea according to Bruce Schneier (http://www.schneier.com/blog/archives/2005/06/write_down_your.html).

I would even argue that having security getting in the way of usability can sometime be a good thing, just because it reminds user to act securely. For example, in the bank where I work, lots of the security measures in place are security theater (for example face recognition at the door, but the security guy will open the door for you if the recognition fails). While those measures do not improve security by themselves, they are always there to remind us that security is an important concerne at work, that there is some amount of logging and checking going on, and that if you get caught doing something "unsecure" you will be in trouble.

Of course, this applies to security for the employees of a bank, it might not apply to the users of your website ...

Answer 8

You should force your users to change every n days if your security policy requires it. I work for a State agency, and this is a requirement enforced from the State Auditor's office. I can't do a thing about it, so I have to force changes.

If you are not bound by regulation to force password changes, don't force them. Ensure that the passwords that do get set meet certain minimum complexity requirements. Length trumps complexity for most password systems, so a variable standard is best-case in my opinion. Such as:

• No password shall be less than 10 characters.
• Passwords between 10-25 characters will require at least 3 character sets.
• Passwords between 25-40 characters will require at least 2 character sets.
• Passwords longer than 40 characters may use a single character set.

The built-in complexity schemes for things like Active Directory do not support this kind of tiered system. If you build your own password change environment you can do stuff like this. Because each use of the shift key increases the likelihood of a fat-finger event, long passwords with multiple character sets are MUCH more likely to incur failed-login events, especially during the learning stages. If you have an account-lockout system in place, this can be a big issue. For the person that uses the 3rd line of their favorite poem (63 characters!) as their pass-phrase, not having to h@x0r it makes entry fast and efficient.

Should technology or the risk environment change significantly and your passwords are now not as complex as they should be, do put in a way to expire passwords over a period of time. People will grumble over the necessity, especially if you've never forced a change before, but it will help you maintain your security posture.

Answer 9

Hard to guess passwords are a good thing. Enforcing complexity levels that result in users forgetting their passwords or having to write them down is a bad thing, because any security gained by the complexity is completely lost in the process. In an ideal world (which is unfortunately not where we live) there should be a balance trade-off between complexity and usability. Of course different people will see that balance point in different places.

The logic behind regularly changing passwords in X days is a little lost on me. The reason I usually hear for this is to limit the usefulness of a stolen password, to which I respond that any real damage will almost certainly be done within the first few hours anyway. e.g. Fred "becomes acquainted with" Mary's password. Unless that happens at almost the same time that Mary is changing that password, what difference does it make if it's changed tomorrow or next month? Is it really likely that Fred will wait another week or two before making use of the password (assuming that was the intent all along)?

Obviously changing passwords if there is any reason or suspicion that it may be necessary is a whole other matter.

Answer 10

If the application needs such a high-level of security, have you considered using something like SecurID tokens? These mean the user gets a new password every 60 seconds; you don't have to worry about them using writing passwords down. However, these do cost money. How secure does the solution have to be?

Answer 11

I think that information to the users is important.Explain to them how to create a password and how important it is to not use the same password twice. A easy way to create a password is to take a sentence and take the first letter in every word and add some numbers.

Ex. I like to rule the world = Iltrw99

Dont force them to change password it will only confuse them.

Answer 12

While I do not agree with changing passwords every three months this is a requirement if your company is publicly traded, and it is part of being SOX compliant. Side note: Sarbanes-Oxley sucks.

Answer 13

Something I've not seen mentioned is external access to resources.

I tend to agree that if you choose a sensible password policy, unless someone writes it down nobody is likely to guess that password.

However let's say you have webmail accessible offsite, now you potentially have users typing their credentials on "any old PC" and IMO that increases the risk to your business data posed by spyware/malware/trojans and so forth that may sniff/steal those passwords.

Answer 14

If people write down simple passwords, what makes you think they will not write down a huge passphrase or a super complicated password. What incremental password changes do accomplish is a purge of user ID's no longer in use automatically, and it allows for the individual user to have some responsibility in all of this. People are going to be people, looking for the easy road to accomplish something; repeated passwords and incrementally changed passwords can be detected and denied. Complexity requirements can be inforced, forced password changes can also open the eyes of non-IT users to thier responsibility in all of this. Most of the users whom complain about the password change are the lazy one's who pretend changing thier password is like open heart surgery. Stop the whining, be responsible, and stop trying to find easy street, or look for a new job with "limp" requirements...