Making password managers play ball with your login form

Published 13 January 2018 category: code

Secure passwords are long and unique. Therefore, remembering them all is impossible for most human beings. Hence the popularity of password managers. If you’re building a login form, these are some tips to improve the experience for password manager users.

With ‘playing ball’ in this post, I mean that password managers recognise your login form and let you use their features on your fields. Things like password generation, offering to save credentials for a host name and filling in the password for you in a secure way. Ideally, password managers work in both of these cases: on first time visit (when they offer to store credentials) and on recurring visits (when they let you use stored credentials).

1Password suggesting Browserstack credentials to be used for site 1Password recognises it has a pair of credentials for this site

Password managers come with all sorts of heuristics to detect username and password fields. Yet, they sometimes still fail to recognise them. For this reason, Firefox’s password manager complements its heuristics with a recipe system, where users can describe specific instructions for specific hosts. I believe some password managers have hard-coded field recognition for popular websites in order to make them work.

You might think, isn’t recognising my fields the job of a password manager? Isn’t this their problem? I have good news. Mostly, yes. Password managers are built to work with all login forms that follow best practices. Doing nothing special is an option. It will often give you a form that performs well across password managers. But if things don’t play out, this post may contain some pointers to look at.

Password manager popup   add to last pass Last Pass playing ball

Security considerations

Password managers that automatically fill in credentials can be prone to coffeeshop hacker attacks (over HTTP) , as shown by Silver, Jana et al in their paper Password Managers: Attacks and Defenses (pdf). They also provided a number of measures that password managers can take to prevent this, including only allowing filling in passwords after user interaction.

There is also a risk of leaking password information to third party scripts. The article explains actions against this include having the login form on a separate domain, ad blockers, and disabling autofilling altogether (as Safari will do by default). At the same time, more transparency could be provided with browser warnings or permission requests before autofilling.

Use standard HTML form practices

Make sure your form fields are in a <form> element that has an action and a method attribute defined on it.

Another think to look for, is that input elements are associated with a label through their ID (with for) or by being wrapped in one.

Using the right input type can also help: type="text" or type="email" for the username / email address, and type="password" for the password.

The autocomplete attribute

The autocomplete attribute on your username and password inputs can help password managers or browsers figure out what your fields are for. Actual autocompleting, as mentioned above, could be a security risk, if it is done by password managers on page load, rather than after user interaction, or if it happens on pages where protocol or host name are off.

Major browsers ignore autocomplete=”off”, some do this specifically for username and password fields, as they deem it more secure than users using very easy-to-remember passwords.

Google recommend using autocomplete attributes, and their advantages also appear in the spec (yes, there’s a spec!):

The autocomplete attribute offers a declarative mechanism by which websites can work with user agents to improve the latter’s ability to detect and fill sign-in forms by marking specific fields as “username” or “password”, and user agents implement a wide variety of detection heuristics to work with websites which haven’t taken the time to provide this detail in markup.

(Source: Credential Management spec)

For usernames

For the username field, you can add autocomplete="username".

For passwords

For new passwords, for example during account creation or in a password reset process, it’s autocomplete="new-password". For current passwords, for example in a login form, it’s autocomplete="current-password".

No funny stuff

Both 1Password and LastPass have various recommendations related to unexpected behaviour. Well-built login screens:

The message here is: keep it as simple as you can. This helps both users and password managers.

Multi-page login forms

Multi-page login forms can make sense, for example if there are different login options based on the type of user. With this kind of login pages, some password managers, including LastPass, may not play ball. I’ve found that LastPass will not work on first time visits, when your password field is hidden or in a hidden element (more on the hidden attribute). In others, including 1Password and the built-in managers of Chrome and Firefox, this problem does not exist.

In my situation, ‘pages’ were just divs on the same page, with only one of them not hidden. That caused LastPass to not do its first time visits thing. I consider this a bug in LastPass, or overly enthusiastic heuristics at the very least. I found out that if I used something like opacity: 0; it did not fail. This would cause a weird user experience, as opacity only visually hides elements, leaving them available to access by keyboard or Assistive Technologies (AT). Sometimes, and in this case, accessibility is about making something inaccessible to all, at the same time (i.e. when temporary hiding certain screens in a flow).

What I ended up going for is this: I used data-hidden instead of hidden, with CSS that only visually hides. In addition, I added the inert attribute (and its polyfill, as it has no browser support), to make sure the elements are not only invisible, they are also unavailable to use (until they should). Unavailable not only visually, but also for keyboard and AT users. It’s hacky, but it did circumvent LastPass’ bug.


