Password policies. Once again.

Recently in the newsgroups (, to be specific) the question of password polices and the out-of-box defaults came up. The poster lamented a number of things: that Microsoft doesn't enable account lockout by default, that we don't have a built-in mechanism for automatically disabling unused accounts, that the 42-day default expiration is troublesome. Here's my response; figured that it would make for a useful blog post, too.

Account lockouts

Account lockout is a poor substitute for good passwords -- and is one of the most expensive security features you can use. Let's think about this by considering the threat. What threat does account lockout (attempt to) mitigate? Password guessing. How can you make password guessing attacks become useless for an attacker? Two ways: implement lockouts or use good (meaning long) passwords.

Consider the first choice, account lockouts. The typical cost to an organization to reset locked accounts is US$75 per help desk call. In a medium or large organization, this can become a very high monthly maintenance cost. In nearly all instances, the call results from users locking themselves out (too many vodka tonics on the plane, maybe?), not users encountering locked out accounts because some bad guy was trying to guess passwords. Account lockouts have one more -- very bad -- problem: they create opportunities for bad guys to conduct denial-of-service attacks against accounts or entire domains! Even if you use a timed unlock of, say, 15 minutes, then the attacker can write his script to churn through thousands of bogus logon attempts every 15 minutes 2 seconds. So, contrary to the claim, enabling this setting actually can have significant impact on usability.

Account lockout is there for people who absolutely need it. But I can't think of any instance where this is true. Instead, have a policy that requires simple passwords at least 15 characters long. Forget about complexity rules that force people to write down passwords. A simple 15-character passphrase (think short sentence) is easy to remember, quick to type, and far stronger than any short complex password. A passphrase like this will withstand any kind of automated password attack, including those based on rainbow tables. And you can even use a method that helps you remember unique phrases for each site, if you wish:

• web mail: "my dog and i got the mail"
• shopping: "my dog and i bought some stuff"
• office: "my dog and i went to work"

This is why we disable account lockout by default. There are much better --  and much less expensive -- ways to mitigate the threat.

Disabling unused accounts

You're right, there's no built-in method to automatically disable unused accounts. A variety of third-party products can provide you with this functionality. I suspect some of them might be free, perhaps simple scripts even. I tried searching on "automatically disable unused accounts" and saw a few hits that looked promising. This particular function, however, rightly belongs in the HR process. A number of customers I've spoken with have automated the account creation/disablement/deletion process, incorporating it into HR systems. When a new user is hired, the account is created; when the user departs, the account is disabled; some time later, it's deleted. The HR systems take care of this, not domain or enterprise administrators. I wrote more about this subject in "When you say goodbye to an employee."

Password expiration

Password expiration is an important setting for everyone. It mitigates two threats: employees sharing passwords and bad guys discovering passwords. Because we can eliminate the second threat using long simple passphrases as I described above, then we have only one remaining threat: password sharing. Your estimation of how prevalent this threat is in your environment will guide you toward choosing an expiration time that works for you. 42 days is a reasonable default; our own corpnet uses 70 days. My experience with most customers shows that password sharing isn't a problem. So for those who do enforce long simple passphrases, I suggest that a reasonable default for expiration is 120 days.

Windows begins notifying you 14 days before your password expires. You can change this time period through group policy. I was in a similar situation recently. Last month my domain password expired while I was in Australia for TechEd there. I could continue to log on to my laptop with cached credentials, but couldn't use Outlook Web Access or RPC+HTTP of course. So I connected to a Terminal Server computer we have on the Internet, logged on there, and changed my password.

Comments

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  There's a lot of research going on about passwords vs. pass phrases. Please see Jesper Johansson's three-part series: http://www.microsoft.com/technet/community/columns/secmgmt/sm1004.mspx http://www.microsoft.com/technet/community/columns/secmgmt/sm1104.mspx http://www.microsoft.com/technet/community/columns/secmgmt/sm1204.mspx Scientifically, we don't know enough to state for certain whether pass phrases are indeed stronger than passwords. However, quoting from the conclusion: "While no one can conclusively answer the question of whether pass phrases are stronger than passwords, math and the logic appear to show that a 5- or 6-word pass phrase is roughly as strong as a completely random 9-character password. Since most people are better able to remember a 6-word pass phrase than a totally random 9-character password, pass phrases seem to be better than passwords. In addition, by adding some substitutions and misspellings to a pass phrase, users can significantly strengthen it, which is not possible with a totally random 9-character password."

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  Dan-- That's why I wrote about it, and continue to mention it at conferences whenever the topic of passwords comes up. If we can get these "jumped-up managers" to better understand real security risks, and the potential side-effect risks of certain security settings, then we'll all be in a better position. Education is always a good thing.

