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;
  bComplex = FALSE;
 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 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

comments powered by Disqus

Reader Comments:

Thu, Jan 29, 2009 Anonymous Anonymous

its goods

Wed, Sep 7, 2005 Jon Nashville

How or did you get rid of the error message once the passphrase goes beyond 15 chars. That is one pinch point for our enterprise because of user perception and help desk call volumes.

Mon, Jul 4, 2005 Ramius Anonymous

If you are interested in checking out the tremendous power of Rainbow Tables for password audits of you employees, there are several options available from our site.

We offer both tutorials for password assessment as well as a large selection of Rainbowtables and Dictionary files for this purpose.

Sun, May 8, 2005 nick michigan


Fri, Apr 22, 2005 David Walker Los Angeles

Why not just add NoLMHash value in the registry, then you don't have to have long passwords. And your users don't get mad at you. Your passwords are not LM hashed and thus much safer, and your users are happy campers. Win-win!

Thu, Jan 6, 2005 Dave Anonymous

I would have to think it would be easier to implement a thrid party piece of software, like Password Policy Enforcer, instead of writing a custom DLL to get the job done.
But that's me.

Thu, Dec 2, 2004 joe Anonymous

A couple of items.

1. You don't need to enable the complexity settings GPO setting, it can be disabled. You only need to set DLL name in the notification packages. I have done this several times where a company doesn't want the default MS filter but wants some sort of filter.

2. You should make note that password filters are not trivial things. Done incorrectly you can seriously impact the security and stability of your domain controllers. Filters run at the highest security context possible on a domain controller and are fully exposed to outside influence, coding must be extremely well done so as not to open up security holes.

3. Finally another more userfriendly solution is to disable the ability to natively change passwords and force people through a web interface that can properly feedback what is wrong with the password someone is trying to set. The native feedback system is poor at best.

Thu, Dec 2, 2004 Mark Minasi Anonymous

Mr. Melber, another great piece as always. You may recall that there's another way -- an ADSIEDIT hack that I wrote about on my site. But PLEASE, could you be more specific about building a passfilt.dll? Assuming we downloaded the SDK, what's the full source and what commands would we type to compile and link a DLL of this kind? A step by step would be FANTASTIC! Great article, thanks again.

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.