This article is aimed at those who build password policies without understanding how they affect security. All resources on the internet that allow you to create a profile and manage some private data require a password to be created due to some requirements. For example, lengths or special characters. And this is OK from the user's perspective. It means that the system really cares about a person’s private data, and a strong password is as harder to be compromised. However, sometimes service vendors apply a common and general approach to accept passwords without understanding how their solutions affect security. And, actually, help «bad people» to compromise passwords accepted by their system.
Let’s take a look at a small example. Assume two different policies based on a password with only two characters. The first policy doesn’t tell us anything. Just a password from two characters. And the second policy tells us next: the password should be based on two characters where one of them should be a special character. Which policy is more assertive?
– Of course, the first one.
If someone decides to guess your password, then the first policy allows your users to set the password using any two characters. Where the second policy is like a guide for hackers, it points out that one of two characters is a special symbol.
We hope that you follow the idea. Let’s check another, more complex example. Assume a policy like this (a real-world example) :
- The minimal length should be 8 symbols
- At least two digits
- At least one capital letter
- At least two special characters
Is this policy strong enough? – Yes, it is, but!
But the human factor. There are so many people who use common passwords for all their profiles, mostly these passwords are absolutely the same, and sometimes they are a little bit modified just to pass the password policy. Also, most people will try to create a password that is at least applicable to all requirements, and that’s all. So, due to this, such password policy mostly, will be treated like this:
- 8 symbols
- 2 digits
- 1 capital letter
- 2 special characters
Due to this, such a cool and robust (on first look) password policy has become a guide for hackers. And this really works.
Having a password like this: 8 random symbols (********) where 2 digits (11******), one capital letter that means a capital character from the alphabet (11A*****), and 2 special characters (11A@@***) – the hacker should just guess 3 (three) characters and the position of other required by default symbols (where possible ranges of these symbols are already known).
So, how to deal with this? There is a way out, and this way is completely around the right policy and correct validation principles. Below are a few recommendations for those who build such policies and algorithms and for users who create passwords and use them to get access to their data.
For engineers: How to build a truly strong policy for your password-accepting algorithms
Just a couple of the recommendations that might improve your password algorithm in many times:
- Do not provide strict requirements, build them in a flexible way
- Build an indicator of password strength based on the password rate instead of applied requirements in the password
You should build an algorithm that accepts any, absolutely any password that passes your minimum quality rank. You can build an algorithm to calculate password strength based on some criteria, for example:
- The existence of a capital letter gives +1 to the rank
- The existence of each two digits gives +1 to the rank
- Every 4 letters give +1 to the rank
- Every two special characters give +1 to the rank
And then define that minimal password strength, for example, should be 5. It means that to reach such a condition and save the password user may type different combinations:
- aaaaaaaaaaaabbbbbbbb (+1 for every four letters)
- Aaaaa12#!ffff (+1 capital, +1 four letters, +1 two digits, + 1 two specials, +1 four letters)
Having such approaches will never help hackers to understand the behavior of your password algorithm and predict common cases. Also, it will provide flexibility to your users to make a password without strict restrictions.
For users: How to generate passwords
- Don’t follow password requirements to pass them most shortly, always do more than it is expected
- Don’t use anything public information about yourself (DoB, First or Last name, any ). Use not logically combined words (like «SkyMonkeyMilk» – easy to remind, but hard to guess) or, in the best way – use password generation tools
- Don’t repeat your passwords, use password management tools to keep them all securely, and then you will need to know only one password – from your password management tool.
Thanks for reading, we wish you to have safe password algorithms and no private data leaks