In-Depth

New Password Mantra: Go Long

New hacking methods make short passwords unsafe, but Microsoft makes it tough to go long. Her's how to forge an effective policy.

It's time to raise the bar on minimum password length requirements. Password cracking tools are now readily available that decrease the time it takes to break passwords by an order of magnitude over their predecessors, meaning yo're not nearly as safe as you once were with seven-, 10- or even 13-character passwords.

With this in mind, I decided a minimum password length of 20 characters was warranted. But when I got knee-deep in attempts to raise the bar, I found that it wouldn't be so simple to enforce. Microsoft's own documentation on how to do it, in fact, was wrong.

GPO Editor: No Help
On my journey to find the fastest and easiest method to raise the floor on the minimum password length, I started with the obvious choice—the Default Domain Policy.

I opened the GPO Editor with the Default Domain Policy as the target, and expanded the GPO down to the Account Policies, found under Computer Configuration|Windows Settings|Security Settings. This is where the Password Policies node lives, including the Minimum Password Length policy. Editing the policy reveals that the spinner will allow a password length from 0-14 characters.

Given that 14 wasn't high enough, I considered next how I could change the underlying files associated with the Default Domain Policy to let me raise the limit.

Security Templates: Nada
I turned to the security template, to see if that would allow me to configure the minimum password length to 20 characters. Using the MMC, I opened the Security Templates snap-in. I created a new template and configured the minimum password length to 14 characters. After I had the new security template created, I edited the file, which resides under C:\Winnt\Security\Templates. Using Notepad, I changed the value of 14 to 20. I saved the file and opened up the new template using the Security Template snap-in via MMC; it showed a value of 20 for the minimum password length.

From here, I needed to import the new security template into the Default Domain Policy.

I followed these steps to import the security template to a GPO:

1. Edit the GPO using the Group Policy Editor.

2. Expand the Computer Configuration|Windows Settings|Security Settings node.

3. Right-click on Security Settings and select the Import Policy menu option.

4. Locate and click the new security template file, then click the Open button.

5. Close the GPO.

To test the new setting, I forced GPO replication and went back to the Default Domain Policy to see my new configuration. The configuration didn't take.

Next Up: Net Accounts
Next I tried to use the Net Accounts command-line tool to view and configure the Password Policy settings. To view the settings, I typed the following at a command prompt:
Net accounts
The results of the command are shown in Figure 1.
To configure the password length, I typed the following command:
Net accounts /minpwlen:20
This didn't work either. It appeared that the hard-coded limitation of 14 characters goes beyond the GPO editor and security templates—it also goes for anything that attempts to change the minimum password length above 14 characters.

Figure 1. The Net Accounts command gives a comprehensive listing of password settings.
Figure 1. The Net Accounts command gives a comprehensive listing of password settings. (Click image to view larger version.)

As you can see, regardless of the tool that I used, I was limited to a 14-character limit for the value of the minimum password length. This isn't due to a configuration problem in the implementation of Active Directory (AD). Rather, it's an interface limitation to keep AD from isolating Windows 9X and Windows NT computers (which only support 14-character password lengths).

Last Gasp: Build a Filter
The final option was to try a password filter. I customized my own password filter, similar to the old passfilt.dll for Windows NT.

The password filter allowed me to configure not only the minimum password length, but many other password-related variables, including:

  • Can't use username (the password can't be the same as the username)
  • Minimum number of characters
  • Number of character types—upper case, lower case, numeric, non-alphanumeric and UNICODE characters
  • Restricted words for passwords

I had to do some coding and searched the Security SDK and MSDN for "password filter," where I found some guidance. Here's a sample snippet of code for the password filter:

if(cchPassword > 20){
 for(i = 0; i < cchpassword="" ;="" i++){="">
  if(CharType[i] & C1_DIGIT) { dwNum = 1; continue; }
  if(CharType[i] & C1_UPPER) { dwUpper = 1; continue; }
  if(CharType[i] & C1_LOWER) { dwLower = 1; continue; }
  if(!(CharType[i] & (C1_ALPHA | C1_DIGIT) )) { dwSym = 1; }
}

if(dwNum + dwUpper + dwLower + dwSym) = 4)
  bComplex = TRUE;
else
  bComplex = FALSE;
}
else
 bComplex = FALSE;

Once I had my passfilt.dll created, I needed to place it on the domain controllers (DCs)—all of them. I placed the file in the Windows installation directory on each DC, then registered the new file:

1. I accessed the HKLM\System\ CurrentControlSet\Control\Lsa Registry key.

2. The Notification Packages subkey already existed, so I added the name of the password filter to the existing value data (I didn't include the .DLL extension). I also left the existing data unmodified. (Note: If the Notification Packages subkey didn't exist, I'd need to create it. Then I'd add the name of the password filter for the value data [not including the .DLL extension]).

Then I made sure the "Passwords must meet complexity requirements" policy was enabled in the Default Domain Policy GPO. This setting also needed to replicate to all DCs in the domain. But it did, finally, work.

No thanks to Microsoft, though. My calls to Redmond usually got me a "Wow, you're right, you can't change it there!" response. The general consensus was that changing the minimum password length to 20 characters wasn't possible in Windows 2003, or any other Windows versions. Other research on the topic turned up nothing worth while. In the end, it's a do-it-yourself operation, but one that can be done.

Girding the Troops
So, how do you prepare for the storm surely coming your way after implementing such a strong password policy? Education is the key. Take steps before you even touch the security template or GPO. Craft a memo describing why longer passwords are important, when users will need to update their passwords, how many passwords they'll need to use before they can reuse them, and the proper way to view a longer password.

One thing I suggest is to not call it a password anymore. 2%3uayUQfaisy&* 782@4321 is not a password—it's a passphrase. But the beauty of the passphrase is that it doesn't have to be jibberish to be powerful. Its very length gives it power. (Go to Redmondmag.com for my previous column on that topic and use FindIT code Nirvana.) Patient explanations and long lead times to get used to the concepts will go a long way in helping secure the environment and making the transition easier for users.

Despite all your efforts, you'll still likely run into resistance. Be prepared to man the phones, and to deal with angry and frustrated users. Explain to each and every user why longer passwords are more secure than shorter passwords, and stand firm on your decision—company resources are at stake.

More Information

Featured

Most   Popular