Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I've found in several cases, forcing users to change their password on a regular basis becomes more of a strain on maintenance rather than a help for security. Also, I've seen users write their new passwords down since they either don't get enough time to remember their passwords and can't be bothered re-learning another one.

What security benefit is there for forcing a change in passwords?

share|improve this question

11 Answers 11

up vote 8 down vote accepted

Here is a different take from the SANS diary:
Password rules: Change them every 25 years

There is one practical benefit. If someone has your password, and all they want is to read your email and remain undetected, they can do so forever, unless you eventually change your sign-in secret. Thus, regularly changing the password doesn't help much against someone breaking in and making it off with your goods, but it DOES give you a chance to shake off any stalkers or snoopers you might have accessing your account. Yes, this is good. But whether this benefit alone is worth the hassle and mentioned disadvantages of forcing users to change their password every 90 days, I have my doubts.

share|improve this answer
    
And that article misses the one key point - with no password change requirement everyone ends up knowing everyone else's password. Internal threats are a much higher risk than external. –  Doug Luxem Nov 16 '09 at 4:43
    
@DLux, Why do you presume that the users will never change their passwords? As time evolves, people have to learn to secure their resources based of the value they see in them (and not by administrative enforcements). If forced preemptively a user is very likely to search (and find) a way to retain the same password after the change. They will change the password only when they really want to. –  nik Nov 16 '09 at 12:24
1  
It is a fact that users are going to share their passwords with each other. Requiring occasional changes adds enough of a barrier to that sharing (i.e. the shared passwords they know stop working). If you don't think your users are sharing passwords, then you probably don't know them well enough. –  Doug Luxem Nov 17 '09 at 0:55
    
@DLux, I know them well enough to observe that when passwords are shared, either of the knowing people would change the password when forced to do so -- and, probably with a pre-defined pattern. It is very difficult to design algorithms that account for Social Engineering of human minds. There is an incompleteness somewhere in there of the Gödel kind. –  nik Nov 17 '09 at 4:03

Force a password change when you guess it (by running a password guessing program on all your users all the time).

It's hard to argue with "you have to change your password" when the answer to "why?" is "because we were able to guess it blind". It automatically rewards those who choose difficult to guess passwords, and teaches your users what passwords are weak. If they choose "password1", it will expire before they can log in once. If a user chooses a 16 character, random, mixed-case, alphanumeric password, you'll never guess it -- and neither will anyone else. Let 'em keep it a very long time, and they'll even be able to memorize it.

share|improve this answer
    
That's...brilliant. Evil, but brilliant. –  acolyte Apr 3 '13 at 13:45

It is a trade off. Requiring frequent password changes does result in lower quality passwords. There has even been research to this effect.

That being said, the only reliable way I have found to prevent users from sharing passwords is to require periodic password changes. My experience shows that 90 days seems to be a decent compromise between usability and security. If you go longer, people start relying on shared passwords - sooner and you end up with "November09", "December09".

share|improve this answer

The worst thing about forcing a change in passwords is not that you're actually causing people to change their passwords. It's that usually it comes with little or no warning, and they are immediately struck with a problem they need to deal with right away, so instead of giving someone time to think out a good password it's more likely to be one that is either less secure but easier to remember, or more secure but it just gets written down, thus negating the security advantage.

share|improve this answer
2  
In a standard AD situation, you are warned at every login for 15 days before it is required. –  MDMarra Nov 17 '09 at 1:30

If the passwords are of sufficient complexity that they are not easily guessable, and they are not shared among systems, and it is unlikely that it has been compromised, then changing a password is probably not all that important.

However, should any of those occur, and the first two are probably more common than not, forcing people to change the password periodically means they are less likely to share passwords, at least.

That said, I would choose to educate your users about what a good password means, and why it is very bad to share them. Writing them down is common no matter what you do.

I recommend people choose a password from a book they know, by remembering some not-so-familiar quote from it, or making up a phrase. Use the first letter from each word, and add two numbers inside there somewhere. Most people can remember that after they've typed it a few times.

share|improve this answer

I see no benefits in that practice at all.

