How to eliminate passwords? It can't be done
Do you follow best practices for passwords on all your accounts? If you say yes, you're either lying, mistaken or using a password manager. It's impossible for human beings to follow best practices. Some of the key practices for passwords are:
- They should be long (maybe 10 characters or more)
- They should be complex, i.e. no dictionary words, even embedded, and a mixture of letters, numerals and, if allowed, punctuation
- Do not reuse one password for a different site
- Change passwords periodically
There, I'm sure I've missed some, but that's hard enough. Here are five long, complex passwords. Could you remember them? 4gaETMUpqO74 R4665qAtWnYN 3gMZq99YYOck CeRvsII90CZ7 DIQj5gGpx25r
I use a password manager, which I used to generate the list above. Nobody can remember even a few of those passwords, so password managers hide them from the user. But they're still there. They can still be breached and abused at the service end, although not reusing passwords will limit the scope of the damage. Furthermore, password managers are a hack. They scrape web pages and attempt to stuff usernames and passwords in the appropriate fields. It doesn't always work and workarounds are clumsy.
How could we actually eliminate passwords? IAM (Identity and Access Management) products, also known as Enterprise Single Sign-On, do the same thing in a different context. Once you authenticate yourself to the IAM, it will authenticate you to services, both in and out of the enterprise, with which a trust relationship has been established. These relationships are usually defined using XML-based standards SAML (Security Assertion Markup Language) and WS-Federation. In SAML, the parties are the Identity Provider and the Service Provider. For instance, your enterprise IAM (the Identity Provider) could use SAML to authenticate you to Google Apps or Office 365 (the Service Providers).
Tech Pro Research
But SAML and WS-Federation are not practical options for unmanaged end user systems. The closest we have are third-party authentication from big-name companies like Facebook, Google, Microsoft, Twitter and LinkedIn. These authentication systems are generally based on a protocol called OAuth. For example, a job recruiting site might allow you to authenticate with LinkedIn and, as an added benefit, retrieve your job history and other profile information from your LinkedIn account.
OAuth in these cases is just a delegation protocol: it conveys authorization decisions by a service provider using web APIs. OAuth itself is not an authentication protocol. In the example above, LinkedIn is doing the authentication, using OAuth to allow the user to interact from a different site. If the distinction is confusing to you, you're not alone. A lot about OAuth is confusing and it's easy to implement badly and insecure implementations are not uncommon.
Another problem with OAuth is that it can be confusing to end users. Much like those permissions lists on Android, OAuth presents lists of what the site you're using will have access to from the authenticator, such as to be able to post on your Facebook wall. I know I think long and hard when I'm presented with one of these. OAuth UIs are also natural targets for phishing for your credentials for the authenticator; is that really Google asking for your credentials?
But even if there were no problems with OAuth, it's not a complete solution. Most sites don't want to delegate that trust to a third party, and lots of them won't trust some of the authenticators (e.g. Microsoft, Google) in particular.
Finally, there are biometrics. In theory, you should be able to use your fingerprint or face or iris or something else like that to log in to third parties, and some of this has become realistic with Apple's Touch ID and Windows Hello, but there are a lot of different potential biometrics and they're available on different platforms and it will be a very long time before a user could use biometrics to the exclusion of passwords.
Personally, I don't see a practical solution. A real solution would have to be easy to use (as enterprise IAM generally is) and secure. OAuth fails in some degree in both respects. If an authentication service were to come around that everyone respected, and which only provided authentication, that would be great. I just can't imagine who that would be. It's sort of been attempted before with OpenID, in that any OpenID service could be an authenticator, but that never caught on for a variety of reasons.
So no, I don't have a happy ending for you. I see password proliferation, password confusion and password breaches in our future as far as the eye can see. The best solution for now is a password manager, hack though it may be.