Here's Some Good Password Advice

Whether pass phrases are better than passwords seems to be a matter of personal preference. But whichever approach you choose, consider the following tips for developing strong passwords or pass phrases.

Enforcing Password Policies
First, some tips for how to determine a password policy in group policy. It is a good idea to create a separate group policy object for your password policy. It is easier to roll it back should something go wrong. Go to the Active Directory Users and Computers tool, right-click the domain, and click Properties. Then click the Group Policy tab and click the New button. When you are done, edit the new group policy object and configure your policy in the Computer Configuration:Windows Settings:Security Settings:Account Policies:Password Policies node.

Second, keep in mind that password policies can only be applied at the domain level, and take effect for all users on that domain. You cannot have a separate policy for a group of users or even an Organizational Unit (OU). If you create a password policy for an OU it will only work for local accounts on the computers in that OU.

Third, you may notice that the password policy options are somewhat limited; there are only six. For most systems, following the recommendations in the Windows Server 2003 Security Guide is appropriate:

Why You Should Not Use Account Lockout
Even though the guide recommends configuring account lockout at 50 tries, I urge you not to configure account lockout. First, the chances that an attacker will guess a reasonable password are so remote as to not justify this option. Second, an attacker is highly likely to take your account lockout setting and convert it to a denial-of-service attack by locking out every account on the system. Third, most vulnerability assessment tools will lock out all the accounts on your domain. In the end, whether you use account lockout is a matter of your security policy, and debate whether it provides value.

Keep in mind, however, that account lockout problems represent some of the most frequent technical support issues with Microsoft support services, and resetting an account costs an average of $70 per incident. If your security policy is so stringent that you believe these numbers are acceptable, and your policy cannot enforce reasonable passwords, you might still choose to configure account lockout. If not, do your Help Desk and budget a favor, and avoid it.

Enforcing Unique Requirements
As you probably realize by now, password policy settings in group policy are not very flexible and may not even guarantee good passwords. For instance, unless you also go to Computer Configuration:Windows Settings:Security Settings:Local Policies:Security Options and configure the "Network security: Do not store LAN Manager hash value on next password change" setting, you will still store the weak LM hash. In addition, just because you require complexity does not mean passwords cannot be guessed or cracked. Finally, you cannot require password lengths greater than 14 characters due to user interface limitations in Group Policy.

There is a way to solve these problems, but it requires programming skills. You can write a custom password filter. A password filter is simply a DLL that receives a clear-text copy of the password when the user changes his or her password. It can then process that password and ensure it meets unique password requirements. It will look the password up in a dictionary, ensure there are no symbols in the 8th position of an 8-character password, make certain there are no company-specific words, and so on. The limit of the elements you can check is only what you can program and how fast you need it processed. For instance, some organizations use password filters to ensure that administrators have stronger passwords than users.

There is one last thing you need to know about password filters. While they are extremely powerful, they are mostly string processing functions written in C/C++, and the DLL containing the filter is loaded into the LSA process on the domain controllers. This would be a terrible place to have a buffer overflow, and if you are not extremely careful when writing your program, you run a serious risk of that.

Creating Pass Phrases
Finally, here are a few tips on how to use pass phrases, if that is your choice. First, a pass phrase needs to be more than 4 words long, preferably at least 6, to be as strong as a totally random password. Second, the words should not be short. Short words can be cracked very efficiently with standard password crackers. Third, character substitutions and/or misspellings considerably strengthen the pass phrase. You can also include some spaces, but exclude others, to achieve the same level of strength.

Fourth, the sentences need not be intelligible. In fact, it is harder to crack a pass phrase if they are not. Finally, using a combination of upper and lower case letters, and including numbers and symbols, is absolutely essential. Preferably, the symbols should not be selected from those above the numbers on the keyboard. Those are the first symbols attackers try.