Consulting Journal: Techniques - Enabling password managers

Techniques: Enabling password managers

by David Blakey

I think that you should encourage visitors to your website to use password managers, because those visitors want to use them.

[Monday 31 August 2020]

When someone visits your website, I believe that you should make their experience as good as it can be. Given that many visitors will use password managers, such as LastPass, you should facilitate their use.

I am not saying that I think that using LastPass is a good idea. I am not advocating that, as a consultant, you should recommend its use to your clients. I am saying that, if you require users to log in on your own website, you should enable them to do that using methods that they prefer to use.

If your website provides free content, such as articles and downloads, then consider helping password managers to automatically complete your login form.

Remember also that some of your visitors may not be as able as others to enter their username and password, and that they may rely more on tools such as password managers.

What users expect

Someone using a password manager will expect that, each session with their browser, they will log in to their password manager once and then be automatically logged in to your website when they visit your log-on page.

Their second-best preference will be that their password manager completes their username and password on your log-in form, so that they only have to click your Log in button.

What users may get

A user with their password manager open may arrive at a log-in page that is unfriendly to password managers and then find that

They have to click on the username or password field to invoke their password manager
They have to select the website from a list in a window that their password manager opens, so that the fields on your form can be filled
They have to click the Log in button on your page.

If you're not a fan of password managers, you may think that these actions are not onerous. And, indeed, they are not. But they are not what your visitor is expecting to have to do.

Checking your form

If you are not a web developer, you can check your form against the criteria that I have listed below by clicking the View source link that you can probably see if you right-click anywhere in your log-in form. If you are a web developer, I have provided examples for each line of your form.

Form

The log-in form will be bounded by a <form> element to start it and a </form> element to close it.

The form must have a method and it must be post. This tells the browser to submit the field name and values as a form, rather than as a text string attached to the URL.

The form should also have an action attribute and it should point to the login page. Even though you can leave this out if the page is the current page, I recommend including something like action="login.asp".

The <form> element should contain autocomplete="on" This invites autocompletion of all fields within the form. Generally, password managers will ignore the setting of autocomplete, but it is good practice to include it.

Input for username

The <input> element for the username should have name="username" and id="username" attributes. Names close to username will also work.

The type="text" must be used. Even if you use numeric IDs instead of an actual username, the type should be text.

Input for password

The <input> element for the password should have name="password" and id="password".

The type="password" must be used.

Input for button

The best method is to use an <input> element with type="submit".

For web developers

Loading

Load the form with the page, instead of having it loaded by an event.

Similarly avoid handling events within the form. You can, and, in my opinion, should, use a pattern attribute within the username and password fields, to avoid malicious code injection.

Form element

<form name="loginform" id="loginform" action="login.asp" method="post" autocomplete="on">

Web developers should note that the autocomplete attribute should be in the <form> element and not in the <input> elements below it.

Also, other formats of autocomplete should be avoided. Some of these were not implemented in all browsers, and some have been deprecated in future browser developments. Do not code

<input type="text" name="username" id="username" autocomplete="username">
<input type="password" name="password" id="password" autocomplete="current-password">

Input for username

<input type="text" name="username" id="username" pattern="[\w\d\s'\-&]+" autofocus>

Use a <label> element to either refer to the input element or to include it.

<label for="username">User name</label><input type="text" name="username" id="username" pattern="[\w\d\s'\-&]+" autofocus>

Input for password

<label for="password">Password</label><input type="password" name="password" id="password" pattern="[^\s'=\u0022]+">

Input for button

<input type="submit" value="Log in">

[ List articles on Techniques ] [ View printable version ]