A Sensible Password Policy

A password should be 24+ characters, require lowercase, uppercase, numbers, special characters, not one of the last 24 passwords, not more than three characters in a row of the same type, and change every 30 days. Uh, NOT! Here’s a more sensible policy.

The policy described in the intro is a real policy in some organizations. But it’s so “secure”, it’s insecure. There’s always a balance between security and usability. Tip the scale too far towards security, and you actually make things far less secure. The reason? Humans. If the burden of following complicated processes or memorizing complex strings becomes too great, the users, especially non-tech users, will circumvent your security. Ex. writing passwords down

Here are some thoughts of a more sensible approach to passwords. For the purpose of this article, “password” means anything a user is excepted to remember and/or use as a form of authentication: passwords, passphrases, computer accounts, WiFi keys, etc.

• Passphrases: It is much easier for a typical user to memorize a long passphrase than a long (essentially) random string. Example: “The1!Smith’s2@Entire3#Retirement4$Savings”
• Length: The single most effective policy for the password itself is minimum password length of 14+ characters (for passwords) and 24+ characters (for passphrases).
• MFA: The single most effective policy for the authentication process is a MFA requirement. Although SMS based MFA is the least secure MFA method, it is still far better than a single factor (i.e. username/password) alone. If that’s all that is available, use it. If a token based option (ex. Google Authenticator) is available, use it and NOT the SMS based option.
• Complexity: Password complexity requirements also help, but should be thoughtfully implemented. A mix of character types from at least three of these categories – lowercase, uppercase, special characters (!, %, &, [, (, @, etc.) and numbers should be encouraged, but maybe not required. Again, we don’t want to get too crazy here or the users will write down their passwords.
• Aging: Password aging should be nearly abandoned altogether. It encourages (almost requires) users to increment passwords (changing a digit within the password). I could MAYBE see an annual requirement, but I am not convinced it helps more than it hurts. Here’s the thing, if there’s evidence of a password compromise, you have seconds/minutes to change your password before it will likely be used by the attacker. Short of that, what’s the point in changing it? Ever? Update: We have written a newer article that helps explain why this is a terrible practice for nearly all scenarios: Forced Password Rotation == Incrementing
• Dictionary: Do not allow simple “dictionary” words, or even two dictionary words together. If it’s a 14 character password, there should be zero dictionary words. If a passphrase, use 5+ words. Password cracking tools, in addition to trying the dictionary words, will mangle the words as well – reverse them, substitute letters for numbers (leet), and pad characters on the front and/or back.
• Audit: Whenever and wherever possible, admins should periodically audit password hashes with a large dictionary. Do so in a safe manner (you, nor anyone else getting exposed to user’s passwords). The only way to confirm an attacker will not be able to easily crack your users passwords is to try to crack them first…and then force a change.
• Users: Never use the same password/passphrase on more than one account/system. Every login must have a different password.

For more information on this topic:

• https://duo.com/blog/nist-update-passphrases-in-complex-passwords-out
• https://www.sans.org/blog/time-for-password-expiration-to-die/

The full NIST write-up (referred to in the above article): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf

Featured image courtesy of maklay62: https://pixabay.com