The Great Debates: Pass Phrases vs. Passwords. Part 3 of 3

This is the final article in our series on passwords versus pass phrases. The first part covered the fundamentals of passwords and pass phrases, how they are stored, and so on. The second part focused on relative strength and detailed mathematical approaches to determine which is stronger. This final installment concludes the series and gives some guidance on how to choose passwords and configure a password policy.

On This Page

Password Advice

Whether pass phrases are better than passwords seems to be a matter of personal preference. Certainly a pass phrase of 9 words is stronger than a password of 9 characters but if you can’t type that many words accurately, it is much worse. In addition, if the user mouths the pass phrase while typing it, little has been gained. In the end, until we perform further research, we cannot state conclusively that one is better than the other. There is one crucial factor to remember, however. For the estimate of password entropy to be valid, it is necessary to use a completely random 9-character password. The estimate of entropy for the words is conservative enough to account for sentences that actually make sense. This may be the second largest argument for pass phrases over passwords: they are easier to remember. If you agree that pass phrases are easier to remember, use them. You will not be worse off than if you use passwords.

Making Pass Phrases Stronger

There is one more thing to consider; namely, that you can easily add additional entropy to a pass phrase. At some point you have probably created a password with an @-sign instead of an a, $-sign instead of an s, ! instead of an I or 1, and so on. Well, you were not the first person to do that. In fact, every decent password cracker knows how to look for those substitutions. They add very little strength to your password. In addition, since the entropy calculations for a password assume that the 9 characters are selected at random from 72 symbols, the entropy calculations for a pass phrase make no such assumptions. If we add some substitutions to the words in our pass phrase, we basically remove them from the dictionary, and make cracking much, much harder. How much harder? Well, the upper bound on how much harder it is to crack a pass phrase with substitutions is determined by the inherent entropy in our character set. If we add 10 symbols to our 26-character set, we get a 36-character set with 5.17 bits of entropy. Each of the 29 symbols in our pass phrase is now worth 5.17 bits, earning our pass phrase 150 bits of entropy. Since that is actually more than the 128-bits used for the hash, we have achieved the highest possible entropy. To estimate the lower bound, we can probably use Shannon’s projections, and assign entropy of 66.7 bits to our pass phrase. That is a wide range, but clearly makes cracking the pass phrase much harder.

There is one more way to estimate the additional strength created by substitutions. http://www.ukradioamateur.org/extra/morse/html/c28.htm gives estimates of letter frequencies in the English language. It shows that we might have 21 different letters in our 25-character phrase, not counting spaces, and that the most common are E (3.25), T (2.3), N (1.98), R (1.9), and O (1.88). While I do not know of any common substitutions for N and R (or their lower-case equivalents), I do know that 3 is often substituted for E, 7 for T, and 0 for O. There are up to 7 of these characters in the password (|3.25|+|2.3|+|1.88|), and the user may have exchanged any combination of them. Thus, there are 2^7=128 different combinations of this pass phrase. Consequently, the pass phrase is 128 times stronger if we assume that one or more letters was switched even for the most common substitutions. If the user employs uncommon substitutions or misspellings, the pass phrase is even stronger.

Enforcing Password Policies

After reading these articles, you may decide to change your password policy to enforce pass phrases only, or in some other way. How do you do that? First, you determine a password policy in group policy, but here are some tips for how to do so.

First, 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:

Maximum password age – Ensures that passwords are cycled frequently enough to make cracking or guessing them harder. Recommended setting: between 42 (the default) and 90

Minimum password age – Ensures that users cannot cycle through the password history and use a past password. Recommended setting: 2

Minimum password length – Ensures that passwords have a minimum length to make them harder to crack. Please note that storing LM hashes from 7 to 8 characters provides minimal benefit. See the first article in this series for details. Recommended setting: 8

Passwords must meet complexity requirements – Ensures that passwords have a certain minimum complexity. This setting ensures that passwords include at least three symbols from the four categories (upper-case, lower-case, numbers, non-alphanumeric symbols), and that they do not contain the user’s first or last name or any portion of the user’s name. Please note that passwords that meet these requirements are not necessarily strong. For instance, the password “Password1” meets these requirements. Recommended setting: Yes

Store passwords using reversible encryption – Reversible encryption is used in systems where an application needs access to clear-text passwords. It is not usually needed. Recommended setting: No.

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, as the initial article of this series described, 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.

A full discussion of how to write a password filter is beyond the scope of this article. For full details, please refer to the following resources:

Documentation for the PasswordChangeNotify, InitializeChangeNotify, and PasswordFilter functions in the MSDN Library http://msdn.microsoft.com

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.

Conclusion

In this article, I have applied some logic and empirical research to the old debate of whether pass phrases are stronger than passwords. Before drawing any conclusions, however, it is critical that you realize that this is a theoretical discussion. If an attacker has access to crack your password hashes, s/he has already hacked your domain, and your network is completely compromised. In addition, cracking is unnecessary if the attacker has access to a tool that can consume password hashes directly. Also, if your users don't understand password security and believe in it, no password scheme will work.

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. Contrary to what your grade school teacher taught you, there actually is value in misspelling things!

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.

If you have gotten this far in the article series and are considering using pass phrases, we would like to ask you a favor. Please think of another pass phrase (not the one you are currently using) and mail it to us at passstud@microsoft.com*. We will use the submitted pass phrases to study the relative composition and strength of pass phrases to develop a better understanding of how they are used. If we get enough results, I might write a follow-up column discussing them.

As always, this column is for you. Let us know if there is something you want to discuss, or if there is a better way we can help you secure your systems. Just click the Comments button below, and send us a note.

*We will only retain the pass phrase you send us so we can perform our analysis. We will not store your email address or any other personal information you send along with the pass phrase. The pass phrase you send will be aggregated with the other pass phrases we receive and will not be associated with any of your personal data sent in your email.