Password managers are essential to secure internet usage, so making our login fields work with them is extremely important. This will mostly happen automatically if you follow best practices. The autocomplete attribute can make it easier for password managers to recognise your fields. Using hidden attributes can make password managers fail altogether. This can be hacked around, but I do not recommend doing so, unless absolutely necessary.

Many thanks Job, Krijn, Mathias and Henrik for suggestions and feedback

Comments & mentions (84)

Joshua Mertens 31 Aug 2018 09:58:00

Your blog is very good. It is helpful for many peoples to make there password strong and not be cracked easily. There are lot of online password generator tools available like [URL removed] which can be used to generate really strong passwords.

Rowdy Rabouw likes this
Saroj zoras likes this
Bram Willemse likes this
Gábor Orosz likes this
John Courtney likes this
Kai Hendry likes this
Philippe Vayssière likes this
Hugo Giraudel likes this
delicado likes this
Scott McKee likes this
Sint Smeding likes this
Natalie Marleny likes this
Dominik Dröscher likes this
Bas Stoker likes this
Paul Grenier ᕕ( ᐛ )ᕗ likes this
Dave Fisher likes this
Dez Iddon likes this
Geoffrey Dhuyvetters likes this
${HARO_ENV} likes this
Syntactic Sugar likes this
Hélio Correia likes this
brandon johnson likes this
Kelvin likes this
Kristof Neirynck likes this
Adrian Thomas likes this
Niall Thompson likes this
Jasper Moelker likes this
Dirk Ginader likes this
dovyden likes this
Herin Hentry likes this
Jeffrey Bennett likes this
Bogdan Soare likes this
Kyon likes this
Zell Liew likes this
Gregory Van Looy likes this
Bram Nijmeijer likes this
Jérôme Smadja likes this
Ihazmrrr likes this
likes this
Hidde Schultze likes this
Brad Frost likes this
Philipp Wartenberg likes this
Paul Grenier likes this
Sohail Sarwar likes this
Nicolas Steenhout likes this
Tori Pugh likes this
Baldur Bjarnason likes this
Kilian Valkhof likes this
Nathaniel Flick/Natanahira likes this
Eric Eggert reposted this
Chris Heilmann reposted this
Marcos Castany reposted this
Marcel Bootsman reposted this
MICHEL! reposted this
m@rco reposted this
Jennifer Sutton reposted this
Dez Iddon reposted this
Pierrick P reposted this
brandon johnson reposted this
ChristophePorteneuve reposted this
Kelvin reposted this
Rik reposted this
Kev reposted this
adrian reposted this
Baldur Bjarnason reposted this
Eric Eggert replied: Super important for people with cognitive disabilities, too! And everyone. Because everyone should use a password manager!
Eric Eggert replied: Super important for people with cognitive disabilities, too! And everyone. Because everyone should use a password manager!
Eric Eggert replied: Super important for people with cognitive disabilities, too! And everyone. Because everyone should use a password manager! replied: “Making password managers play ball with your login form”…
Веб-стандарты replied: Как не мешать менеджерам паролей заполнять формы, Хидде де Врис предлагает несколько советов —…
Stéphanie replied: If you build a site with a login form, please read this :) It's frustrating to have the site in password manager but to need to search for each field because the form was not built properly "Making password managers play ball with your login form"…
Johan Ramon replied: aria-expanded does not require a fallback:…
#accessibility #a11y
Clever Marks replied: Making password managers play ball with your login form… #password #ux #form #login via @nhoizey
Hidde de Vries replied:

The year is about to end, so it is time for another year in review post! I love reading what others write about their years, hopefully mine is interesting to some people.

Like last year, I’ve divided stuff into highlights and things I learned. To be clear, that doesn’t mean I had a year consisting of 100% highlights and learnings, there is also stuff that went wrong, wasn’t amazing or was personal, I just think they’re for elsewhere (in person over drinks).



In 2018, I spent most of my time in Mozilla’s Open Innovation team, working specifically on the IAM project. For those unfamiliar with it, IAM is short for identity and access management, it is about how people proof who they are and get access to stuff with as little friction as possible. It’s been super exciting to build most of the front-end for a project codenamed “DinoPark”.

In the last quarter, I’ve also spent a day a week working at the City of The Hague, specifically helping with improving accessibility and profesionalising front-end development of their digital services. It’s been great to see improvements shipped both in the application’s code as well as the content management system product.

Other short engagements included:

  • teaming up with Jeroen and Peter, I helped NOS, the Dutch broadcaster, with an accessibility audit, user tests with visually impaired users and an in-house presentation on technical accessibility
  • I ran a one day workshop on accessibility guidelines at Zilveren Kruis
  • with Peter, I worked on JavaScript to power a chat-like interface for the Dutch government


