Enforcing Stronger Passwords

Microsoft's password complexity filter: what's wrong with it and why you might need something better.

Bill: Is there a way to change the default password complexity filter in Windows 2000 or Windows 2003? We just did a sweep of our user passwords with a password cracker and found that lots of our users had passwords that were easy to discover even though we enforce six-character strong passwords.
—An MCSE in Phoenix

Phoenix MCSE: Okay, so let’s start at the 20 yard line and talk about passwords and why password complexity is important before discussing what’s wrong with the Microsoft complexity filter.

First of all, Windows does not store a user’s password, as you probably know. It stores an MD4 (Message Digest) hash of the password (and a DES hash for backward compatibility with Windows 9x clients.) The MD4 algorithm slices and dices the password in such a way that the input cannot be derived directly from an analysis of the output.

Get Help from Bill

Got a Windows or Exchange question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to Bill at mailto:boswell@101com.com; the best questions get answered in this column.

When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message but submit the requested information for verification purposes.)

But....

The MD4 algorithm is well known, so a password cracking program simply builds a database of hashed passwords and compares those hashes, one by one, to a password hash either taken directly from Active Directory or derived from a sniff of a challenge-response authentication transaction.

(The password hash is not transmitted on the network during a challenge-response, but the challenge is available in clear text, so it’s fairly simple to derive the value of the hash based on the reply sent by the client in response to the challenge. Kerberos avoids this vulnerability by not transmitting a challenge. It transmits a timestamp encrypted with a hash derived from the user’s password hash. The attacker would have to know the precise timestamp to derive the password hash.)

Windows passwords are particularly susceptible to precompiled hash attacks because the domain controllers do not “salt” the passwords with a random number as Unix systems do.

Okay, so that makes a dictionary attack of a Windows password fairly straightforward. What about “strong” passwords, though? Most of us use the Windows password filter to force our users to select passwords that meet these criteria:

  • At least once change from upper to lower case
  • At least one numeral or special character
  • Cannot contain the user’s logon name
  • Cannot contain portions of the user’s name

Based on the complexity filter, a password of Orange7 would be acceptable as long as the user’s name isn’t John Orange. (I’ll talk about password length in just a minute.)

A password cracker would find a match for the hash of Orange7 very quickly, though. Adding a special character to the end of a word doesn’t fool the cracker. The cracker simply runs through the precompiled dictionary words and tacks a single special character onto the beginning then at the end. It then does the same for two special characters, then three.

So, you don’t get a strong password by putting complexity at the beginning or end of a password. The special characters have to go in the middle.

Also, as long as you store old-style LanMan hashes in Active Directory, the change of case in the password is useless for deterring password crackers because LanMan passwords are converted to upper case before hashing. So, although an NT password might be considered “strong” if it looked like this PaSsWoRd$, the resulting LanMan password would be PASSWORD$, a fairly simple item to crack.

You won’t get acceptable password complexity until you rid yourself of legacy LanMan password hashes, which requires purging all Win9x machines from your network or installing the DSClient patch on them and hacking the Registry on each client machine. See Microsoft Knowledge Base article 239869, "How to Enable NTLM 2 Authentication."

As far as enforcing a six-character password length, that’s not long enough of a password. Even if you force your users to put special characters in the middle of their passwords and purge LanMan password hashes, it would still not take all that long to crack a six-character password using brute force. Even if you force users to change their passwords every 30 days to foil the cracker, users simply select a base pattern and only change the special character or numeral at the end: Orange7 -> Orange8 -> Orange9 and so forth.

So, if you want to have passwords that can withstand a moderately sophisticated cracking application, you need at least eight character passwords (10 is better) with special characters in the middle of the password and no patterns when changing passwords. With all that in mind, the complexity filter in Windows just doesn’t cut it. You may want to take a look at the Password Policy Enforcer from Anixis (www.anixis.com) or some other third-party tool for enforcing more robust complexity. You should also start thinking about deploying a two-factor logon such as a smart card, smart token, or biometrics.

If you have a recommendation for a better complexity filter, or you have techniques for encouraging users to select strong passwords, pass them along to me and I’ll print them in an upcoming column.

