Skip to content Skip to footer

Oftentimes, we are asked “What is the best password policy?” 

There is no one size fits all policy that works for everyone. Your policy needs to be reasonable and not too overbearing. I have compiled some factors that go into a great password policy and have shared those with you below. 

Password Length

The best thing you can do is increase the length requirement.  Ideally, you would like all users using 15 characters or more because passwords that are 14 characters or less are stored in a weaker hash format that is easily cracked using Rainbow Table password crackers.  That hack requires someone to dump the SAM or grab a password hash and send it offsite. However, with the prevalence of phishing and malware, it can be accomplished via a coordinated attack.  Most of our customers are not comfortable pushing users to a 15 char minimum unless they do a lot of education around passphrases and adopt those companywide.  If you are currently requiring a minimum of 8 characters, try to push that to 10 or 12 characters.

If you are willing to require 15+ characters for all users, you will want to consider passphrases. A passphrase is really just a long password. It is typically thought of as a series of words separated by spaces. The words could be a phrase from a sentence or disparate words such as the “correct horse battery staple” example made famous by the xkcd comic. In the nFront software, you can require a specific number of spaces within the password field. Requiring 2 or 3 spaces will ensure the user is using 3 or 4 separate words. When you are using passphrases, you want to consider skipping the dictionary all together or using a very minimal dictionary. We had one customer who had provided 4 example passphrases to users in the IT communication, and he cleverly used the dictionary to block usage of those example phrases. You could make certain words like the company name or the word “password” completely off limits even if used within a passphrase. Using the dictionary to block common passphrases would also be a great idea. For example, you probably do not want phrases like “mary had a little lamb” or “green eggs and ham” in use on the network. So far, I have not seen those in any hacking dictionaries, but I am sure it is just a matter of time… And when that time comes you do not want to be the easy target.

Password Blacklisting / Dictionary Checking

The 2nd best and arguably the first best policy requirement is to do dictionary checking.  Do not look at the dictionary as a plug and play solution.  You will need to modify it. We provide a 6000 word dictionary.  In my opinion, it is rightsized and has good coverage.  It contains a list of common passwords, days of the week, months, seasons, team names for major sports teams, cities, thousands of common names, and many other terms. It is a plain text file that is quickly and easily customized. It is in a Unicode format, so it supports any printable character in the world.

You always, always, always want to supplement it with additional words like your company name, terms from your industry, local sports teams, local restaurants, etc.  Any “localized” knowledge that you can think of which a user may use to compose a password would be a good idea. We have a tool that can help with this. It can scan your website (even if it has thousands of pages) and build a list of unique words used on your site or blog. The list can be directly added to the dictionary file used by our password filter. Below is a video showing how the web scanning tool can be used to build a custom dictionary.

Since our dictionary does a substring check, you don’t have to worry about variations to the beginning or ending of the words.  Passwords like “Summer123” and “Summer2021” will both get rejected because our dictionary contains the word “summer” and any variation in case (upper, lower, mixed), prefixes, or suffixes will result in rejection. Thus, you get very broad coverage from a single dictionary entry. Our system also supports common substitutions, so it will block passwords like “$ummer123” and “$umm3r123”, etc.

Checking breached passwords – good idea but not foolproof

Some of the more modern compliance recommendations like those from NIST suggest checking passwords against a “corpus of breached passwords” which is a fancy way of saying, “Do not allow passwords that have been compromised.” While this is a good idea, it is not foolproof and should not be your only line of defense. You must keep in mind that many of the internet breaches were from trivial sites with trivial passwords that never would have even met basic Windows complexity. For example, one year the top LinkedIn password was “123456.” Obviously, a person will use a different password and likely a more trivial one on a site like mySpace or Facebook than a password used for banking. In summary, many of the passwords from internet breaches were never smart choices. You can get many lists like rockyou.txt and others across the internet. However, the de factor standard has become the approach of using the HIBP (have I been pwned) list of password hashes. The latest is a 10GB file that expands to 23GB and contains 572 million compromised passwords. The list is in a SHA1 format, so you have no idea of the original word. Therefore, you cannot be sure of exactly what is there unless you use a tool to query for specific passwords. I doubt you will find your company name or “Summer2021” there. I am writing this in December 2020 so next year at this time I would expect to find Summer2021 there since seasonal passwords are such a popular choice.

