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.
> 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.
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.
> 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.
A few minutes ago I registered to T-mobile, and 1Password thought that my username was something like mytmobile.aspx. I also find that 1Password has a very hard time with banking sites. There is at least one bank where it simply fails to login. YMMV of course.
Going beyond these anecdotes, even if these heuristics almost always work, I believe that having heuristics involved at all is preventing mainstream adoption. I think that if the password management interface is standardized and heuristic-free, then we will see password management support in the mainstream browsers. I am imagining a future where the auto-generated passwords work transparently so that users don't even know about them. I think this cannot happen without browser support.
> Mobile apps are a different story, that's where we really need standard system support for delivering credentials.
I agree that password management on mobile is a greater pain point, and (as mentioned elsewhere in this thread) the additional problem there is with entering the master password.
I use KeepassX on laptops and it's great, but the password manager use-case really falls apart on phones / tablets.
It is slow and awkward to enter a strong master password on a typical mobile device keyboard, having to shift to numeric and symbolic layouts every few characters. So slow in fact that sometimes I forgo logging-in to a service and wait until I'm back at a laptop.
I don't know what the solution is but that's one of the hurdles to wider adoption. Users just want their passwords to be available. Perhaps biometrics is part of the answer.
On the subject of length, why does seemingly every website enforce a maximum length? I tend to memorize entire sentences with punctuation and capitalization to use as passwords and it's effectively impossible for me to do this when everyone caps password length.
It kind of implies to me that whoever is storing the password has done something incredibly stupid.
Memorizing sentences means that I can just use a copy of The Bones or some other pocket reference as my password manager.
YES. Plus, this kind of integration would make it trivial to change a password, so that could literally be a one-click process in the case of a leak.
And as you say, password managers already have a fallback for sites that don't support the interface, so there would be backward compatibility as it gets adopted. (And likely it will take a long time before businesses like my bank, which requires a password of exactly 6 alphanumeric-only characters, catch on...)
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.