Hope this helps.

About the Author

Contributing Editor Bill Boswell, MCSE, is the principal of Bill Boswell Consulting, Inc. He's the author of Inside Windows Server 2003 and Learning Exchange Server 2003 both from Addison Wesley. Bill is also Redmond magazine's "Windows Insider" columnist and a speaker at MCP Magazine's TechMentor Conferences.

comments powered by Disqus

Reader Comments:

Thu, Jul 22, 2004 Jason DC

This article, although interesting, did not answer the original question! The question was how to change the built-in complexity rules in W2K/W2K3...there is no documentation for this anywhere on Microsoft's website (an MSDN query pulls up tantalizaing document titles, which 404 when you click on them...). In NT4, it was simple to write your own PASSFILT.DLL...however I'm worried that in AD the automated file system protection mechanisum will not let you override the built-in filter. I plan to test this today...however I'm not hopeful.

Tue, Jun 15, 2004 David Curlis Chestertown, NY

I agree with MrT & Kurt, I have had an easier time having end users adopt passphrases of 16 characters or more, rather complex passwords. There is nothing worse than seeing a users complex password written on a post-it note stuck to their monitor.

Sat, May 8, 2004 mailpete405 Alabama

Password policies are no longer rational. In standard intelligence tests, subjects are asked to remember a string of random numbers. The widely quoted average before stumbling - seven, give or take two - is thought to reveal the capacity of our short-term memory. Unless you have a very secure facility, machines would need to be set to screenlock after 5 to 10 minutes of inactivity. Complex passwords are useless if a passerby can sit at a vacated terminal which has been left logged-in during a bathroom trip. People are asked to memorize random passwords longer than the average brain can handle, change them every 30 to 90 days, and not write them down. Meanwhile, basic physical and operational security measures are being completely neglected, making all of the hassle for the user a complete waste of time.

Fri, May 7, 2004 Anonymous Anonymous

I've once asked a MS guy about pass phrasing and I got the, "go multi-factor pitch". Ka-chin - $$$, nary a peep about what I asked about.
Working in my evironment, I don't consider it a great idea as some of our users have enough issues with their login ID's let alone passwords. Add smart cards and/or biometrics and it is definately a no-go.
What bothers me right now is we are constrained due to legacy conditions to 14 characters but eventually when we move to pure w2k or w2k3 I'd like the studies out there making a case for passphrasing (127 char in AD) vs. password complexity. My fear is we'd get password complexity implemented and helpdesk flooded with locked accounts. And of course at that point management will start listening to vendors will start popping out of the wood-work promosing to fix it if only you'd shell out the bucks.

Thu, May 6, 2004 Joel Omaha, The Good Life

Good article, didn't know that special chars should be in the middle or they're worthless.
Did I miss it? When you "rid yourself of legacy LanMan password hashes, which requires purging all Win9x machines from your network" and all 9x machines are gone, do you need to turn off LANMAN hashes or not worry about it because newer clients default to NTLM2?

Wed, May 5, 2004 Jim DC

Two points: First, we tell our users to make pass phrases, not passwords. We tell them to think of a phrase of 8 or more words, and then use the initials as the password. Example: "Think of a phrase of 8 or more words" yields toapo8omw. It looks like gibberish and it's easier for the user to remember. Second, recommendations for "complexity" requirements are mathematically unsound. The time needed to break a password is related to the number of possible passwords. Adding one or two characters to the length of the password has a much bigger effect than adding 26 characters to the password character set. Besides, most people don't take advantage of a rich character set anyway (consider the "Orange7" example). In addition, if a password cracker knows you're using complexity requirements, a good first cut for the tool is to assume initial caps (26 possible characters), a series of lower case (26 possible characters each), and a trailing digit (10 characters). In a 6-character password, your first 118,813,760 guesses would probably cover most people. Compare to an 8-character password that's all lower case: 208,827,064,576 passwords, over 1500 times as many.

Wed, May 5, 2004 DavidB Denver

