20

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.

Iznogood
  • 320
  • 3
  • 12
  • I see someone voted on closing this topic. I think password management is very pertinent to programming. But if the community feals it should close it well where should I ask this? Superuser? – Iznogood Aug 23 '10 at 20:45
  • 1
    Honestly, I consider the client's security to be his concern. By all means, use SSL and things to keep the encryption so that it can't be sniffed, but if he wants to use "0" for a password, thats his own fault. –  Aug 23 '10 at 20:48
  • Try to make interfaces that allow to inject implementations of what you decide later. One method for verifiying password strength (or saying what's wrong with the password), one method for evaluating if it's time to change it or when it will be, and so on. By now return "ok" and "don't need to change" :) Later, when you get your answer from serverfault, you have the doors to open... – helios Aug 23 '10 at 21:10
  • 2
    @mathepic - "but if he wants to use "0" for a password, thats his own fault." - I agree in concept, but in reality, the site owner has some accountability. If you use "0" at your bank, and your account is cleaned out, they will put it back, right? – tomjedrz Aug 24 '10 at 04:22
  • 2
    @mathepic I disagree completely. Maybe for hotmail its the users fault but when its a private system full of private information its the companie's problem if its compromised because some idiot chose "0". – Iznogood Aug 24 '10 at 14:27

14 Answers14

29

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.

bcat
  • 405
  • 3
  • 5
  • 2
    You can prevent your second point in your password policy by requiring diversification from historical passwords. – Warner Aug 24 '10 at 18:57
  • @Warner: How would you implement that in a secure fashion? You should almost never be storing passwords without hashing them first, and `fluffy1` should have a totally different hash than `fluffy2`. It's easy enough to prevent users from reusing the *exact* same password, but I think that's about all you can do. – bcat Aug 24 '10 at 22:20
  • Couldn't agree more... – Antoine Benkemoun Aug 25 '10 at 08:08
  • 1
    @bcat, you most certainly *can* check to see if new password is an easy permutation of their old password. In the case of the incrementing number suffix, simply decrement and increment the new passwords suffix (if it is a numeral) and compare its hash versus the previously stored hashes for that user. You could put other simple transformation checks in as well. All without storing passwords in plaintext. – mmcdole Aug 25 '10 at 19:30
  • @Simucal: D'oh, I never thought of that! You're right, of course that would work. Do you know of any software that implements these sort of checks? I've been in environments where the password policy prohibited reusing one of your last few passwords exactly, but I've never seen password dissimilarity requirements like you mentioned. (It does seem like a good idea, now that I see how easy it would be to do.) – bcat Aug 25 '10 at 21:01
  • 2
    @bcat : Linux employs this type of verification via PAM (pluggable authentication module) and the utilities that allow users to change their passwords within the system request their current password first so that it can be judged against the new password. – syn- Jul 11 '11 at 04:29
14

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.

Matt Mencel
  • 369
  • 4
  • 13
  • It sounds like a good argument for not failing at user-education, not necessarily vs password policies. Not a failure on your part - someone higher up in IT botched things badly, because the ideas you listed should've been something every employee had put in front of them for every password-change-prompt. – Kara Marfia Aug 24 '10 at 14:30
  • Single sign-on really should be the first bullet point, it's the carrot that gives users a reason to learn the password. Also, the expiry time should be based on how often the user uses the password, 30-day expiry is not unreasonable for a system used daily, but at a previous employer their (non-SSO) expenses app (an app that most people only logged into once a month) had a 30 day expiration policy, everyone I know ended up ringing the helpdesk every time they used it! – GAThrawn Aug 24 '10 at 19:52
  • Single sign-on is incredibly useful. It helps to dramatically reduce the amount of passwords a user is required to know. – Anthony Giorgio Aug 25 '10 at 12:56
10

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.
Damovisa
  • 233
  • 1
  • 6
  • +1 - Agree for the most part, although I like 120 day or 180 day expiration. Good luck keeping an "exceedingly strict" password policy alive in a political organization. – tomjedrz Aug 24 '10 at 04:43
  • "People are good at securing pieces of paper" - really? you must know far better people than I! When I used to do desktop support you could have easily got onto a user's PC when they weren't around just by picking up the paper diary they'd left on their desk, turning to the back page and then typing the newest looking word into the password box. – GAThrawn Aug 24 '10 at 19:56
  • I think it depends on the piece of paper and their opinion on how important it is. Would those same people leave $50 notes lying around on their desk? Their credit cards? :) – Damovisa Dec 07 '10 at 06:35
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.

  • Well in this case its a private site with no registration form. Users are employees so they have to use the system he he. That being said I do not necessarely agree with very high security. But I do not get to decide everything you see.. – Iznogood Aug 23 '10 at 21:36
3

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.

3

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.

Kara Marfia
  • 7,892
  • 5
  • 32
  • 56
2

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 ...

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
Guillaume
  • 1,073
  • 5
  • 12
  • 24
1

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.

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
0

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.

John Gardeniers
  • 27,262
  • 12
  • 53
  • 108
0

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?

Mitch Miller
  • 575
  • 3
  • 13
0

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.

NiklasS
  • 443
  • 1
  • 4
  • 6
0

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.

Supercereal
  • 793
  • 1
  • 8
  • 17
0

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.

flooble
  • 2,364
  • 7
  • 28
  • 32
  • Very good insight thanks! Wonder how we can protect ourselves from that. We will be enforcing Firefox/chrome and bloqing IE6-7-8 so thats that. – Iznogood Nov 11 '10 at 21:27
-1

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...

Tai
  • 1
  • I find a "huge passphrase" much, much easier to remember than a "simple password". There's even a famous [xkcd comic](http://xkcd.com/936/) about this, so I'm quite sure I'm not alone. – Michael Hampton Dec 16 '12 at 01:05