Custom Password Filters

  • Article

Back from holiday now, and almost over the jetlag. Almost.

A question came up today about Password Filter DLLs, and the documentation always seems to be hard to find, so I've popped up a quick summary of everything I know here.

Back In The Day of NT4, there was an optional component that Microsoft provided called PASSFILT.DLL that could be installed to perform password complexity checks. These days, equivalent functionality is built in to the base OS (since Windows 2000)(I.e. Windows 2000, 2003, 2008, 2012, 2016, etc etc).

Anyway, the problem is that the Platform SDK article Installing and Registering a Password Filter DLL makes the assumption that you want more security than Windows' default password complexity check, and so lists the final step as being:

4. Ensure that the Passwords must meet complexity requirements policy setting is enabled.

If you'd written a filter that, say, only checked that the user wasn't using their own name as a part of the password, and you wanted this check to be an additional check over the Microsoft built-in password complexity filter, this would be a Good Thing, because a password is only considered valid if it satisfies all installed password filters. It's an AND relationship:

  • Filter1 must return true AND
  • Filter2 must return true AND
  • Filter3 must return true

So, all the filters run for every password change, and if they all say "yep, that's fine with me", then the password change is successful.

If you wrote a filter that checked for the word "Micro$oft" (or a 1337 derivative of your own company name) in a password, and rejected it if it was present, and followed the instructions at the above link, you'd have a system that would accept:

  • strong passwords (as defined by your Windows complexity policy)
  • that didn't contain that particular word (as defined by your filter)

To extend the model, if your company had compiled a massive database of personal information on its employees,  you could similarly check that they weren't using their wife's name, blood type, social security number (Hello Americans!), dog's name, daughter's boyfriend's name or brand of hair gel as a part of their password, and be assured that the password met Windows' password complexity requirements... though slightly more seriously it's a good idea to keep these things somewhat lightweight.

The Windows Password Complexity setting simply enables or disables the default "complex" Windows checks, so you don't have to muck around with DLL installation and removal to get the regular "complex" stuff, it just sets a registry key (via policy). The Windows password filter is always installed and always runs to some extent, it just doesn't always take action (depending on those registry settings).

Over the years I've worked with password filters, it's (disappointingly) been reasonably common that some customers actually want reduced security in the password complexity space (often because it's more difficult to upgrade legacy systems that can't handle > 5 character passwords and lower case, or other similarly horrific constraints). As the alternative is "no password complexity" at the Windows filter level, we're not really that flexible, and any security measure is potentially better than none.

If you're coding a password complexity filter that is meant to replace rather than complement the Windows complexity checks, you need to disable the "Passwords must meet complexity requirements" setting to make yours the One True Password Filter (assuming no other custom filters are installed that make it impossible to produce a valid password... be careful with that too).

It's worth calling out one other item around password filters - the error message received by clients isn't configurable - the client always assumes the Windows password filter is in use, and is hard-coded to report the Windows complexity requirements (at least in part because there's no mechanism that is used to explain to the client what the problem is.) (Update 2017-04: There was a feedback link here, but... the behaviour didn't change for 20 years, so odds are we've moved on from passwords. And if you can modernize your environment, perhaps you can too? Hello!) (in all non-glibness, consider an unlock gesture tied to a device a more authentic validation than a shared character string which many folks will surrender for a bar of chocolate...) (OK so that was a cheap 2004 reference, but you have a security awareness program in place, right?)