Good info, but I'd like to see more (or really _any_) backing for the claim that 8 characters is the minumum required to withstand a sophisticated attack. Obviously cracking time increases with complexity and length--but by how much? Where is the point of diminishing returns?
Along the same lines, I'd like to see more discussion of the trade-offs involved, This is not a one-size-fits-all solution. Are you assuming the environment is a national bank, or a local automotive shop with 5 computers? A reasonable security trade-off for one would not be reasonable for the other.
More information on password cost/benefit (say a table of time vs complexity and length, assuming X hash comparisons/second) would help readers evaluate an appropriate policy for their environment.

Wed, May 5, 2004 Anonymous Anonymous

Someday we'll all have to accept that passwords are just primitive and we need to go with multifactor authentication.

Wed, May 5, 2004 jeff florida

It's my understanding that windows stores it's passwords in (3) 7 character groups. When you run software such as lophtcrack on a password, it hacks the 1st, the 8th and the 15th character first. Therefore saying 8 or 10 characters is tougher to crack is a false sense of security, at least in windows world. If the hashes are found for the characters 1-3, the same hashes are used for characters 8-10. Therefore ABC????ABC would be easily cracked. You really need a third party utility or two forms of authentication to make it secure against cracks.

Tue, May 4, 2004 Mike Riverside, Ca

there is a problem with strong cipher passwords. And its a big problem, although it might be good to give them a big password like i dont know PaSSwOrd$!@121 is secure the user will have a he double hockey sticks of a time remebering it. Firewalls and the way you delegate information is your first line of defense, and while AD crackers use hash algorthims i thought most of them have to be in the internal network. Besides NT will tell you in the event logs if you set the appropriate thresholds with the event log utility if a user is trying to log into a special account and requesting and that account should be specifically used by few computers. You have to be carefull with this practice, making a password routine that requires I do not know say a 10 character difficult password just maybe a bad idea and a headache if the system remembers 20 passwords from the user. Best practice is to assign the passwords i guess with randomness and to give the password to the user, but security seems to be more about politics then secure computing. So you have to look at it from that standpoint. If your organization really requires strong cipher strength then upgrading to smart card technology may be a wise investment. Expensive at first, however with a carefully planed rollout can save in headaches of calls to the IT department. I recently read also that seems to cut department productivity on the user side and Help Desk side if they have to constantly update passwords. Maybe when IO software launches fingerprint ID's we may all be safe, but alternativly if your a good programmer in C++ and MFC and i think ATL. You could program a custom MSGINA to accept a flopy disk as a password with some obscure 64 bit length passwords. That would be hard to crack and have them be digitall signed so they are not plain text (RSA may do the trick) then make it unique to the client by creating a broker object that uses a different signed hash digest per computer. But that is really complicated and would take a huge developement effort on the ADMIN. And although there are some msginas that are open source the code is next to cryptic, especially if you want to allow it to run the windows Active Directory type of security, so choose carefully what you do. As windows uses a Regular String expression to decipher what you type as a password. And remember, if it takes a long time for the user to rember or that you are putting way to much on emphasis of the security of passwords, that means that you have not looked at how documents and users should interact. There are alternative situations. Cross refrence some on the internet and you find some good answeres, however i do not like the idea of web based reseting of passwords, with orgs that have critcial documents. although, you could create a script that uses a long password and is delegated to just changing passwords, you create problems with people who are smart enough to find those passwords in the ASP script or JSCRIPT that you write. Remember you can only provide a wall, there are ways to bypass that wall. And it is easier sometimes, and it is harder sometimes. A good defense is a great offense, limit the use of installations at your site. Audit your software and create policy forbiding the use and installation of un authorized software. If you create this type of policy you have a better way of controlling your assets. However, to create such a edict you need support (politically) from the boss. And examples should be made and unethcial processing to the rule should have consequences, IT should be a dictator of security practices and a delegate of a larger state for things such as features and that stuff. I do not really care if XP has a new theme machine to make the computer look glossy. It should process the login and do what i need it to do! Nothing, more and nothing less. Besides, things that may be a problem should be isolated, and secured. What people should talk about is how to get work done in office, not can i reset my password to this!

