So the topic of your password policy is still weak is nothing new. Just doing a quick search for the phrase “your password policy is stupid” or “your password policy sucks” will result in numerous presentations and articles on the subject.
While each of these articles and presentations have their merits, they all seem to fall short on one very key issue, the ability to enforce a strong password policy.
Specifically there is a serious oversight or weakness, in Microsoft’s Active Directory (AD) service, the most widely used directory service within the industry today. As Active Directory’s current ability to enforce a robust password policy natively is weak at best and seriously lacking in some basic password policy enforcement features. You’d think that after over 12 years of being the number one targeted operating system, that Microsoft would provide you with the ability to enforce a strict password policy with commonly requested features but you would be wrong.
Active Directory’s password enforcement limitations are further compounded or indoctrinated when random compliancy requirements (like PCI) seem to give a passing grade to the default (and highly anemic) “complexity requirements” imposed natively in Active Directory. Yes, there is literally a check box for “certified vendor solutions” – Do you support active directory? Yes, ok you are good to go.
Why do I bring this up?
Well, one of the more common questions and discussions we recently had while presenting our Catch me if you can presentation came from numerous administrators that are struggling to enforce a better password policy than the one that comes with Microsoft’s Active Directory. As most have learned by now, beyond having the ability to enable a few more settings and point to a custom word list, enforcing a strong password policy in Active Directory is not practical with the native features they have today. This has caused many organizations to look elsewhere for expensive third party solutions or moderately supported open source solutions that will allow them to intelligently enforce their password policy requirements.
So what elements should we have for enforcing a strong password policy? Lets start here:
- Minimum password length (set min of 15 char for Domain Admins to thwart Rainbow Table password cracking)* Native to Windows (but not enforceable by user privilege or type)
- Maximum number of characters in each password (useful for mainframe limitations)* Native to Windows
- Maximum password age* Native to Windows
- Reject new passwords that match old passwords by more than X characters* Partially Native to Windows (not very configurable)
- Check to see if the password contains 0,1,2,3, or 4 of the following character types* Native to Windows
- Non-Alphanumeric aka Special Characters
- Minimum / Maximum Numeric Characters in password
- Minimum / Maximum Upper Case Characters in password
- Minimum / Maximum Lower Case Characters in password
- Minimum / Maximum Alpha Characters in password
- Minimum / Maximum Non Alpha Numeric Characters (e.g. !,@,#,$,%,^, etc.) in password
- Minimum / Maximum Space in password (require spaces to encourage use of passphrases)
- Check to see if password contains username
- Check to see if password contains any part of user’s full name
- Check to see if password contains 2 consecutive identical characters
- Disallow passwords that begin or end with a numeric character
- Disallow passwords that begin or end with a special character
- Force the password to contain a numeric character in a specific position
- Force the password to contain a non-alphanumeric character in a specific position
- Check to see if password matches a customizable plain-text dictionary* Native to Windows – but painful to implement and maintain
- Check to see if a password uses a base or root word that is blacklisted via customizable plain-text dictionary (aka no more Password1 or Companyname1 or Company Abbreviation)
Notice all the things not listed as “Native to Windows”? In our experience, those missing features provide you with the ability to enforce a strong policy while also providing real-world enforceable standards.
How do we know?
At DirectDefense, we’ve been doing password analysis for years as part of our penetration tests, as well as offering it as a standalone service to help clients support and measure the effectiveness of their user security awareness training. In our testing methodology we leverage simple dictionaries, a few hybrid tests (aka dictionary + random inserted strings), and in the most recent twist in the past two years (thanks to GPU cracking and oclHashcat), we leverage brute force based on common password patterns.
So lets share some stats:
- Average percentage of cracked passwords based on a common dictionary file (rockyou.txt) –32%
- Average percentage of cracked passwords after 6 hours of testing –87%
- Most common base words –Password, Seasons – (Spring, Summer, Fall, Winter), Windows, Welcome, and Company name or Abbreviation (Xyzcorp1)
- Most common numeric strings –123, 1234, Year (2013, 2012, etc.), 12345, 54321, and zip code of office (31522)
- Most common special character –! , *, and # (almost always used at the end of the password)
- Most common password patterns –?u?l?l?l?l?l?l?d?d (Passwor12), ?u?l?l?l?l?l?d?d (Passwo12), ?u?l?l?l?l?l?l?d (Passwor1), and of course ?u?l?l?l?l?l?l?l?d (Password1)
What is the message you should tell your users? No, dear user, your password is not unique and you are not a snowflake.
So how do you start fixing the problem?
Identify How Bad Your Problem is – We highly recommend you do a password audit for your organization to see how bad of a problem you have. It is rare, but we have seen a few organizations that are doing things well manually and only require a few tweaks to their existing training to start showing very positive results.
Non-Tech Solution – Start updating your user awareness training to give good recommendations and examples of commonly used passwords that should be avoided. Remember, humans learn through repetition, so once or twice a year is not enough. Ideally you are doing something once a quarter until you start seeing a positive change in your culture and password audit results.
Tech Solution – You can try to beat the native solutions into shape if you have a diehard attitude, but honestly we’ve yet to see anyone be successful with it. There are third party solutions out there, but be prepared for some sticker shock as most of these solutions charge by the user account (hint – do a search for “enforce dictionary windows password”).
Test to Measure – Just like in step one, you should establish a process to audit/crack your passwords on a regular basis to see how well your organization is improving over time.
By making these changes to how you handle password policy enforcement, user awareness training, and auditing yourself, you can achieve a more robust security posture at the place where security starts for most organizations … at the login prompt.