Coming up with a valid password policy is a nightmare. Too many variables need to be considered, and when you throw end-users into the mix, things can go south very quickly. However, building a secure password policy doesn’t need to be an ordeal. It all comes down to knowing your end-users, and anticipating what they will let you get away with. To help you bridge that gap, we’ve created a list of ‘Best Practices’ to keep in mind when building your password policy. Stick to these principals, and watch how quickly this nightmare ends!
Password Policy Best Practices
1. Minimum Length
Let’s start with one of the more popular options to consider when building your Password Policy: Length. Password length is key if you want to enforce strong passwords in any environment. It has been proven time and again that length is the most important factor when determining password strength. The recent rise in the use of passphrases is indicative of just how this particular Best Practice is.
To keep things both simple and effective, limit the minimum length for your passwords to somewhere around 10-12 characters. By starting with a significant length, you are able to lightly nudge your users in the right direction. Going one step further and requiring phrases is a good way to train users on establishing long but easy to remember passwords. To give an example, you might set a minimum password length of 20 characters and give users the following sample password: I do not like green eggs and ham! That example contains 33 characters if you count spaces, and 26 even if you don’t. Additionally, that particular pass phrase very easy to remember, but not that easy to guess!
2. Minimum/ Maximum Password Age
Let’s face it: people are predictable. When faced with an obstacle, we will always try to find the simplest way to get around it. This determination is the foundation for doing away with regular password changes. As recommended by the National Institute of Standards and Technology (NIST), periodic password change requirements should be removed from ‘Best Practices’ due to the ill effect such requirements have on end-user behavior.
When confronted with rapid password change requirements, end-users tend to lapse into formulaic approaches that ultimately weakening their digital identity security. The most common example is the use of a new password with a few numbers tacked on to the end. This is a quick and easy workaround the end-users are only too happy to employ. If an attacker has compromised an old password, the first thing to check is if the new password matches any common additions such as special characters or number sequences.
Minimum age is still viable, however, as it requires end-users to wait a certain amount of time before changing/resetting the password again. This prevents users from blowing out password history by simply resetting the password 20-30 times in quick succession.
3. Password History
Speaking of Password History, this is another password policy best practice to consider for improving security in your environment. A solid Password History policy prevents users from decreasing authentication security by reusing old passwords once they have been changed. Additionally, combining password history with additional best practices – such as minimum age – further reduces the risk of account compromise.
Password History is a simple practice in terms of functionality. This particular password policy best practice encompasses a list of remembered passwords that users cannot reuse. On the end-user side of things, password history helps users ensure unique passwords without accidentally reusing weak, potentially compromised passwords after a reset. From a security perspective, this best practice reduces the risk of compromised passwords being utilized long after the fact.
The precise number of passwords to remember is going to vary from one environment to another. However, a high number is a safe bet. Typically, we see administrators setting Password History into the 20s now, which is not really as high as it sounds. When combined with the fact that password expiration is not happening as regularly, users should only be changing the password when it has been forgotten. In that scenario, a password that was forgotten could easily have been compromised. If that is the case, the old password should not be allowed back into the mix.
4. Flexible but Required Complexity Options
Password Complexity options are the source of ire for both end-users and administrators alike. Of course, it doesn’t help that complexity options are never entirely clear, and the debate on their necessity has been around for a long, long time. We even touched on the topic earlier this year in another blog on How to Strengthen Password Policies. Yet, here we are again: discussing how complexity options are a best practice for improving your password policy. Simply put: complexity works.
The kicker here, though, is that complexity only works when it is implemented well. Users are easy to frustrate and hard to control. Password complexity requirements are most often the straw that breaks this particular camel’s back. It doesn’t have to be that way, though. Length over complexity is a logical starting point because of the simplicity, but it is not the only option.
Flexibility is the key point to consider when implementing password complexity options for your password policy. Users are more likely to fall in line when they can choose which rules to follow and which ones to ignore. Active Directory itself has been implementing flexibility for years now – because it works. By requiring users to adhere to 3 out of 4 complexity requirements, you provide just enough freedom to prevent rebellion. Even if you bump that down to 2 out of 4 options – password security will only increase. If password complexity requirements are implemented alongside passphrases as well – end-users might not even know that the requirement exists: they will meet it automatically.
Build a Better Password Policy for Your End-Users
At the end of the day, your end-users are the key determining factor. Best practices are only ever meant as a guideline, not as a group of rules set in stone. Your environment is going to vary wildly from the next. Knowing what your end-users want is going to help you finalize the password policy as needed. Striking the balance between security and usability is not always easy, but it doesn’t have to be all that difficult either.
Just keep the above guidelines in mind when building your Password Policy, and your end-users will be setting and utilizing strong passwords before they even know what hit them.