Password Best Practices

Password Best Practices

After having established how passwords are stored, used, and attacked , we are finally ready to discuss how to pick good passwords. There are several techniques to protect password-based authentication schemes. The first couple involve configuring the system properly.

Protect Cached Credentials

Protecting cached credentials is primarily about minimizing what the attacker gains by obtaining and cracking them. First, we need to keep in mind that cached credentials cannot be used on a different system. They are unique to the system where they were generated. Therefore, they are only useful if they are cracked and the account has access to something that is not on the machine where the attacker obtained the cached credential.

To access the cached credentials, the attacker must be able to run code as LocalSystem or an administrator. If you practice proper defense in depth, do not browse untrusted Web sites as an administrator, and do not double-click attachments, the primary way an attacker can steal cached credentials is to steal the computer. This is usually pretty noticeable, giving you a chance to reset your passwords before they are cracked. Of course, the attacker could exploit some other condition, but this entire book is about defending against that.

Third, if you heed our advice in Chapter 8 about only using privileged accounts on privileged computers, the exposure is very limited because it is unlikely that the attacker can steal a privileged computer. The broad availability of tools to crack cached credentials makes this advice all the more important, however.

Finally, it is highly recommended to disable storing the cached credentials on any machine where they are not needed. This applies to at least the vast majority of servers and probably most workstations as well. Cached credentials are designed primarily to be used on laptops. You can disable them on other systems by setting the Group Policy setting "Interactive logon: Number of previous logons to cache (in case domain controller is not available)" to 0. This causes the system to not generate cached credentials at all. Just remember to exclude laptops from this policy.

We once had an argument with someone who advocated removing the cached credentials feature altogether. We find this advice not only shortsighted, but quite inane as well. If we do not have cached credentials on roaming systems, users would have to log on using local credentials when roaming. Not only will this be extremely inconvenient, as mentioned earlier, the chances that they will use the same password as on their domain logon more than likely approaches 100 percent. If such a system were to get stolen, the attacker would be able to simply steal the hash and then use that to authenticate to the domain, requiring no cracking at all. At least with cached credentials, the attacker is forced to crack the password. Clearly, removing the cached credentials feature would significantly decrease security, not increase it.

Following the advice in this section, you will significantly decrease the exposure against attacks on cached credentials.

Disable LM "Hashes"

In spite of the fact that cracking hashes is unnecessary effort, it is useful to disable storage of LM hashes. For instance, this prevents use of the LM protocol, which is much more vulnerable to cracking of captured challenge-response credentials than NTLMv2. It also disables Windows 9x, which should significantly increase the desire to replace those systems, providing great security benefit in the process.

There are several ways to make the LM hash not get stored; one of them is to use passwords (or pass phrases) longer than 14 characters . You can also use the NoLMHash switchexposed in Group Policy as "Network security: Do not store LAN Manager hash value on next password change." Using that switch, you can globally turn off storage of LM hashes for all accounts. The change will take effect the next time the password is changed. In other words, existing LM hashes in the current password and any past passwords are not removed simply by throwing that switch. In addition, the fact that the effects of the switch are not immediate means any interoperability problems caused by not storing LM hashes will not immediately surface. See Microsoft Knowledge Base article KB 299656 for more information.

You can also remove the LM hash by using certain characters in your password. It is widely believed that using "Alt characters" in your password causes the LM hash not to be generated. This is not entirely correct. Only certain Unicode characters cause the LM hash to disappear. For instance, Unicode characters in the range between 0128 and 0159 cause the LM hash not to be generated. (For a list of all characters below 1024 that cause the LM hash to not be generated, see Table 11-5.) Many other Unicode characters are actually converted into other characters before being hashed , as shown earlier in Table 11-2.

Table 11-5. Character Codes That Do Not Generate an LM Hash