I did not do a lot of volunteering this year, but I did translate the Inclusive Design Principles into Dutch and worked on improving MDN documentation on accessibility.

Conferences and events

This year, I attended these events:

I spoke multiple times, too:

I did my CSS Layout workshop three more times (for Fronteers and at Front-end United) and ran a new accessible components workshop (for Frozen Rockets).

Organisers, thanks so much for having me. The first time conference speaking was stressful, time-consuming and very scary, but also satisfying. I got great feedback, both praise and things I can improve on (thanks, you know who you are).

I’d love to speak more in 2019, please do get in touch if you want to have me present at your event or give a workshop.


I published 26 posts on this blog, not including this one. Like I said in last year’s review: I very much recommend writing, it can be helpful in many ways. It is also great to be able to do this on a domain you own, on pages you designed. If anyone needs mentoring around this, get in touch, I would love to help!

Some of the most read posts:


It felt a bit weird to have the Goodreads app keep me in check reading-wise, but it did the job. I managed to read more than the goal I set. Some that readers of this blog might find interesting:

Book covers of brotopia, klont, common sense and killing commendatore
  • Brotopia, about the ‘bros’ that founded some of the biggest Sillicon Valley corporations and the culture they created. I must admit some doubts towards the word ‘bro’ , but wow, the book taught me a lot about how I don’t want to be and where I don’t want to work.
  • Klont – if you read Dutch, get it! This novel brilliantly captures the phenomenon ‘datafication’ and how it endangers some of the basic concepts of free societies, as well as, unrelated, the phenomenon of ‘experts’ traveling the world to give talks
  • Common sense, the Turing test and the quest for real AI – sometimes fairly technical and academic, but I loved the hype-free thinking about artifical intelligence and what to expect from it
  • Killing Commendatore – if you’re into Murakami or want to start reading his work, this is great. It is a lot of pages, in two parts, but worthwile. I read the Dutch translation, it is available in many other languages, too.

For all the ‘big data’ and AI expertise that Amazon, which owns Goodreads, has, the app is still very bad at recommending new books. For me, it doesn’t go beyond what the most generic airport bookshops stock. The real human beings I have befriended there brought much more reading inspiration.

Things I learned

Some random things I learned:

  • I finally got my hands dirty in declarative client-side component frameworks. My framework of choice was Vue.JS. I learned concepts like routers, props down / events up, reactivity and lifecycle hooks, enjoyed working in this paradigm, but even within that, I mostly wrote just JavaScript, good markup and sensible CSS. I have a blog post upcoming on this.
  • I learned in multiple projects this year how hard it can be to explain the concept of focus. It exists as a thing in the browser (the document.activeElement), but also as a thing in people’s thinking, not necessarily the same way. And then I’m not even talking about indicating focus yet. In my talk in Groningen I spent a number of slides trying to get it crystal clear. I like Laura Carvajals “You wouldn’t steal their cursor” and tried a streetlights metaphor (they are not pretty, but if they’re not there, you can’t see where you’re going at night)
  • I worked with WCAG 2.1 in real projects (testing for the newly added success criteria and talking about them in slides)
  • I added CSPs to some sites (see also How I learned to stop worrying and love CSPs)
  • I did more background reading to better understand the world we’re developing front-ends for (super meta), inspired by various colleagues, conference speakers and friends

What I want to get better at next year:

  • writing and presenting
  • I want to try and build something with Rust
  • get more people excited about having a personal website with a blog

With that, I wish all readers a fantastic 2019! If anyone has written year in review posts, I’d love to hear about them in the comments/webmentions, and read what you have done.

Freek Van der Herten 📯 replied:
🔗 Making password managers play ball with your login form… #bestpractices #html
Hidde replied: thanks for sharing!
معاذ replied:
Making password managers play ball with your login form #html…
Jan replied: Making password managers play ball with your login form…
patrick h. lauke #toryScum #clapForFlagWankers replied: don't think so, because that would then be a bug/flaw in that specific password manager (since others work on it), and there are a myriad of other options (even free ones/built-in ones in browsers) available to users
Hidde replied: thanks! so in “a mechanism is available to assist the user in completing the cognitive function test”, that mechanism could be semantic markup that >1 password manager recognises?
Alastair Campbell replied:
The first example in the understanding doc is what you are thinking about:… Your responsibility is the markup, the rest is up to the UA.
Hidde replied: ooh thanks, that was exactly what I was looking for!
Manuel Matuzović replied:
“Making password managers play ball with your login form” by @hdv…
Leave a comment
Posted a response to this?

This website uses Webmentions. You can manually notify me if you have posted a response, by entering the URL below.