I’ve been working on a project that’s motivated by a number of pen-test results over the past few years. Though it’s cool to find interesting vulnerabilities, it seems that most of my pen-tests at some point or another benefit from one of the dumbest vulnerabilities ever: guessable passwords. It seems to be an intractable security problem in most places, and this project is my little contribution to help make it better: OpenPasswordFilter.

The point is that the security of any environment has less to do with the patch level of its systems than it does with the security decisions made by the users. It only takes one user to choose a classically bad password to doom the rest of the network to compromise. As domain user populations grow to thousands or tens-of-thousands, the probability approaches unity very quickly that someone has a password of Password1, Summer15, or Company123. Common 90-day password rotation policies are especially bad for this, because they basically train people to think of something that corresponds to that cycle and they end up on a SpringXX, SummerXX, etc., rotation forever.

My primary recommendations in my reports are to implement stronger complexity requirements and conduct password audits. For various reasons, too many places are unwilling to do either – the former due to cost or lack of perceived options and the latter due to the fear of arming administrators with the tools to get user passwords. There’s an obvious critical logic flaw in the second (namely, that admins can do what they want and Google can teach them how to get the passwords out anyway), but the former can actually be addressed.

Microsoft provides a mechanism supporting custom password filters, in which you implement a DLL that is loaded by LSASS on boot that can be called to evaluate passwords when users set them. It’s a very simple interface (all of four functions, and only one of them requires real code), but most organizations aren’t going to write their own. There are commercial options, but they typically fall into the “call for pricing” category.

But it’s such a simple DLL… one function that returns a TRUE or FALSE. I worked up a proof of concept that is very much in the “alpha” stage, but it’s enough to share. The OpenPasswordFilter project exists to provide the following features:

  1. A custom password filter DLL
  2. A user-space service for decision making
  3. User defined dictionaries for forbidden passwords

I definitely intend to add more functionality in the future, but this is a good stab at the basics. The software architecture should be robust enough to allow adding more mechanisms for denying passwords (beyond just a straight dictionary). My goal is to have something actually usable on the cheap to armor a domain against trivial password attacks. I would be thrilled to get feedback from anyone with ideas how to make it better or just to let me know if it works on someone else’s domain.