01280159	03060307	0312	03190320
03290331	0383	03850406	04080409
04110414	04180424	0426	04280429
04330437	04390447	04490450	04520460
0477	04800483	04940495	04970608
06100631	06330696	0699	07010707
0709	0711	0716	07180729
0731	07330767	07730775	0777
07790781	07830806	08080816	08190893
08950912	0914	09180919	09210927
09290930	0933	09350936	09380944
0947	09500955	09570959	09610962
0965	09671024

Using Unicode characters in the password requires a bit of caution. Several items will break. They include the following scenarios:

• You will not be able to use this account from a system running Windows 9x unless you install the Directory Services Client. This is because there will be no LM hash and Windows 9x can only use LM authentication.

• The account cannot be used as a cluster services service account unless you also configure the NtlmMinClientSec as shown below.

• The account will not work properly in some command-line situations. Cmd.exe is Unicode internally, but uses the OEM character set for parsing batch files. Therefore, although you can set a password with a Unicode character using net user or passgen.exe, you cannot set or use that password in batch files. Batch files are always parsed as ANSI files using the OEM character set. If you enter one of these characters in a batch file, it will be converted into some roughly equivalent OEM character set symbol. Obviously that symbol does not match the Unicode symbol used in the password, and use of the password will fail. That also means that you should never attempt to set passwords using batch file, particularly if they have Unicode symbols in them. Calling a tool that generates a password, such as the passgen.exe tool on the CD, will work as expected. However, specifying the password using net user, for instance, will cause unexpected results. The passwords will set, but will be set using a relatively unpredictable character set dependent entirely on the locale of the system where the batch file was created. For example, if you use character code 0128 in your password and enter that character in a batch file, it will be interpreted as character 128 by a system using the Western European (Windows) character set. The same behavior may be encountered with other command-line tools, although if they receive stdin directly from cmd.exe they should work fine.

You should also disable the LM and NTLM authentication protocols, as described in the discussion about LM CompatibilityLevel above. Doing so significantly improves your protection level against attacks on captured challenge-response sequences.

Removing LM hashes does require caution, however. The reason they are left on by default is because removing them breaks things. Specifically, it breaks any application that uses UDP-based authentication for RPC. That includes Windows Cluster Services, Office Live Communications Server, and probably others. Those are solved by turning on the NtlmMinClientSec setting, exposed as "Network security: Minimum session security for NTLM SSP based (including secure RPC) clients " in Group Policy. To solve the problem, the NtlmMinClientSec setting needs to be set to "Require message integrity and require NTLMv2 Session security" (corresponding to a hex value of 0x80010). This causes these protocols to use NTLMv2 authentication instead, which uses the NT hash. See KB article 828861 for more information on cluster problems when you do not have an LM Hash. Other applications will also break in the absence of an LM hash. For instance, Outlook 2001 for the Macintosh requires that all accounts used with it must have one. As mentioned earlier, it will also cause problems with Windows 9x. In addition, some third-party products, such as network-attached storage devices, may require LM hashes.

Should Passwords Be "Uncrackable?"

A common misconception about passwords is that they must be "uncrackable." That is not really true. What is true is that most attackers today will crack passwords. However, if we make passwords uncrackable (in whatever sense we choose to understand that term ), the attackers will simply switch methods . Cracking passwords relies on being able to guess the password by brute force against a hash or a captured challenge-response sequence. Making a password "uncrackable" provides no protection whatsoever against a pass-the-hash attack. A 127-character password is just as vulnerable to one of those as a 1-character password. In addition, a 127-character password is no more resilient to a keystroke logger than a blank password. In reality, the only threat an "uncrackable" password actually mitigates is one that relies on an unnecessary method of attack. Thus, creating "uncrackable" passwords does not make you any more secure in an absolute sense. You would be better off focusing on creating "unguessable" passwordspasswords that cannot be guessed remotelythat are at the same time more easily remembered . Then take the spare mental horsepower you would have used to remember an "uncrackable" password and devote it to implementing an alternative to passwords, such as smart cards, instead.

