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. :-)
I can't find the article but this has been talked about before I think it was Microsoft. There's one major problem with it all the hashes must be unsalted. If someone gains access to the unsalted list they have to crack slightly harder passwords but thousands of times faster. Just look at phpBB's unique MD5s like 97% have been cracked.
ReplyDeleteProbably the best key derivation function is scrypt (assuming it works as advertised). It uses SHA256, so for password hashing you want to ask for no more than 32 bytes of data from scrypt. Using the suggested settings it uses over 16 MiB making it hard for governments to crack. An added bonus is GPUs don't have enough ram to use every core.
So the real question is protect against offline or online attacks.
Also if you're stuck with unsalted hashes (NTLM) there's no reason not to do this. Well besides making it harder for the uses as there is no clear cut answer to will this password work without trying it. I'd expect that password 1 through 20 will fill up.
One thing to consider is requiring unique passwords instead of N. Also if someone tries to use the same password as someone else then require a password change at next log in. Since it's obviously not a good password.
Another problem is the easy common passwords that are disabled might help the attacker understand what the harder passwords are in an offline attack.
Hi Steve/Sc00bz! :-)
ReplyDeleteThank you for your comments!
I had a feeling Microsoft had written something similar earlier... hmm. Gotta look it up.
LM/NTLM are indeed unsalted, so I don't see much of a problem hashing Windows passwords yet another time without salt, but with a better (slower) algorithm, as in my proposal.
My proposal will protect against both offline and especially online attacks; it will lower the number of successful account compromises through a (very) limited wordlist in combination with an account lockout policy through an online attack.
For offline attacks it will increase the time needed to recover "all" passwords, as there will be more unique passwords to crack.
As for requiring all unique passwords, I think that would kill off any and all remaining usability for most users of the system. :-)
Hey Per, sorry for falling off the face of the planet for the last couple of months, but this is certainly a post I can't stay away from ;)
ReplyDeleteThe Microsoft paper that Steve/Sc00bz mentions is "Popularity IS everything" which is available at:
http://research.microsoft.com/pubs/132859/popularityISeverything.pdf
The biggest difference between their approach and your's Per is that they use a Bloom filter to store the password results, (instead of keeping the hashes). From a security, (vs usability), standpoint the large number of false positives generated by this is a big advantage if/when an attacker ever gains access to the back-end oracle. It reminds me of the truncated MD5 hashes in the rootkit.com dump. Sure a dedicated attacker can still target individual users, but the high number of false positives makes widespread cracking of the truncated MD5 hashes worthless for analysis, and cost prohibitive for an actual attacker.
Unfortunately there are the usability issues with a bloom filter. Because of the false positives, someone with a very strong unique password might have it rejected because it collides with 'password123'. Since you're talking about implementing this on DCs which already have all of the password hashes, your approach of using the actual hashes would be more appropriate ;)
(more in my next post)
I'd also like to second another point that Steve made. When talking about password policies, it's important to determine if you are protecting against online or offline attacks. When dealing with online attacks, I will strongly argue with you that blacklists are very effective, and I can point to Twitter's experiences with them as a real life use-case to help prove my point. Or I can put it another way. When following your proposed solution, are you comfortable letting one or two people in your organization pick 'Password123' as their password before the number of collisions become high enough to ban that password?
ReplyDeleteThat actually brings up another point that was made in the Microsoft paper. A popularity oracle really is only effective as a stand alone security technique when a large number of users are involved. That way, even if an attacker knows that two or three people picked 'Password123', the number of users they would have to guess against during an online attack would make the attack too costly. When talking about services like Hotmail, this assumption holds true, but if we're talking about a mid-sized organization of a couple thousand people, it might be worth the attackers time to try a couple of common passwords against all of the accounts.
This doesn't mean that I'm not a fan of popularity oracles. I think they can be a very important part of a larger password creation policy strategy to deal with issues that you mention like with Helpdesk password resets. But I also think that it needs to be combined with other security mechanisms like strong hashing algorithms, blacklists, user education, and dare I say it ... corporate approved password vault programs.
So I guess what I'm saying is I really enjoyed your post, and I think you bring up a really good point that one good defensive technique is to limit a password's popularity.