What risks can (and should) your password policy address?
In "What's the Password?" February 2006, InstantDoc ID 48891, I discussed the password-resetting process and how to manage authentication so you can be assured that requests for reset passwords are legitimate and that those reset passwords are getting to the proper users. Now, let's return to the subject of passwords to discuss the core concept of Windows authentication controls and examine the role password policy plays in protecting passwords.
Defining Password Policy
Like almost any system that uses passwords for authentication, Windows lets you define requirements for keeping the passwords (and thus authentication) strong. A domain's password policy is defined in one or more Group Policy Objects (GPOs) linked to the root of the domain. (Don't confuse domain password policy with password policy for local accounts, which can also be set through GPOs.) By default, there's just one GPO at the root, and it's called Default Domain Policy. When you open this GPO and navigate to Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy, you can see the password policies that are enforced for all domain users, as Figure 1 shows. Before configuring these options, you need to clearly understand which risks a password policy addresses and which risks it doesn't.
Risks to Password Security
The two main risks to password security are online password guessing attempts and offline password cracking attacks. An online guessing attempt occurs when an attacker repeatedly tries to log on—either manually or by using a program—with a username and a guessed password. Depending on the authentication protocol, an offline cracking attack can occur when someone steals a user account database that contains the hashes for all passwords and then uses a cracking tool that attempts to come up with the password that corresponds to each hash. A cracking tool typically performs the hash algorithm on a set of possible passwords (either a list of common words or a list generated from a character set) until it finds a password that results in the same hash as one of the hashes found in the stolen account database. At that point the cracking tool discovers the password associated with that user and reports it to the attacker.
As you can see, guessing and cracking are fundamentally different. To be able to crack passwords, you need the hash or information based on the hash. (In some cases, you can crack a password if you've acquired information derived from the hash, for example, from the NT LAN Manager—NTLM—authentication protocol's challenge-response packets sniffed from the network.)
Then a well-written program can crack the passwords, given enough time. The latest cracking programs can use a rainbow table, which lists every possible password and its hash. Rainbow tables make password cracking nearly instantaneous.
What Password Policy Can't Do
Because crackers can try every combination of characters in a password, or better yet, look up the hash in a rainbow table, requiring strong passwords and setting minimum password lengths are of little use as a defense against cracking attacks. To defend against password cracking, you must prevent the attacker from obtaining password hashes or derivative information.
In the Windows environment, you must have administrator access or physical access to dump password hashes in crackable format from the SAM or Active Directory (AD). Preventing someone from sniffing crackable authentication traffic from the network is tricky, but by using strong authentication protocols such as Kerberos or NTLMv2 (instead of NTLM), as well as physically securing telecom rooms and using fully switched networks, you can make it reasonably difficult.
Sophisticated attackers can still use Address Resolution Protocol (ARP) poisoning to trick switches into routing packets through a bad guy's node on the network. To defend against these and other sophisticated LAN attacks, you need to use advanced LAN security technology such as the IEEE 802.1x standard and IPsec. With 802.1x, a computer that connects to one of your switch's ports must authenticate itself before the switch can use that node to send or receive packets. IPsec lets a computer authenticate other computers before communicating with them and reject rogue systems. You can also use IPsec to encrypt packets.
What Password Policy Can Do
So, as you can see, enforcing password policies such as minimum length and complexity requirements won't help you defend against password cracking. But it can protect you from guessing attacks by malicious insiders and outsiders. Requiring passwords to be at least seven characters long and enabling complexity requirements increase your network's resiliency against password guessing attacks.
You can further improve your network's resiliency with a good lockout policy. Most password-based systems have some form of lockout policy. The lockout policy for Windows consists of three values that let you control how many guesses you allow each account to sustain over a specified period of time and what happens if a user exceeds those parameters. For example, Figure 2 shows a policy that limits a user to five consecutive guesses (five invalid logon attempts) within any 24-hour period (1440 minutes). If the account is locked out, the lockout duration value of 0 requires an administrator or someone with delegated lockout reset authority to unlock the account.
For many companies, this is a good lockout policy. But what constitutes a "good" policy depends on many factors, and each organization must decide what lockout policy works best for it. By requiring users to select passwords that aren't easily guessed and letting attackers guess only a few passwords before being locked out, you can get the most out of Windows' password-based authentication system.
"Audit Your Passwords," InstantDoc ID 49522