What Should Administrators Tell Users About Passwords?

In the end, passwords put the onus of security on the individual user, making it critical that administrators explain to users how to pick good passwords. There are a few things that most users can actually do when it comes to picking better passwords

Use Long Passwords

First of all, users and administrators alike need to know that longer passwords are better than shorter passwords. The logon dialog starting with Windows 2000 supports 127-character passwords. Use it! The longer the password, the better. That does not mean that all passwords using n characters are better than passwords using m characters, where n > m . It is easy to create an m -character password that is stronger than an n -character password. What this does mean is simply that if you take a given password of size n and add characters to it, it will be stronger than the original password. One technique for doing this is just to pad the password with some number of instances of a random character. For instance, if your password is pas$word? and you pad it so it becomes pas$word?????, the new password is stronger than the old one. Personally, we find those kinds of passwords hard to remember, but if that technique works for you, use it.

Use Pass Phrases

We very often hear the advice to use pass phrases these days. This advice largely stems from the fact that a pass phrase is much longer than a password. As mentioned earlier, pass phrases provide no protection against pass-the-hash attacks. In addition, a password cracker operates by manipulating characters. If pass phrases become commonly used, there is no reason to believe the attackers will not use pass phrase crackers that manipulate words rather than characters. Thus, the mere fact that a pass phrase is longer than a password is a transient benefit at best.

