|
Password managers, combined with randomly-generated passwords, solve the most serious problems afflicting user-selected passwords. Adding two-factor authentication solves yet more problems. And yet both password managers and 2FA are not widely adopted by users. Where do we go from here? I use a password manager, and the UX of registering to a new website is just awful. On the registration page I need to check what sort of password is being asked for (e.g. 'no longer than 15 characters'), and configure the password generator accordingly. After registration I need to manually convert the password into a login; my password manager can try to do it automatically, but it often fails because it doesn't know how to translate fields from the registration page to the login page. Compare this with what most users do: just enter the same password everywhere. Much less friction. I think we can make using password managers easier than entering the same password everywhere. We can do this by introducing a standard web interface for password managers. This interface will let browsers fill in usernames and passwords on registration and login pages, automatically. It may include password specifications, such as 'password should be between 10-15 characters long'. Here's the use case: imagine the password manager is integrated with the browser (say as an extension). When it detects this interface on a web page, the password manager hides the password field, replacing it with a message like 'secure password is auto-generated'. Similarly, login pages that support the interface will not show a password field at all. From time to time, the user has to enter their single password (to allow the password manager to access its database). In this scenario, the user has to do less work (on average) than when they enter their password manually. When no password manager is installed, the browser simply displays the same old password field. Given a standard interface, implementation is simple: on the server side, it's just a few tags that specify user and password fields on registration and login pages, and what to replace them with when the password manager works. There should probably also be a site identifier to let the password manager know which registration page corresponds to which login page. (Currently password managers rely on URLs to figure this out, and this heuristic sometimes fails.) The whole architecture of storing passwords stays the same. On the client side, password managers already do much of this work anyway, including trying to heuristically figure out which fields correspond to the username and the password. This sort of interface makes things much simpler for them. |
I have yet to find a case where my pwd manager fails to do this (lastpass). I've also never (with the default settings) had a site reject a password generated by it.
> We can do this by introducing a standard web interface for password managers.
I think the web is closer to that than you think (it's fairly easy to figure out the fields in a login/registration/pwd-change form). Mobile apps are a different story, that's where we really need standard system support for delivering credentials.