Many years ago I made a developer create a custom password filter for Microsoft Windows, based on the passfilt.dll source code example. For obvious reasons I will not go into the specifics about when, where, why, how, what etc about that specific implementation. :-)
I've written before about being careful with disclosing your user/logon name, why your password history may be bad for you, what exactly do you/they mean by "wordlist", and even an old article entitled "Experiences with password policies" back in 2005. I could list more, but these are highly relevant for this blog post.
Here's the thing: I don't think implementing static blacklists for passwords really help. On the contrary, I think it is counterproductive as it will just be of annoyance to end-users, and will easily be circumvented. In the long run you will end up with users whispering behind your back about words NOT caught by the filter. Of course they will not tell you, as you are Mordac, the preventer of information services.
However there is another problem that may be of even greater risk than those end-users poking around with easy-to-guess passwords. Helpdesk. Yup, that's right. The people who has their performance measured by the number of support calls they can open and close in 45 seconds or less. Do you really think they are so creative they give out unique and easy-to-read length 15+ passphrases to every caller? No way buddy, no way. Most likely they will use a very limited set of "default" passwords, that change only every few years or so. If there's a bunch of new people starting at your company on Monday, they probably get the same password for starters, all of them. Sure, they will have to change it upon first logon, but with default Microsoft Windows, you can't really set a time limit for disabling the accounts if the password doesn't change in n days. That's too bad.
So here is my quick and dirty suggestion. I've given this a bit of thought, I have already attacked my own idea and have some objections, but I'd like to hear your comments first. Based on my primary experience within the corporate world filled with Windows desktops and valuable data stored on Windows servers, I'm kind of biased here (forgive me...):
Dynamic Prevention of Common Passwords
We'll implement a custom password filter (passfilt.dll) that uses a good HMAC to create a value for the new requested password by the user. This value will get stored either locally or in a centralized file/database, along with a count value. (In all honesty, as long as Microsoft continues using LANMAN and NTLM (no salting), it doesn't take much to do better....). This filter will be deployed to all domain controllers, to enable the filter for domain accounts.
Using a configuration file (no hardcoding, thx!), we'll set a threshold value N for how many simultaneous occurrences of the same password we'll accept among all accounts.
As soon as the filter receives a cleartext username + password for control, the filter will first check the bare minimums (length, complexity, similarity to username etc, if applicable), then proceed to hash the password, and check that specific hash value for number of occurences in the file/database that is dynamically updated. If there already exists N occurences of that hash value in our file/database, the password will be rejected.
The main purpose of this is to prevent a high number of accounts having the same password at the same time, with the most common passwords in corporate environments being tied to date/day/month/year and seasons. However, with such a dynamic filter in place, we'll effectively block any and all attempts to set the same (bad) password across multiple accounts, no matter the source.
In combination with a decent password policy and the removal of the LANMAN hash values, we'll have a better and wider selection of passwords in use at any given time. We'll effectively increase the time needed to successfully recover (crack) X passwords, while reducing the maximum number of accounts that can be compromised through the successful recovery of a single password (NTLM hash value).
--
Now, this is just some stuff I've been thinking about during easter, so be gentle with your comments. As I said earlier, I've attacked my own proposal already, and have some objections. Before I eventually expand this idea and lay out my own objections, I would really appreciate your comments. Fire away. :-)