One intriguing possibility with pass phrases, however, is the possibility that users could remember a stronger password because each unit of length requires fewer chunks . For instance, in a completely random password (from the user's perspective), each character is a chunk . In such a password, following Miller's theories mentioned earlier, the user will only remember 7 ±2 characters, giving us a relatively short password. Furthermore, each character is likely to come from a fairly small character set, such as the 76-character set on a common keyboard. However, this loses sight of one thingusers do not use completely random passwords. In fact, they generally do not have seven chunks in them. Consider the password $tockholm1. On the surface, this password has 10 characters. But, are these characters chunks in Miller's definition? No. This password only has three chunks. The first is the word Stockholm . The second is the substitution of $ for S. The third is the appending of 1 to the end of the password. In fact, this password is extremely weak, and if a password cracker can perform hybrid attacks, and includes the word Stockholm in the dictionary, this one would crack in seconds, or minutes at most.

The average length of a word in English is about five characters. In English, five characters is also the number used to measure typing speed in words per minute. Likewise, in a 1995 survey of 45 PGP users, Arnold Reinhold discovered that the average word length used in a PGP pass phrase was 5.3 characters. Interestingly, Reinhold also reported that five eighths of all the words were English dictionary words. In other words, there is a lot of evidence to indicate that five characters is a reasonable estimate of word length.

Going back to Miller, if users can remember a 7-word sentence , they could actually have a 35-character password. There are several caveats with that reasoning, however. First, it is unlikely that a real pass phrase is actually that long. For instance, the author who wrote this chapter currently only uses a 32-character pass phrase, and it is a bear to type. Reinhold also found that the median pass phrase had only four words in it.

Nevertheless, four words may be more than the number of chunks in most user passwords, and it is probably easier to remember, too. As long as the words are not predictable based on each other, this may be a significant advantage of pass phrases over passwords

Use Substitution

A very common technique for "strengthening" a password is to use substitution. For instance, people will change an a to @. The problem with this technique is that attackers know this technique, too. Most of the substitutions derive from these common ones:

• a = @

• i = !

• 1 = !

• e = 3

• o = 0

• s = $

• t = 7

• t = +

• l = 7

• to = 2

• for = 4

• a = 4

• & = @

• & = $

• s = 5

• pee = p

• be = b

• you = u

• ate = 8

• see = c

• for = 4

• to = 2

• are = r

Using one of these substitutions is not worthless; however, it is not as worthwhile as it might first seem. For instance, suppose you pick the password Password1. Using these substitutions, there are only a few additional passwords to test, such as P@ssword1, Pa$sword1, and so on. Generally speaking, the more places there could be a substitution, the more possible passwords the attacker would have to test before finding the right one. In this case, there are four common substitutions, leading to an additional 2^4=16 passwords to try. If the substitutions do not use the common ones, or the original password was not a dictionary word, the password becomes considerably stronger from substitution.

Combining pass phrases and substitution gives us an incredible amount of power. Consider a pass phrase such as "This is my current pass phrase." If we only use the common substitutions, we have 5 different places to use a $ instead of an I (32 combinations), 2 places to use ! instead of I (4 additional combinations, or 128 total combinations), 2 places to use @ instead of a (4 more, for 512 total combinations), and so on. The greater length of pass phrases means that substitutions are incredibly valuable . You can take a pass phrase and make it many orders of magnitude stronger by simply substituting some of the characters for other ones.

There is Nothing Wrong With Writing Down Passwords

It really bothers us when we see "best practices" or security policies that tell people they are not allowed to write down their passwords. There is absolutely nothing wrong with writing down your password. What is wrong is not adequately controlling the place where you wrote them down. Writing down passwords allows us to remember more and better passwords, which in and of itself is actually a benefit. What you do not want to do is write them down and then not secure the written copy. For instance, putting your password on a Post-it note and pasting it to the monitor is bad. Hiding the note under the keyboard is really not much better. Writing it in a Microsoft Word document stored on a USB token that is locked up in a safe is perfectly fine. The key thing to remember is to protect the place where you wrote the password just like you would protect the password itself.

Group Passwords into Categories

Another really useful trick is to group passwords into categories. In an informal survey of about 20 users, all of them stated that they use passwords in many different placestypically between 20 and 50. However, most of these fall into certain categories, such as "finances, work, home, e-mail, recreation, throwaway" and so on. By grouping them into categories like this, you can create four or five different passwords and then reuse them on sites that have similar security requirements and similar protection mechanisms. This allows you to remember a lot fewer passwords. The last category, throwaway , is particularly interesting. Several of the users stated that they do not create permanent accounts, for instance, when they go shopping online. Instead, they create a new account each time, with a password that they do not care whether they can remember. Obviously, that will not work on all sites, but it does work on many and is an interesting and useful strategy.

Finally, a word about password reuse. Passwords can be reused temporally (across time) as well as spatially (across systems). Temporal reuse is almost always bad. Users tend to do this if left to their own devices. One way to restrict it is to use the password history settings in Group Policy. By "remembering" the last n passwords, the system can check that a new password does not match an old one. If you do this, do not forget to set a minimum validity for passwords; otherwise , users will simply change their passwords n +1 times and get back to what they had before.

Another form of temporal reuse is when users just append some character to a password when they have to change it. For instance, if the old password was password the next one might be password1. The only way to enforce a policy against this programmatically is to write a custom password filter, which is discussed later.

Spatial reuse is where users reuse passwords across systems. This can be bad, but is not necessarily so. If the password is only used on systems with the same security requirements, spatial reuse is acceptable. It becomes a significant problem when done on systems of different security requirements, however. Again, there is no way to enforce this programmatically.

Password Best Practices for Administrators

When it comes to passwords used by administrators, you need to remember a couple of key things.

First, do not reuse passwords across accounts. For instance, administrators should have one administrative account for each system class they administer and one information worker account for e-mail, Web surfing, and so on. Reusing passwords across accounts defeats the entire purpose of having multiple accounts. This also means that you should have different passwords on the local Administrator accounts on all systems, or at least one per security class of the system. This would be difficult to manage, but frankly, do you really need the built-in administrator account? If not, why not get rid of it? If you set a really complicated password and then forget what it is, you have basically disabled the account. Considering that the Administrator account is really a disaster recovery account anyway, this makes sense. It is often easier to rebuild the system than to try and recover it, so in some deployments you would rarely use that account anyway.

If you cannot disable the Administrator account, use different passwords for it on all machines. In Chapter 8, we discussed the passgen tool on the CD. Instead of repeating that discussion here, we will just mention that you can use that tool to maintain different administrative passwords on all systems under your control.

Administrator passwords should also be more complex than user passwords, and they should not have LM hashes stored unless absolutely necessary. One way to enforce these complexities is to write a custom password filter that enforces stricter requirements on administrators. It would have to detect the type of user who is trying to change the password and apply different requirements to different users. Keep in mind here that such a password filter would incur significant overhead on your domain controllers, and you need to have adequate processing power to meet the performance needs of even moderate sized domains.

To learn about password filters, look up "notification package" and " passfilt " in the Microsoft Software Development Kit (SDK). You can access it online at http://www.microsoft.com/msdownload/platformsdk/sdkupdate/. Such a password filter incurs some overhead that makes changing the password take longer than it otherwise would, but that is usually not much of a problem.

The preferred way to remove the LM hashes is to use the NoLMHash key. This is not always possible, however, depending on what is in your environment. If for some reason you cannot set this key, you can remove the LM hashes for particular accounts in other ways. For instance, use passwords (or pass phrases) longer than 14 characters. You can also use certain Unicode characters in your password. These are entered by holding down the Alt key (Fn+Alt on a notebook) and typing a four-digit code on the numeric keypad (the numeric overlay keyboard on a notebook). Not all the Unicode characters cause the LM hash to not be stored, however. Some are actually converted into different charactersfor instance used in a password generates the same LM hash as E. Some of the ones that cause the hash to disappear are shown in Table 11-5.

Notice that the characters in the table are four-digit codes, not three-digit codes. The three-digit codes are the extended ASCII codes, and most of those, on most character sets, do cause the LM hash to get generated. The leading 0 is significant here.

One caveat on using Unicode characters: If you use a Tablet PC, the soft keyboard currently does not support entering these characters. If your system has a hard keyboard, however, you can still enter it using that keyboard.

On the Futility of Account Lockout

Before we leave best practices, we have to mention account lockout. Account lockout is a feature that disables (locks out) the account after the password is unsuccessfully typed a predefined number of times. Account lockout is supported in the operating system because certain military specifications require it. It also makes for a lot of heated religious debates. The authors consider that account lockout not only provides no positive security value, but actually decreases security. As we showed earlier, only really poor passwords can be guessed successfully. Thus, the real problem if a guessing attack succeeds is really poor passwordsnot lack of account lockout. Turning on account lockout does not make the passwords any stronger, and a sophisticated attacker will tailor the attack to work around any account lockout settings. Hence the claim that it provides no security value.

Worse than not doing any good, however, is the fact that account lockout is harmful . It can obviously be used by an attacker in a very easy denial-of-service attack to lock out every single account on the system, rendering the system unusable. Now consider if this were to happen to your Web serverit would not be much of a "server" any longer. Moreover, it is highly likely that the account lockout settings are tripped accidentally . For example, almost all vulnerability scanners will trip account lockout settings, resulting in entire data centers being disabled. Finally, even if there is a timeout to the lockout, users will generally call the help desk when their account no longer works. Microsoft's Product Support Services (PSS) estimates that an account unlock support call costs $70 per incident. Consider the cost of the support calls before you start implementing account lockout. If you have 10,000 users, and they trigger account lockout 5 percent of the time when they need to type their passwords, you have 500 lockouts each time your users log on. Typically, they log on at least twice a day, so that is 1,000 events per day. If 20 percent of them call the help desk, you are fielding 200 calls a day, at $70 each. Is attempting to put weak protection in place for weak passwords really worth $14,000 per day in increased support costs? As a cheap intrusion detection system, it may have value, but think carefully before you turn it on.