Tue, May 4, 2004 Ted Florida

Bill your article was very good, your column is one of the few on my mailing lists I actually take time to go through in detail. Please keep up the good work its appreciated.

Tue, May 4, 2004 Kurt Anonymous

I agree with Mr.T. At a recent Microsoft Security Roadshow, Steve Riley from Microsoft discussed this very issue. He talked about the superiority of kerberos over LM and NTLM. So like Mr. T said the key is move from the concept of passwords to that of passphrases. NTLM cannot hash passwords greater than 14 characters. So if you pick a passphrase of 15 characters or more, Windows will store it with kerberos making it extremely difficult to crack. And with a passphrase there is no need for special characters or numbers which makes the passphrase much easier to remember. The simple passphrase "mydogspotlovescarrides" is much more secure, because of kerberos, than a 14 character stong NTLMv2 password. The catch here is that you need all Windows 2000 or above. If there is a way to make this work on NT, I am unaware of it. I have stated this change in our enterprise and found the users receptive to moving to passphrases over complex passwords.

Tue, May 4, 2004 MrT Anonymous

Pass phrases are a better idea than shorter complex passwords, e.g. "Scooby-dooby doo". They're easier to remember and harder to crack. What is the max length that W2k can enforce?

Tue, May 4, 2004 Stan Anonymous

As one who has been on both sides of the strong password issue (LAN and helpdesk) I can say that trying to get users to want to have very strong complex passwords is a pipe dream. If you ever sat the helpdesk on password aging day and had to answer 100's, if not thousands of password calls and hear all the confused, angry users who just wanted to do what they are paid for, you will get a more realistic perspective.
When we changed to a strong password pattern and enforced it, the helpdesk was buried, 100's of calls in queue for hours, all because the carefully worded, step-by-step instructions were incomprehensible to the average business user. They didn't understand it and didn't want to, they simply wanted to login and go to work. While locking out the evil-doers is great, locking-out the users just breeds rage and more non-compliance.

Tue, May 4, 2004 Don Nelson Minneapolis

Certainly password strength is a high priority in this organization as well. But, I feel the article should have addressed the user problem of needing a single login authentication. That is a long way off as most organizations use multiple vendor's products. Users need to log in to many internal products and personal Internet Sites, like banking. I have about 75 and many have different password requirements. So people from Domain Admins to ordinary users are just writing out passwords and placing them around their desk.
The industry needs to work the human engineering. I believe it is a natural tendency for IT people to enjoy the power they can bestow on their organizations. So I believe the additional complexity discussed in the article is a temptation to IT which already today is being circumvented by users compromising the very security being espoused.

Tue, May 4, 2004 Timmy Anonymous

Enforcing complex passwords is a catch 22. If you make the password requirements so complicated the users can't remember them, they will end up writing them on a piece of paper and tape it to their monitor or bottom of keyboard. This is not good considering most malicious attacks come from people on the inside.

Tue, May 4, 2004 Anonymous Anonymous

I once wrote a VB 6 program that went through every ascii character, for every possible bit in a byte for a 64 bit password encryption scheme. It worked all the time. Try using something other than ascii.

Tue, May 4, 2004 mcsa/mcse jobless in PA Lehigh Valley

MMYYabc$ where (MM) is the current month; (YY) is the current year; (abc) is the initials of the user (Randomly use caps); ($) is a special character. the ($) can be at the start, end, or between date/initials. Alternate months (assuming a 30 day forced refresh) - rotate the date & initials - so that in January - 0104abc! in February - Abc02!04 in March - 0304!aBc in April - abC!0404 in May - 05!04ABc in June -
!aBC0604 etc. - easy for the end-user to remember - satisfies the criteria (8 characters) for security and changing - and cannot be easily cracked.

Mnemonics -
Use children's nursery Rhymes - "Three Blind Mice, See How They Run" yields: 3BmCHTr!

Chemistry:
Potassium Permanganate is KMnO3$$$

Tue, May 4, 2004 hhc ok

Isn't limiting incorrect logins the first line of defense?

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.