Developers: common misconceptions about login forms

Require the use of special characters, limit the length of passwords, force passwords to be changed regularly...

In recent years, we have witnessed a global awareness of the major role of password protection in corporate IT security. This is evidenced by the 50% increase in the use of password managers observed by the LINC (CNIL Digital Innovation Laboratory) and Médiamétrie between 2018 and 2019 (1). While competent authorities such as ANSSI provide good advice and practical guides to help professionals adopt the right reflexes, some obstacles persist. This is for example the case of these four constraints which are still frequently found in password forms... and which do not help to engage employees in more secure practices.

1- Impose a maximum number of characters

Even today, many password forms limit entry to a certain number of characters, sometimes only 8 or 12 characters! This restriction perhaps comes from a desire to avoid denial of service attacks (2) by sending content of several megabits or even gigabits. It perhaps also stems from the idea that the user will not be able to remember the password if it is too long.

The problem is that this constraint prevents users from choosing truly strong, long and randomly generated passwords. So this practice is a major barrier to the adoption of password vaults and therefore produces the opposite of the desired effect on user security!

To address both issues (avoid denial of service attacks and enable the use of password vaults), set the maximum length of a password field to 500 characters. This is more than sufficient in both cases.

2- Require at least 8 characters, a lowercase letter, an uppercase letter, a number, a special character

Well known gauges such as “Please enter at least 8 characters, a lowercase letter, an uppercase letter, a number and a special character” are common in password forms. The principle is well-founded since in fact, the more different characters the password contains, the more complex it will be for a hacker to decipher.

The problem is that this doesn’t have a big effect on password security in real-life because users will use obvious substitution mechanisms that will barely slow down hackers. For example ’i’ will become ’1’, ’a’ will become ’@’ and ’s’ will become ’$’.

As we explain in our article “What is a strong password?“, the strength of a password depends primarily on its length.

Our advice is therefore to impose a password length of at least 12 characters (or even 14) and to display to the user an evaluation of the strength of their password using libraries like zxcvbn. Also impose the use of all types of characters since users are used to it and it doesn’t hurt.

3- Require regular renewal of your employees’ passwords

Renewing passwords is a divisive topic. Some prefer to impose regular password changes, based on the principle that in the event of a data leak, renewing the password will cause the hacker to lose access via the old password that has become obsolete.

This rule is, in our opinion, of little relevance, because

In the event of a data leak, changing your password several weeks or months later will probably already be far too late.
Over-demanding users by requiring them to change their passwords too often risks discouraging them or creating behaviors in them that won’t stop any hacker, such as adding a date or number at the end of the existing password for example…
Not to mention that requiring frequent password renewal often results in wasted time in terms of managing forgotten passwords for IT managers...
Furthermore, if the site has detected the data leak, it will be able to notify its users who will then have to effectively change their password immediately (not several weeks later). But if the data leak has not been detected, then as long as the flaw is not corrected, the hacker will be able to repeat his attack and access the changed password. In short, in reality, this rule probably has a limited effect in terms of security.

Forcing your employees to use a password vault, on the other hand, will have a much more positive effect on security. Indeed, the user will be able to define a random password which prevents the hacker from extracting the password from its hashed version (unless the site being hacked stores the password in clear text, but there, it’s not your users’ fault, it’s yours).

The other benefit of a password vault is to allow the user to never reuse their professional passwords in their personal life. This practice therefore leads to a fairly high risk that the user ends up entering their password on a very poorly secured site and that the hacker manages to reuse this password to attack the business.

Requiring your employees to change their passwords regularly, yes, but start by imposing the use of a password vault!

4- Try to prevent robots from filling out your form

Some sites attempt to prevent bots from filling out password forms for one or more of the following reasons:

Avoid automatic scripted attacks
Force the user to enter their password so they don’t forget it

Some sites also prevent copying and pasting a value into new password forms to minimize the chance that perhaps the user entered their first password incorrectly and then gets stuck.

All these reasons are bad reasons because

scripted attacks can be blocked at the server level, quite simply by a timeout after more than 3 failed attempts for the same user
if the user forgets their password or enters it incorrectly, except in specific cases, you must offer them a forgotten password system

But what’s most annoying is that these anti-bot mechanisms prevent password vaults from working properly when autofilling forms, which is extremely frustrating for users. By using these methods, you are making it even more difficult to adopt password vaults and you contribute to make the web less secure.

Our recommendation is therefore on the contrary to let legitimate robots do their work andadopt the following good practices:

do not prohibit copying and pasting into a password field
do not refuse javascript events emitted by robots (ie do not refuse events with the “trusted“ attribute set to false)

systematically use the standard “type” and “autocomplete” semantic attributes on input fields

<input type="text" autocomplete="username"/>

<input type="password" autocomplete="current-password"/>

<input type="password" autocomplete="new-password"/>

move anti-bot mechanisms to the server side

Conclusion

To summarize, password forms that are too restrictive or constraining are a barrier to the use of password vaults which are nevertheless essential to sustainably support users towards best practices in terms of password security. The better the password vault can accomplish its missions (automatic filling, generation of strong passwords, etc.), the more password security will be ensured and the more users will bet satisfied to take part, without constraints or considerable efforts. Word to the wise!