Password Defense

Every user account on your network needs a password, although Windows 2000 permits user logons with null passwords. After you decide to enforce password usage, you need to determine the password policies you want to enforce. You can set password policies for a domain or for an individual computer; setting a password for an individual computer is useful when you have machines that are in vulnerable locations or that hold sensitive data. Unfortunately, Win2K doesn't let you set policies on a group-by-group basis, only by domain or machine.

To view or manipulate password policies for a domain, open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in and right-click the domain object in the Console pane. Choose Properties from the shortcut menu to open the domain object's Properties dialog box, then select the Group Policy tab. Select the Default Domain Policy GPO link, and click Edit. Then, expand the default domain policy object to computer configurationwindows settingssecurity settingsaccount policiespassword policy. As Figure 1 shows, the Policy pane lists the available domain policies (the same policies exist for local computers). To change the current status of a domain policy (by default, domain password security policies aren't defined), double-click the policy listing to bring up the Security Policy Setting dialog box, and select the Define this policy setting check box.

Unlike domain password security policies, password security policies for individual computers are always defined by default. However, the default settings don't impose any security in addition to the domain policy. Moreover, any policy you've set for the domain overrides any policy you've set for the PC. If you've set a policy for the computer and the domain policy remains undefined, the effective policy is the computer policy. If you've set policies for both the domain and the computer, the effective policy is the domain policy. When you set a new policy for a PC, you need to restart the computer to put the policy and its security settings into effect. After restart, you can see the changes you made in the Local Security Settings window. As Figure 2, page 66, shows, the local policy Enforce password history is the effective policy, which means that no domain policy is overriding the local setting. The following password security policies are available:

Regardless of the domain policies you set, you can also set the User must change password at next logon, User cannot change password, Password never expires, and Store password using reversible encryption policies for any individual user by configuring the Account tab of the user's Properties dialog box. Those individual-user policies override domain policies.

Some password security policies are interdependent, and others are mutually exclusive. For example, if you permit password changes immediately by not setting a minimum password age, you can't select the Enforce password history option. If you want to permit blank passwords, you can't set a minimum password length. And if you use Enforce password history to specify the number of passwords people must use before they can employ a previous password, you must also specify a number of days in the Minimum password age section of the Security Policy Setting dialog box.

Even if you don't enable the strongest password security policies available, you need to develop a procedure for determining passwords and distribute instructions to your users. For example, set a rule that every password must contain both numbers and letters. Or tell users to avoid using any part of their names in their passwords. Users with access rights to sensitive material (e.g., company payroll records) need to avoid using any recognizable phrase in their passwords so that other staff members can't guess the password. These recognizable phrases include numbers that refer to birthdays, names of spouses or family pets, or any other references that coworkers might know.

Using Strong Passwords
Enabling the Passwords must meet complexity requirements (aka strong passwords) policy means that the OS helps you maintain security by enforcing rules when users create passwords. When you enable strong passwords, passwords become more difficult to guess and "dictionary attacks," in which software randomly tries passwords in order to break in, are less likely to succeed.

Strong passwords use a device called a notification package, which uses a .dll file that contains password rules. You can't configure the rules that are in Win2K's default notification package, passfilt.dll. However, you can write your own notification package if you want a different set of rules. You'll find the source code for passfilt.dll in the Microsoft article "HOWTO: Password Change Filtering & Notification in Windows NT" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q151082), and you can use it as a model for writing your own .dll file. The .dll source code is the same for Win2K and NT. Passfilt.dll contains the following rules, which apply as users create passwords.

If you enable strong passwords, you need to consider the settings for password uniqueness. Users might have difficulty inventing strong passwords, and some administrators let a user repeat a password after one or two changed passwords. The rationale for this policy is that because the passwords are difficult to crack, security doesn't suffer when users can reuse an old password after only a short amount of time.

Complicated passwords also increase the chances of typing errors when users enter the password during logon. A more common problem is users forgetting characters in their passwords. Users solve this problem in several ways that compromise security, such as by writing their passwords on notes that they affix to their monitors or by leaving themselves notes in unlocked desk drawers.

Administrators who enable the strong password feature do so because they want to apply the maximum password security features available. Forbidding repeated passwords until a large number of intervening passwords are used certainly tightens security. My advice is to implement the strongest security measures at first. If you run into problems because users can't come up with a series of strong passwords, you can lower the specified number of passwords.

Win2K enforces strong password rules only when a user creates a password over the network (i.e., when the user is working on a computer connected to other computers). The strong password rule isn't active when an administrator writes a user password directly to the SAM, so you can open Active Directory Users and Computers and enter a user password that doesn't qualify as a strong password (let's call it a "weak password"). This action lets you enforce strong password rules on a user-by-user basis. If security is of sufficient concern to warrant implementing strong passwords, use this bypass sparingly. Apply it only to users who have secure workstations or low access rights.

If you enter a weak password for a user in AD, the user must use the strong password rules when he or she creates a new password after the specified time for password changes has elapsed. By selecting Password never expires in the user's Properties dialog box, you can let the user continue to use an administrator-assigned weak password. If you have a reason to give the user a new password, create the password yourself in AD to avoid the filters that the rules contain.

Passwords on the Front Line
Password security is a front-line defense in enterprise security. When you use policies that strengthen password security, be sure to notify users about the new password environment and provide easy-to-follow instructions for creating and changing passwords.

Additionally, intruders sometimes use software that helps them crack passwords. If you can obtain a copy of one of these programs, test your passwords by running the software on various computers within your enterprise. If the software cracks any password within 1 minute, ask the user to create a new, more complicated password.