• Anonymous
  September 04, 2007
  On the subject of disabling inactive accounts, couldn't you use somethign like  "dsquery user -inactive 4 | dsmod user -disabled". (that syntax is from memory, don't go blindly running in in production)

• Anonymous
  September 04, 2007
  I like the unique pass phrases idea. How would you address though the  practice of users trying to come up with a new pass phrase at each password expiration date? Of course some users just increment their existing passwords in order to remember them easier. On this date users always forget their new password and many help desk calls are created.

• Anonymous
  September 04, 2007
  If only MS policy would allow you to require a password of 15 characters.  Today, the maximum length (that I can find) is 14 characters.

• Anonymous
  September 05, 2007
  The prefix-idea (my dog and I) is great, Steve! You could even write down the endings of the passwords, such as "went to work" on a post-it, no one could use it anyway. To address antknee's issue, the post-it could say "went to work4"  :-)

• Anonymous
  September 05, 2007
  Steve, great post I couldnt agree with you more. I see the true problem here being convincing the stakeholders of this. We have spent so much time and effort drilling some practices into the heads of the exec's that when the practices change it is hard to get the stake holders to change.

• Anonymous
  September 06, 2007
  The comment has been removed

• Anonymous
  September 12, 2007
  dkkazak: just edit password security policy (not with the the GUI) by notepad, import to GPO and there you have it...  min req passwords <14 characters...

• Anonymous
  September 14, 2007
  The comment has been removed

• Anonymous
  September 17, 2007
  My suggestion in order to enhance the password security level that 4 kinds of consequence, number and symbol is also necessary.

• Anonymous
  September 17, 2007
  Benny, where passwords are concerned, size matters more than how hard it is, so a long simple password is actually less likely to be guessed / cracked than a short complex one. Requiring complex passwords also leads to users forgetting their passwords - and then, they might as well be locked out because they're going to call in for the service desk, and they're going to write their complex password down on a Post-It note taped to the screen. As for changing expired passwords, you can actually do that through OWA, if your admins have enabled the feature.

• Anonymous
  September 27, 2007
  The comment has been removed

• Anonymous
  September 27, 2007
  Hello, i translated this post to french for those that may interest: J'ai traduis ce post en francais pour ceux que cela pourrait intéresser: http://lordoftheping.blogspot.com/2007/09/politique-de-mots-de-passe-encore-une.html

• Anonymous
  September 28, 2007
  The comment has been removed

• Anonymous
  October 03, 2007
  The comment has been removed

• Anonymous
  October 03, 2007
  Do you have an article that addresses a password reset or unlock tool and recommendations on that?

• Anonymous
  October 04, 2007
  Other people, other opinions. There is an article about password expiration which I have found some days ago and I would be very interested about your opinion: Prof. Eugene Spafford (CERIAS, security expert, NSA advisor, ...) sais that the whole topic of password expirations is based on the best practices 30 years ago where short passwords with no complexity where common but is totally useless today. http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/trackback/ What do you think about it? To be honest, I like the idea of getting rid of password expiration policies but I do have some scruple to make it real... Jan

• Anonymous
  November 12, 2007
  Give that CIOs and the like are notoriously hard to convince when it comes to security matters, turning off Account Lockout can be problematic in some organisations. The helpdesk want it off, the system admins want it off, but some jumped-up manager with less practical experience than the greenest of phone jockeys reckons he knows better. Which brings me on to the one AD account property I always wished Microsoft had included: the ability to tag a particular account (service accounts, for instance) with a Do Not Lockout flag. That way, one can still pretend to CIOs that security best practice is being followed, but make the more critical accounts immune to this kind of DoS attack vector.