Avoid Confusing Messages Caused by Password Filters

Users wanting to change a password in Windows NT or Windows 2000 may stumble across a strange error message shown in Figure 1: “ Your password must be at least 0 characters and cannot repeat any of your previous 0 passwords. Please type a different password.”

“At least zero characters”? “Any of your previous zero passwords”? Obviously, there’s something broken here. To understand what it is and how to cure it, we must take a look at the password filtering functionality. Password filtering allows you to enforce that the passwords that users choose meet certain criteria which you can define yourself; e.g., that they should not contain the user’s name. Filtering was introduced with NT 4.0 service pack 2 and was first described in Microsoft Knowledge Base article Q151082. This article, as well as the corresponding SDK article “Password Filters,” should be considered important reading; they provide essential hints on how to implement password filtering on your system or network.

In a nutshell, to do your own password filtering, you write a “filter DLL”, copy it to the system32 directory, and enter its name (without the .DLL extension) in the registry under

HKEY_LOCAL_MACHINE\
       System\
       CurrentControlSet\
       Control\
       Lsa\
       Notification Packages 

“Notification Packages” is a value of type REG_MULTI_SZ, so it may contain multiple DLL names. Every time someone wants to set or change a password, all DLL’s listed here will be called; more precisely, their “PasswordFilter” entry point will be called. Within this function, each DLL can inspect the new password in whatever way it likes and tell the system whether it accepts it or not by returning true or false, respectively.

Microsoft ships NT (once again, since version 4.0 service pack 2) with a sample filter DLL called PASSFILT.DLL. It accepts only sufficiently complex passwords, those consisting of a mix of upper and lower case letters, numbers, and special characters. (See the Knowledge Base article for details, which also contains the source code of an early version of PASSFILT.DLL.) You install this DLL as I just described.

In Windows 2000, the functionality of Microsoft’s PASSFILT.DLL is built right into the system. An administrator can enable it simply by selecting “Passwords must meet complexity requirements” in the Local Security Settings dialog of the Administrative Tools control panel applet, see Figure 2. You can still add your own filter DLL’s in the same way as for NT 4.0.

What happens if any of the filter DLL’s rejects a password? Well, that’s exactly the case that causes the error dialog shown in Figure 1 to pop up. But where do those two zeroes in the message string come from? These are the values the administrator has chosen as minimal password length and “password history length.” (A password history length of “3”, for example, means that the new password must be different from the last three valid passwords.) In Windows 2000, you can configure these two settings in the same dialog we already mentioned a moment ago (Figure 2). Under NT, you start User Manager instead, and select Policies / Account from the menu (Figure 3).

So, by now we know the two prerequisites for the strange message in Figure 1: First, there must be a password filter DLL installed (for Windows 2000, enabling the built-in filter suffices); and second, the minimum password length must be zero and/or the password history list must be off.

Sure, an administrator shouldn’t enforce extensive password checks and in the meantime allow the system to accept empty passwords. But wouldn’t it be nice if a password filter DLL cared about this by itself, thus avoiding irritating messages? The filter DLL described here, PwFilter, demonstrates how you can achieve this — or at least come very close to it. Listing 1 shows the main module, PwFilter.pas. Actually, its filter function, PasswordIsSafe, is all too simplistic: it accepts every password containing at least one digit and one non-digit, but that’s okay. For this example, the central point is to show how to get rid of the zeroes in the error pop up.

The idea is simple: the filter DLL should examine the actual system settings for minimal password length and password history, and if they are 0, replace them with more reasonable values, which Windows may then copy into the error message string. The Windows API offers functions for reading and setting these policy parameters, namely NetUserModalsGet and NetUserModalsSet. But don’t even think about calling them in the context of the PasswordFilter function of your DLL: the system will hang, probably because Windows has locked the policy database to avoid conflicts. So what now? Luckily, a filter DLL may contain two additional entry points: InitializeChangeNotify, called when the DLL is loaded, and PasswordChangeNotify, called every time when all filters have accepted the new password and Windows is about to store it.

It seems to make sense to check and correct the password policy as soon as possible, that is, from within InitializeChangeNotify. However, once again we are experiencing problems with the NetUserModals functions: InitializeChangeNotify gets called at a rather early point during system startup — a point where network support isn’t yet completely initialized, and so these functions fail here. To work around this, InitializeChangeNotify in PwFilter spawns a new thread (CheckPolicyThread in Listing 2) to handle the policy settings. Since there seems to be no system event signaling “network support is up and running” (perhaps you know of one? If so, let me know.), the thread simply tries for at most ten times during 60 seconds to get access to the password policy and modify it as necessary.

From then on, everything is fine — at least if the system administrator is cautious. Of course, he or she can mistakenly reset the minimum password length to zero, and then the next time someone tries to change a password, that nasty zero may reappear in the error message. To at least partially protect against such careless administrators, PwFilter re-checks the password policy every time a password is successfully changed: it implements a PasswordChangeNotify routine for this purpose only.

In Windows XP, Microsoft has changed the text in the dialog to “The password you typed does not meet the password policy requirements.” But this is an incomplete solution. Microsoft should allow password filter DLLs to export one more entry point, say “PasswordFilterWithErrorText”, so that every filter DLL can clearly explain why it rejected a given password.

One last caveat: Filter DLL’s receive passwords in cleartext. So if your functions make local copies of them, don’t forget to zero out your buffers before returning; otherwise, the passwords may be left dangling around in memory, inviting spying eyes.