(Originally published by @fluffy_bs)
I recently had this conversation with a client following a pen test:
Client: “What is our biggest security hole?”
Me: “Your password policy is incredibly weak. We were able to brute-force passwords such as Winter14, Password1, and Company1.
Client: “We just had a meeting where we reiterated our security policy. I told everyone not to use weak passwords like that.”
When users are given the chance to make choices that might compromise security, they’ll usually make the wrong decision. We all realize the old “eight character minimum with complexity” password recommendation just isn’t secure any more and allows for the passwords listed above. So what’s the solution? In a perfect setting, increasing password length and complexity requirements helps out quite a bit. But it doesn’t get to the root of the problem: users creating the weakest possible passwords, which are still susceptible to brute-forcing, guessing, and trivial off-line cracking. (e.g.: “November2014!” or “Password1!”) Also, organizations often have legacy systems which don’t support passwords greater than eight characters, or can’t support special characters, etc., so increased complexity/length may not be possible.
Password audits are also frequently recommended. But that’s the wrong mentality; password audits are reactionary, need to be performed regularly, and don’t target the root of the problem. A better solution is to take the power away from users and force strong passwords to begin with. That’s where Active Directory password filters come in. I recently reviewed a few password filter solutions; in this blog post we’ll take a quick look at Password Policy from SpecOps Software.
Installation was relatively easy, even for someone not intimately familiar with Active Directory and GPOs – I had the software up and running on a Windows 2008 machine in about 30 minutes. Some features of SpecOps Password Policy:
- Dictionary-based password blacklisting
- Passphrase support
- Multiple policies per domain (including < Win2008 DCs)
- Regex support
- Fine-tuning of length/complexity/content requirements
You begin defining the password policy by selecting the filter to work off of rules, passphrases, or both. To avoid conflicting rules and policies stepping on each other, the SpecOps password rules must be at least as strong as those in the default domain policy. This includes the rules as well as the passphrase policy sections. When combining the rules and passphrase options, the rule is simple: if the password is shorter than the minimum length set in the passphrase options, the standard length and complexity rules apply – if not, the passphrase requirements kick in.
The general settings page, as seen below, can be as simple or as granular as you will need, including settings for incremental passwords, minimum number of modified characters between password changes, and an optional setting for a custom explanation message sent to the client on the user’s machine.
The Password Rules settings are the meat of the policy. Settings for minimum/maximum password length and required character groups (upper, lower, digits, and special) are pretty standard fare. Some of the more interesting options are: checking for partial or full usernames in passwords, disallowing consecutive characters, dictionary and reverse dictionary blacklisting, and even regular expressions! As always, when dealing with regular expressions, make sure you know what you’re doing. But this sort of granularity is great for situations where a legacy system may only allow a certain length range and a limited set of special characters.
One of the best features inherent to any decent password filter solution is the inclusion of a dictionary-based checker. The dictionaries can be as simple or as sadistic as you want, which can sometimes pose a problem. The dictionary checker flags if ANY part of the password is in the dictionary. For example, if you have a dictionary that includes the word “hack”, a password of “PD8s!pH#01BQ*V&hack” will fail the check – not a great outcome considering the relative strength of that password. That’s where passphrase allowances come into play; turning on passphrases will override the standard rules when the password is greater than or equal to the specified number of characters. As long as the passphrase length and complexity requirements are set to the same level (or higher) as the default domain policy, everything goes smoothly. As a result, setting the passphrase minimum to 16 characters would allow the above “PD8s!pH#01BQ*V&hack” to pass the checker as a valid password, effectively bypassing the dictionary check.
Instead of telling users to create secure passwords, force them to, by using password filtering software. SpecOps has created a pretty powerful, yet easy to use, password filtering solution.