Strong password is much more important. By strong I mean either 9+ alphanumeric+special symbols, or a 15+ [a-z]-only non-dictionary password/phrase (this is based on a recent study of the cost of bruteforcing passwords using Amazon's EC2).

Remotely-accessed systems must have bruteforce detection and prevention software (e.g. fail2ban) on all the exposed services. This is much more important, IMO, than regular password-changing policy.

share|improve this answer
    
But a brute force attack assumes that the attacker has a copy of your encrypted password. How often does that really happen? –  chris Nov 16 '09 at 3:31
    
One could run bruteforce attack either against a passwords file (as you say), or against an exposed network service with password authentication. To get the passwords file one needs to gain at least some level of access to the target system (either physical or remote), and I believe that using an exploit at that point instead of cracking passwords is a very viable (and efficient) option. To conclude, I believe (but can't prove) that a chance of someone getting a copy of encrypted passwords is about the same as someone gaining unauthorized access to the target system - using other approaches. –  chronos Nov 16 '09 at 12:59
    
Wardialing for passwords is orders of magnitude slower than attacking an encrypted password. Typically if I've got the encrypted password I've already got admin level access or physical control. –  chris Nov 16 '09 at 21:19
    
that's what I'm saying :) I'm just using "bruteforce" both for remote attacks and for decrypting passwords. –  chronos Nov 16 '09 at 22:26

The basic issue is that passwords, as a security mechanism, stink.

If you ask people to change them often, they write them down. If you ask them to use 30 letter passwords with at least 3 numbers, 4 upper case letters, and a control character, they forget them or write them down or do other silly things. If they're simple, users will use stupid password like bunny7 or Bunny7. And they'll use the same bad password for everything, including their porno account and their hotmail account.

I like tools like Mobile OTP, which allow users to use their cell phone as a two factor authentication tool.

In the long term, it is likely that we will somehow land in a world with encrypted certs as the user identification mechanism. Things like OpenID and CAS simplify user authentication and allow convenient single-signon.

In the long term, the best bet is to reduce the number of times users need to issue credentials -- get rid of the "HR" password and the "time-sheet" password and the "CRM" password. Unify them into a common authentication infrastructure that requires users to issue their credentials once. Then have them use something like MobileOTP or an RSA SecurID that uses two-factor authentication.

In the short term, password policies are going to be the topic of religious wars. Just do whatever your boss asks you to, and if you're the boss, use your judgement based on your user-base and expected security profile.

Good luck!

share|improve this answer

The longer a password goes unchanged the more likely it will be compromised, simply because there will be more opportunity for situations in which it may be compromised to occur (given an infinite amount of time anything is possible). It also makes it harder to change in future as the user will have become accustomed to the old one. A further risk is that if it is compromised and the user is unaware of the fact there is potential for some serious ongoing misuse of the user's account to take place. Periodic changes will at least mitigate that as the next enforced password change will render the compromised password useless.

In my experience the scenario most likely to cause users to write passwords down is a lack of joined-up thinking in your security infrastructure, such as having multiple different systems all of which require their own unique username and password combo. Throw 5 of those at a user and you'll get yellow-sticky-note-syndrome with a vengeance.

A reasonable password policy that allows users to choose passwords easy to remember but hard to crack, coupled with some good user education, some solid integrated authentication, and decent lockout and expiry policies, all backed up by an AUP that explicitly forbids password sharing, is the best way.

share|improve this answer
    
Simply becuase ? please explain ! Are your systems subject to continuous third party attack? Perhaps some sort of IDS is in order instead of password changes ? –  Tim Williscroft Nov 16 '09 at 1:52
    
Never said it was my systems, but nope, they're subject to an insidious, nefarious, wretched hive of scum and villany known as "Real Life End Users". Users are lazy, they don't care about security ("it's somebody else's problem") and they just want everything to be made as easy as possible for them. It's all about a balancing act. –  Darth Satan Nov 16 '09 at 12:59

This practice, which is not entirely useless, was much more important long ago. Debating this policy is actually counterproductive, as it diverts attention from current threats that are much more serious.

Consider:

  • If you use Windows/AD, and an account does not have the box checked for "Account is sensitive and cannot be delegated", that account can be used via impersonation, and no password is required. The code to do this is trivial.

  • If a person's windows workstation is compromised from a security vulnerability, their in-memory windows security token can be used to access other computers. Again, no password required.

That second one, by the way, is why you should only access servers using an account that is different from your day-to-day regular user account. Also note that both scenarios completely defeat even the most robust two-factor authentication mechanisms.

The best thing that could occur with regards to password security is to stop debating it and focus on the more contemporary and serious threats.

More information:

Check out Luke Jennings presentation, "One token to rule them all":

http://eusecwest.com/esw08/esw08-jennings.pdf

Insomnia Shell - example of the code required to compromise tokens on an ASP.Net server:

http://www.insomniasec.com/releases/tools

How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0

http://msdn.microsoft.com/en-us/library/ms998355.aspx

Search for "without a password".

share|improve this answer

If you are caching credentials (which most people do for availability) then this is a must. If a computer is physically stolen and credential caching is enabled, then the thief can brute force the machine off of the network without fear of the account lockout policy being activated. They then have valid credentials to your network resources. Changing these passwords on regular intervals can help minimize this damage.

This is the exact reason that you never log in with a privileged account, you always log in as a limited user and elevate individual prompts, this prevents privileged credentials from being brute forced in the event of theft/break in.

share|improve this answer
    
Changing passwords regularly won't help much with stolen computers; unless you always make sure to let the password expire before anyone steals it... :P Only the most stupid hackers would wait several days after getting access before exploiting it.... –  Stein G. Strindhaug Dec 4 '12 at 8:25

I'm way in the camp of never requiring password changes. Or as the article says - every 25 years - yeah I'll be dead then. Good. Here's why... I have 12 passwords to remember at my job. Most of them change and the ones that change are on totally different schedules. They all have different strength requirements. How can a feeble human cope with this? Several ways I've seen: Write them on a white board. Write them on a paper and keep them in an unlocked drawer. or my preferred method: store them in a fairly insecure google doc spreadsheet. There is no way you can convince me that any of these methods (which are VERY common) doesn't totally offset any tiny security benefit obtained by requiring changes.

I have time to write this post because I'm waiting on someone in IT support to unlock one of my accounts. Apparently I didn't update my spreadsheet properly last time. Is there a study that calculates the BILLION$$$ lost to this nonsense?

share|improve this answer

protected by MadHatter Apr 3 '13 at 12:54

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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