Implement Passfilt Correctly the First Time

\[Editor's Note: Email your Windows 2000 or Windows NT security tips or solutions (400 words or less) to Reader to Reader at [email protected] We edit submissions for clarity, style, grammar, and length. If we print your contribution, you receive $100.\]

I recently deployed network infrastructure enhancements that included implementing a strong password policy. To enforce the policy, I used Microsoft's Passfilt DLL, which requires newly created passwords (not existing passwords) to have at least three of the following four character classes:

  • uppercase letters
  • lowercase letters
  • numeric characters
  • nonalphanumeric characters (e.g., [email protected]#$%<>+)

In addition, passwords can't contain any part of the user's username or full name, and they must consist of at least six characters. Be aware that Passfilt affects only passwords that users create over the network, not passwords that an administrator creates with User Manager. An administrator can still create a simple initial password and require the user to change the password to a strong one at the next logon.

I implemented the DLL according to guidelines from multiple documents, including the SANS Institute's NT security guidelines. However, after my implementation, the DLL didn't enforce password complexity. I did some research and found the Microsoft article "How to Enable Strong Password Functionality in Windows NT" (http://support.microsoft.com/support/kb/articles/q161/9/90.asp), which provides the correct method for implementing the filter. I learned that it's important that you add only the word passfilt to the registry string (use regedt32 to do so), not the complete path to the DLL (the passfilt.dll file must exist in the \%systemroot%\system32 folder).

I also learned that two post-Service Pack 6 (SP6) hotfixes exist for Passfilt. In one problem, Passfilt doesn't accept the slash character (/) as a valid special character in passwords. The Microsoft article "Password Filter Excludes the Slash Character" (http://support.microsoft.com/support/kb/articles/q271/8/62.asp) explains further and provides instructions about the fix. The other problem is that although the strong password policy states that a password can't contain your username or any part of your full name, this restriction isn't enforced. For example, a user named Userfirstname Userlastname can successfully create the password xxx*Userlastname123. The Microsoft article "Strong Passwords May Contain Parts of the Full Name" (http://support.microsoft.com/support/kb/articles/q247/9/75.asp) explains further and provides instructions about the fix. The most current Passfilt hotfix (i.e., passfilt.dll, file attributes 09/08/2000 02:51p 4.0.1381.7086) contains both fixes.

Because the PDC is the only machine on which you make changes to the domain accounts database, only the PDC needs Passfilt. However, putting Passfilt on all domain controllers (DCs) is good practice because you can promote BDCs to PDCs. If you promote a BDC without Passfilt.dll to a PDC, you lose strong password enforcement.

If you're going to go through the trouble of enforcing strong passwords, reducing the chance of compromise (e.g., by password-cracking utilities such as Security Software Technologies' L0phtCrack) is also worthwhile. I recommend installing Syskey to improve the encryption of the SAM database on all DCs. Note that a post-SP6 hotfix is available to fix a problem with Syskey encryption. See the Microsoft article "Patch Available for 'Syskey Keystream Reuse' Vulnerability" (http://www.microsoft.com/technet/security/bulletin/ms99-056.asp) for details about the hotfix.

TAGS: Security
Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish