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.
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 offluffy, then change it tofluffy1,fluffy2,fluffy3and so on. In this case, the policy doesn't really help security; even if the user chooses a more secure base string thanfluffy, 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.
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...
Matt
EDIT: 8/24/2011 XKCD agrees and said it better than I did.
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:
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.
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.
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.
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 ...
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:
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.
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.
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?