Is it really a good idea to impose the use of special characters when creating passwords?

At first glance, your reaction to this question may perhaps be similar to mine:
“Yes of course, it’s a good idea, most sites even tell us that our passwords are more secure if we use upper case + numbers + special characters. We hear this all the time so it must be true, right?”

But the doubts probably began to set in when you read the title of this article. This feeling intensified as you clicked to get here, and then perhaps you thought to yourself “admittedly it’s less practical to remember”… and that’s a good thing, because that’s when you start to take a step back, to question this model and form your own opinion…

Reassuring preconceptions

So why do we start with this preconception? Why do we naturally think that a password that is difficult to remember, or at least one which contains special characters, is more secure?

First of all logic tells us, quite rightly, that there is simply a greater chance of guessing a character if it is restricted to the letters of the alphabet, rather than including the alphabet of several different languages, punctuation, numbers, case differences (lower/upper case), etc.

For example: for a single character, there are 26 possibilities for the French lower case alphabet, compared with 62 possibilities (26+26+10) for a single character if we can use a number or a lower or upper case letter of the French alphabet.

On the face of it, increasing the possibilities for a single character therefore appears to be a very good idea, and that is indeed the case. However, it’s far from being the most effective option, and it can sometimes be counter-productive. We’ll come back to this.

Where the doubts arise

Let’s get back to the subject in hand. Here is a typical situation I could experience, and one which will surely sound familiar to you.

I need a new password, so I enter “password1234”. But then I think to myself that it’s time I followed the recommendations to the letter, to make my password “secure”. I therefore delete the last character to add a special character to a password, which is just as easy to remember. The result: “password123!“.

Here, and this has no doubt already happened to you, my password is rejected: Error, “Your password must contain at least one upper case letter, one number and one special character”. So, I roll my sleeves up, wonder in passing why they waited for me to think up a password and enter it before telling me the specific rules that apply to this site, and then replace it with “Password123!”.

Red alert once more, this time I’m told that “!” is not an accepted character … I let out a big sigh, roll my sleeves up further still, and replace “!” with “?”, wondering whether this time everything will be OK. Bingo, it works! “Password123?” meets all the criteria!

But a few minutes pass, and then a question comes to mind: Is “Password123?” really more secure than “password1234”?

Let’s look at this question in a little more detail, taking an arbitrary value of 10 possible special characters in order to simplify the calculations and reduce the order of magnitude somewhat. That therefore gives us:
10 special characters + 26 lower case letters + 26 upper case letters + 10 numbers = 72 possibilities for a free choice of character. In both cases, my password is 12 characters long.

Let’s start with “password1234”:
72^12 = 19,408,409,961,765,342,806,016 possibilities

Now let’s compare that with the password that complies with the site rules, “Password123?”, and for which we need at least one number (10 possibilities), one upper case letter (26 possibilities), one special character (10 possibilities) and the rest of which can be chosen freely:
10+26+10+72^(12-3) = 51,998,697,814,229,038 possibilities, with 12-3 since of the 12 characters, 3 have rules imposed.

At this point, I begin to ask serious questions, as by imposing these rules upon me to strengthen my password, they’ve removed 19,408,409,961,765,342,806,016 – 51,998,697,814,229,038 = 19,408,357,963,067,528,576,978 possible passwords! Wasn’t the idea to make it more secure?

A “brute force” attack, in other words one that simply tests all the possibilities one by one, will take much less time to find my password than if I had chosen it myself, without all of these constraints! Logic, quite rightly once more, tells me this time that the more entry rules are imposed upon me, the more my entry options are “filtered”. In other words, my password is forced upon me slightly more by restricting my choices.

This is a real cause for concern

Let’s take things a little further. To do this, this time I have opted for an even more revealing order of magnitude, with passwords containing just one or two characters, still with 10 permitted special characters.

As a reminder, based on our criteria, the number of possibilities for a single character is: 26 lower case letters + 26 upper case letters + 10 numbers + 10 special characters = 72 possibilities.

Now let’s look at the number of possibilities using only the 26 lower case letters of our alphabet.
For a single character, 26 possibilities is weaker than if we use special characters.
If we increase it to 2 characters: 26^2 = 676 possibilities!

For 2 characters, if the use of at least one special character is imposed (10 possibilities based on our criteria), we have 2*(72*10) = 1440 possibilities, so the same order of magnitude as previously, and 72^2 = 5184 possibilities if I can freely choose the characters.