The nFront software can scan the file of 572 million breached password hashes in less than 100 milliseconds. Our approach has always been to avoid network API calls because the filter runs under the LSA, and network API delays can introduce stability issues. Thus, we do require the file of SHA1 hashes to be local on the machine. Considering we scan the file at the millisecond level, there is no significant performance penalty for turning it on, and I would consider it. Below is a video showing how to add the file of breached passwords and configure nFront to check it.

Password Complexity – Turn It Off (unless you do not have a password filter)

The Windows built-in password policy has a password complexity rule. When turned on, it requires 3 of 4 character sets and no use of the username or part of the user’s full name within the password. If you are not running a password filter, you want to leave it on because it is the best you can do with built in settings. However, it does allow trivial passwords to get through (Summer2020, Password1, Winter123, etc.).

Some customers come to us wanting to require 4 of 4 character types. I suggest against this. Why?  You see how users adapt to Windows password complexity which requires 3 of 4 char types.  Multiple research studies have confirmed that when told to include a number over 90% of people add a “1” to the end.  When told to do all 4 char types, you will end up with passwords like “Password1!”  Studies show over 90% of people will use a “!” character when they must include a special.  Of course, there are other “go to” patterns like tacking on “123” at the end of a 4 digit year (this year, birthday, last 4 of a phone#, etc.).  Hackers love those patterns.  One study showed how you could reduce the time of a brute force attack from billion years to 3 days by making assumptions like: (1) the password will start with an upper case character (2) the password will have a “word” followed by a number (3) and then followed by a special character.  Patterns reduce the possible search space and make the computing time exponentially less.

Requiring 4 of 4 character types is a false sense of security. At first glance, it seems like a prudent security requirement, but after a quick consideration of how users will adapt, you will notice it will not truly improve your password security.

Just Say No to Stanford Password Policy settings

In April 2014, Stanford University introduced the Stanford Password Policy, a length-based password complexity policy. It has different complexity requirements for different length passwords. For example, 8-11 character passwords require all 4 character types, 12-15 require only 3 character types, etc. It is a good idea in theory but again fails when you realize how users will adapt. Ideally, we would love users to embrace the Stanford policy and use 20 character passwords that are all lowercase. However, in reality, the users will simply use passwords like “Password1!” or “February2021” and get right through. You are much better off forcing users into a minimum length that is at least 10 characters or more.

Password Age

The latest NIST guidelines say to pick a strong password and keep it forever. I have not met an admin yet who is comfortable with this. At most, I have seen an admin allow a 365 day password age. I think you want users changing passwords at least once per year.  As you know, users hate changing passwords and especially hate changing passwords more frequently.  Forcing users to change every 90 days results in passwords like “Summer2020”.  Forcing users to change passwords every 30 days results in passwords like “January123” and then “February123” or “MyFavoritePassword1” and a simple increment to “MyFavoritePassword2”.  In other words, the user will simply increment a number with each password change.  Generally speaking, the idea behind changing passwords on a regular basis is to stay one step ahead of a hacker.  If an 8 char password can be brute forced in 50 days, then you want users to change quicker than that.  If you are forcing longer passwords, you should allow people to keep them longer.  If I were requiring 15 char passphrases, I would allow users to keep them for 1 year.  If I were doing a min of 10 char and putting other requirements like a dictionary in place, I would consider pushing the max age from a traditional 90 days to 120 days.  If going to 12 chars or more, I would use 180 days or more.

I know this still does not give you an exact policy, but hopefully, it outlines the factors I would strongly consider.  Here are some examples of what I would consider to be good policies:

Example 1 – A multiple policy scenario with a reasonable policy for end-users and more stringent passphrase policy for Domain Admins.

                Default Password Policy Configuration:

                                Min length: 10 characters

                                Max Age: 120 days

                                Passwords cannot contain the username

                                Passwords cannot contain any part of the user’s full name

                                Passwords cannot end with a number (stops people from just

incrementing a number on the end)

                                Dictionary scan with substitution feature turned on

                                Dictionary file is the 6000 word file with at least 200 other

“localized” words added

                                Exclude: Domain Admins (because you target them in Policy 1)

                Policy 1

                                Min length: 15 characters

                                Max Age: 365 days

                                Minimum required “spaces”: 3

                                Passwords cannot contain the username

                                Passwords cannot contain any part of the user’s full name

**Note Policy 1 does not check the dictionary.  It is designed to force the admin to use a 4 word passphrase (requiring 3 spaces should force 4 separate words). The words could be a phrase or totally different like the “correct horse battery staple” idea from xkcd – https://xkcd.com/936/.  I think that example is too complicated, but the general idea of unrelated words is great.

**Note: If you want to set this to 365 day max and the users to 120 day max, you have to use the nFront Password Expiration service and set the regular Windows password policy to the max age across all policies – in this case 365 days.  The service will run a thread once a day to check the pw age of the different accounts and “short circuit” the timer to force a 120 max age with the regular users.

Example 2 – A multiple policy scenario with a reasonable policy for end-users and more stringent passphrase policy for Domain Admins. This one is slightly more restrictive than example 1 but rewards users with a longer password age.

                Default Password Policy Configuration:

                                Min length: 12 characters

                                Max Age: 180 days

                                Passwords cannot contain the username

                                Passwords cannot contain any part of the user’s full name

                                Passwords cannot end with a number (stops people from just

incrementing a number on the end)

                                Check password against file of breached passwords

                                Dictionary scan with substitution feature turned on

                               Dictionary file is the 6000 word file with at least 500 other

“localized” words added

                                Exclude: Domain Admins (because you target them in Policy 1)

                Policy 1

                                Min length: 20 characters

                                Max Age: 365 days

                                Minimum required “spaces”: 3

                                Passwords cannot contain the username

                                Passwords cannot contain any part of the user’s full name

**Note: Policy 1 does not check the dictionary.  It is designed to force the admin to use a 4 word passphrase (requiring 3 spaces should force 4 separate words). The words could be a phrase or totally different like the “correct horse battery staple” idea from xkcd – https://xkcd.com/936/.  I think that example is too complicated but the general idea of unrelated words is great)

**Note: If you want to set this to 365 day max and the users to 180 day max you have to use the nFront Password Expiration service and set the regular Windows password policy to the max age across all policies – in this case 365 days.  The service will run a thread once a day to check the pw age of the different accounts and “short circuit” the timer to force a 180 max age with the regular users.

Example 3 – A flexible policy that allows you to encourage but not require passphrases. You leverage the length based aging feature within nFront and reward users who create longer passwords with less frequent changes. I like this approach because you can educate users on passphrases and reward their use. For example, if a user opts for a 20+ character passphrase, they can keep their password for 1 year. The dictionary check is skipped in that case but the password is still checked to be sure it is not a password that was breached on the internet. Admins are still required to have passphrases with multiple spaces in their password.

                Default Password Policy Configuration:

                                Min length: 10 characters

                                Passwords cannot contain the username

                                Passwords cannot contain any part of the user’s full name

                                Passwords cannot end with a number (stops people from just

incrementing a number on the end)

                                Check password against file of breached passwords

                                Dictionary scan with substitution feature turned on

                                Dictionary file is the 6000 word file with at least 500 other

“localized” words added

                                Skip dictionary scan if password is longer than 20 characters.

                                Exclude: Domain Admins (because you target them in Policy 1)

                Policy 1

                                Min length: 20 characters

                                Max Age: 365 days

                                Minimum required “spaces”: 3

                                Passwords cannot contain the username

                                Passwords cannot contain any part of the user’s full name

               Length Based Aging settings

                                Passwords 10-14 characters: 120 days

                                Passwords 15-19 characters: 270 days

                                Passwords 20+ characters: 365 days

**Note: Policy 1 does not check the dictionary.  It is designed to force the admin to use a 4 word passphrase (requiring 3 spaces should force 4 separate words). The words could be a phrase or totally different like the “correct horse battery staple” idea from xkcd – https://xkcd.com/936/.  I think that example is too complicated but the general idea of unrelated words is great)

**Note: You must use the nFront Password Expiration service and set the regular Windows password policy to the max age across all policies – in this case 365 days.  The service will run a thread once a day to check the pw age of the different accounts and “short circuit” the timer to force the ages specified by the length based aging rules.

Next Steps – Communicate your policy effectively

Once you have decided on your new policy settings, the next step is to be sure you put the steps in place to communicate the new requirements to your end-users. Within our customer base, we have noticed those who have the smoothest transition are those who have taken time to communicate the settings to the end-users ahead of time.

Stay tuned for an upcoming blog post with tips on end user communication for your new policy requirements.

Leave a comment