Compartilhar via

Custom Password Filters

  • Artigo

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?)

Comments

  • Anonymous
    January 01, 2003
    If elected I solemnly promise no further technical content until FY07.
  • Anonymous
    January 01, 2003
    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.
  • Anonymous
    December 12, 2014
    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
  • Anonymous
    July 01, 2015
    Tristan,
    We're trying to discourage the development of a password filter policy/DLL.
    Do you have any documentation to help us in our mission?

    Regards,

    Carlos Eduardo Marins.
  • Anonymous
    July 05, 2015
    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.
  • Anonymous
    November 09, 2016
    The comment has been removed
  • Anonymous
    March 01, 2017
    hi can i force more than 3 categories in the password complexity which mean to require Upper case , lower case , digits m special characters[TK] You'd need to use a custom password filter for this, as far as I know. (Unless something changed as of 2012 or 2016)
  • Anonymous
    August 08, 2017
    Any idea if Microsoft or anyone else is going to support the newly ratified NIST 800-63b authentication standards?
    • Anonymous
      August 08, 2017
      (Uninformed opinion) I'd imagine you'll see at least a mapping to an assurance level. (Over time.)Abstract for NIST 800-63b for anyone reading:These guidelines provide technical requirements for federal agencies implementing digital identity services and are not intended to constrain the development or use of standards outside of this purpose. These guidelines focus on the authentication of subjects interacting with government systems over open networks, establishing that a given claimant is a subscriber who has been previously authenticated. The result of the authentication process may be used locally by the system performing the authentication or may be asserted elsewhere in a federated identity system. This document defines technical requirements for each of the three authenticator assurance levels. This publication supersedes corresponding sections of NIST Special Publication (SP) 800-63-2.
  • Anonymous
    September 11, 2017
    Any change to tie or integrate this with Fine-Grained Password Policies? Some companies are requiring different complexity to regular users, C-Level users, IT Admins.[TristanK: Not that I know of, but I'd imagine - but haven't tested - that Password Filters layer over FGPPs, so as long as your FGPP defines the length and complexity requirement, any additional checks performed in your password filter will be on top of that. If you try it, do let me know how it works!]