In summary:

As we can see above, 2 elements significantly change the order of magnitude of the number of possibilities required to guess a password: its length and the possibility to freely choose the password. The order of magnitude is even multiplied when both are encouraged simultaneously. Despite our initial preconception, imposing the need for a special character seems to have very little effect.

My password will certainly be much more difficult to guess if I am free to choose its length and the special characters it contains, rather than being required to use special characters!

The source of the problem

As you will have understood, the problem comes above all from the fact that a password entry rule is imposed, such as for example imposing a maximum length, or the entry of special characters. Initially imposed in order to help the user to think of a strong password, this model quickly shows its limitations. The more restrictive the rules, the lower the number of attempts necessary to guess it, whether through a brute force attack, a dictionary attack, or a simple process of deduction.

Consider in particular certain sites which require numerical passwords, with 6 or 8 characters… There is a very high chance that the password will correspond to an important date for the user. Given that the final characters generally correspond to a year, an attacker knowing the target population of the site being attacked in this way just needs to test all the dates.

With a little imagination and a bit of research on the Internet or on social networks, you can even easily find all the important dates for a given person (their date of birth or that of their loved ones, the date they got married, adopted pets, etc.).

This type of attack requires no technical skill and can also pay off even if our data is not directly exposed on the net. Through social engineering, in other words a simple psychological influence or even being manipulated, we could even give away this precious information ourselves.

What we must remember is that even including numbers, different cases (lower/upper case) and special characters, the main thing that weakens our passwords is above all when they are too short. With the possibilities available these days in terms of computing power, we can even, for a few euros, test millions of possible passwords in less than a day (see source). I’ll leave you to imagine how little “security” your 6- or 8-character passwords offer, even including at least one special character, one number and one upper case letter, and above all how long they would be able to withstand such a powerful brute force attack!

So what can be done about these blasted passwords?

As we have seen, having a wider range of characters is an advantage, but not as much as the number of characters used. Here then is my advice.

For users:

• Prioritise pass phrases wherever possible, which are longer than passwords, and naturally include special characters, while remaining easy to remember.
• If there is a limit to the number of characters, prioritise the use of complex passwords, in other words passwords which have little chance of appearing in a dictionary, which are not easy to deduce from your profile, and which may indeed potentially include special characters. Avoid replacing certain letters with numbers that look similar, such as for example putting a 5 instead of an S. This technique, known as Leet Speak, has long been so well known that it is no longer sufficiently complex, and does not therefore make it much more difficult to access your passwords.
  Potentially prioritise use of a password manager (such as Keepass, a free and Open Source tool) or a pass phrase approach, but taking only the 1st letter of each word, phonetically or a mix of the two, taking into account the constraints imposed on the password length: for example, “I love pizza” could become “ILuvπza!”. Some recommendations (in French) from the ANSSI site, the gouv.fr site, and a generator on the CNIL site.

For developers:

• Why impose a maximum of 6, 8 or 12 characters when storage in the base is generally on 255 characters by default? In fact, why not go beyond 255 characters?
• On a technical level, at what point and how do you manage password encryption?
• Allow passwords or pass phrases to be entered in any language (using permissive encoding) in order to encourage the natural use of special characters (accents, apostrophes, punctuation, different alphabets, etc.). Be careful however not to neglect database injection attacks.
• Limit the number of attempts in a given period, in order to artificially slow down brute force or dictionary attacks.
• Notify users by any means when there are a number of unsuccessful attempts on their account, in order to warn them of a suspicious action and allow them to take the necessary measures (deletion of their payment data, etc.).
• Consider alternative or additional input means (e.g.: dual authentication, biometric identification, input by means other than keyboards, etc.), alternative means of saving passwords (e.g.: trusted third parties) or even, why not, “passwordless” solutions?

Conclusion

As far as I’m concerned, a “good” password should definitely be both difficult to guess (whether by deduction, brute force, dictionary attack, etc.) and also extremely easy to remember. Preference should therefore be given to a pass phrase (or a long password) rather than insisting on a password containing special characters. Ideally the 2 should be combined, without this condition being imposed.

And what do you think? Does the unloved password still have much to offer in the face of new, increasing requirements in terms of security, performance and user experience? Many solutions are being designed, for example with adaptive or self-managed identification via blockchain and biometry, to allow increasingly reliable authentication across all of our services.