Custom Password Filters

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+).

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”, 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, 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 Windows checks, so you don’t have to muck around with DLL installation and removal, just 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 – at least, as of XPSP2 that’s still the case. If you’d like to be able to customize the client-side message, go tell the product team).

Comments (6)

  1. Anonymous says:

    If elected I solemnly promise no further technical content until FY07.

  2. Tristan K says:

    Sorry, it’s been about that long since I last worked with them. I believe I heard that some companies have an extensible model which gets their interesting processing done outside of the LSASS process (say, via a service or web service with a rules engine).
    Anything which stops you writing code for deployment in LSASS is probably a good thing.

  3. Woodhall322 says:

    Hi Tristan,

    This is a short and sweet article. I am eager about setting a password filter policy/DLL for my current employer, however I am really struggling to find anything on the web which is useful. All I can seem to find is the odd password policy enforcer software
    company who charge a small fortune for their solutions.
    I appreciate this article is tipping 10 years old, however I would appreciate if you can direct me to a useful site/guide?

    Many thanks

  4. Marins says:

    We're trying to discourage the development of a password filter policy/DLL.
    Do you have any documentation to help us in our mission?


    Carlos Eduardo Marins.

  5. Tristan K says:

    Carlos: AFAIK, the only documentation is the MSDN documentation. You could post your own list of pros and cons in the security forum for a discussion of their merits.

  6. Kees says:

    Might want to try activepasswords . Its a very flexible and configurable password validator (and optionally syncs user accounts and grous too). The rules can be applied to selected active directory groups.
    [Wouldn’t normally allow such posts; search for this if it’s what you want. Link stripped: original URL was for Wizardsoft.]

Skip to main content