Do we need to ban the password?
Ok, I'm not really much of a fan of banning anything, but the continued reports of massive thefts of password databases from web sites are not slowing down. Whether the recent Hold Security report of discovering a Russian ring that got a billion account records from huge numbers of websites is true or not, we should imagine that it is.
As I've written before there are two main kinds of password using sites. The sites that keep a copy of your password (ie. any site that can e-mail you your password if you forget it) and the sites who keep an encrypted/hashed version of your password (these can reset your password for you via e-mail if you forget it.) The latter class is vastly superior, though it's still an issue when a database of encrypted passwords is stolen as it makes it easier for attackers to work out brute-force attacks.
Sites that are able to e-mail you a lost password should be stamped out. While I'm not big on banning, it make make sense that a rule require that any site which is going to remember your password in plain form have a big warning on the password setting page and login page:
This site is going to store your password without protection. There is significant risk attackers will someday breach this site and get your ID and password. If you use these credentials on any other site, you are giving access to these other accounts to the operators of this site or anybody who compromises this site.
Sites which keep a hashed password (including the Drupal software running this blog, though I no longer do user accounts) probably should have a lesser warning too. If you use a well-crafted password unlikely to be checked in a brute-force attack, you are probably OK, but only a small minority do that. Such sites still have a risk if they are taken over, because the taken over site can see any passwords typed by people logging in while it's taken over.
Don't feel too guilty for re-using passwords. Everybody does it. I do it, in places where it's no big catastrophe if the password leaks. It's not the end of the world if one blog site has the multi-use password I use on another blog site. With hundreds of accounts, there's no way to not re-use with today's tools. For my bank accounts or other accounts that could do me harm, I keep better hygene, and so should you.
But in reality we should not use passwords at all. Much better technology has existed for many decades, but it's never been built in a way to make it easy to use. In particular it's been hard to make it portable -- so you can just go to another computer and use it to log into a site -- and it's been impossible to make it universal, so you can use it everywhere. Passwords need no more than your memory, and they work for almost all sites.
Even our password security is poor. Most sites use your password just to create a session cookie that keeps you authenticated for a long session on the site. That cookie's even easier to steal than a password at most sites.
There are a variety of tools for browsers that will generate unique passwords for you for every site, and remember them. That's great when it works, but you must set up synch on all your devices, can't go to a new device easily, and many sites actively work to disable the functions in browsers that remember passwords for you. In addition, in a mistaken effort to improve security, sites all have different rules about what characters can be in passwords and which can't, and of course some sites ban what others insist on, creating more problems.
Even the best of these tools have few users because they're really trying to put a bag on a kludge.
The right technology for authentication is public key digital signature. With digital signature, sites can authenticate you and what they store about you compromises nothing if it's stolen. What's sent over the wire compromises nothing if somebody's sniffing the wifi. It works, and is well understood. And it was built into every browser decades ago, but with the bad-UI features the security world has been plagued with since the dawn of time.
Digital signature can even be used to authenticate each web hit independently, so no cookies can be sniffed, though use in this style is currently rare.
Digital signature has to be done by a computing device. You can't just remember a password to make it work. It needs a private key that few humans could train themselves to remember, and none would want to try. That means to make it work from all your devices you need a safe way to authorize the new devices. (You don't have to necessarily copy the key, but somehow you must get authorizations given to the key of your new device.)
Without special care, loss of a device, or its storage, means loss of your authorization. That's one reason we like passwords -- stored in our brains they usually survive the loss of our devices. We forget passwords all the time but we also lose devices or disk drives too.
For this reason most systems combine digital signature with a password. The password is rarely used (which has its own issues) and never used on two different sites. The password lets you recover an encrypted copy of your private keys, or to re-authorize new keys. This can work OK, though rarely used strong passwords tend to be forgotten which creates other issues.
A frequent proposal is that we all need to start carrying a second device which contains our authentication tokens. That device must be very secure, which means it must do very little. In the past, we usually thought that would be our phones, but our phones have now become big multi-purpose computers with many vulnerabilities of their own. Trusted computing architectures could help, though in the past the main commercial use of trusted computing has been stuff like DRM that lets outsiders trust your computer to regulate you, rather than you trusting it against attack from outsiders.
Again, for some users, have an extra device will still lose out to the perceived convenience of passwords. They'll be at the computer downstairs and their phone or auth key will be up in the bedroom. Many companies use USB devices for secondary authentication, and nobody loves them. In fact, none of the secondary authentication tools used by the more security conscious have user experiences that are well loved.
Identity vs. Authentication
Another effort at this problem came in the form of single sign-on web services, now often called identity management. This began with Microsoft passport, but there was huge backlash against Microsoft owning login and identity, resulting in failed movements like OpenID and the Liberty Alliance. OpenID had you specify an "identity provider" which could be yourself, or could be a big site you regularly sign into. OpenID failed both because of bad UI, and the fact that the few sites that implemented it often made it even harder to use than it was, making you create an account anyway after authenticating with it.
Later, after various systems came and went, Facebook became dominant with Facebook connect. This was perhaps the worst possible situation -- now when you connect to web sites, they can ask for all sorts of data about you, and Facebook learns even more.
All of this came from the conflation of "identity" and "authentication/authorization." What we really want in most cases is authentication. In fact, identity is a subset of authorizations, in that what is typically considered identity, such as my name, is really the fact that I am authorized to use that name on the site. While a Driver's Licence does often get used as an identity card, its primary purpose is to demonstrate I am authorized to drive. (For that, a photograph of me would suffice, my name and other attributes need not be on the card.)
Too many other forces wanted more than just knowing if a user is authorized to do what they're going to do on the site. They wanted identity. In fact, they got it backwards, and decided identity was primary, and that authorizations were something you got by asserting an identity. They wanted identity both because of the world's long history of using identity in things, but also because that let them develop business models based on gathering data about people (identity) and using that to market to them.
Users, once they think about it, are not interested in telling everybody they deal with on the web the details of their identity. That's an anti-privacy web. So we prefer to be in control of our access, at least some of us.
What does a good system do?
Here are some attributes we might need to see in a good alternate system of authorizing on the web.
- Users can readily choose between managing it themselves (in the browser) or farming it out to a remote server (Facebook Connect) and both should always be easy to do.
- The ability to handle such authorization should be present as standard in every browser, and it should work with the least configuration possible. That means it should do the basics with zero configuration.
- There should be strong disincentives against sites making the system provide more information than they actually need. Contrary to some intuitions, that means handing over identity data should be hard. Ease of use is a bug, not a feature.
- It should be very easy to quickly to authorize yourself on other devices when you want to.
- There has to be a way to recover your authorizations if a device is lost
- If passwords are to be used for functions like the above, that's OK, but a way must be found so that the passwords will be used enough to be remembered, but not so often as to make it annoying to use a secure one. Other biometrics may make sense instead of passwords, but it must be biometrics that can be measured anywhere. (eg. not just on devices with fingerprint readers.)
- Consider authenticated actions rather than the login model.
- Understand that different actions at a site require different authentication.
- Commenting on a blog requires almost none and should be trivial. As close to no UI as possible.
- Seeing my bank balance should require more, but not so much as it makes it painful.
- Transferring money out of my bank account should require really secure authorization. It's OK if this is more painful. Two factor is a likely must here, while not as strongly needed just to look at the account.
What we need is a process that is seamless where it can be, and not seamless in the important places where it shouldn't be. Instead, we've gotten a mishmash of systems which sometimes make it hard to do trivial things, but also make it too easy (for bad guys) to do important things.
What do they need?
With a proper authorization system in place, most sites don't need much information from you at all. Today most sites want your E-mail, and use it as a userid. They also use it to help you reset/recover your password, to contact you about actual important things (rarely) and to contact you about their marketing needs (more commonly.) The ostensible use of the e-mail is to stop spam. They make it harder to spam, and can delete accounts of spammers, though they can't usually stop them from creating new ones as any spammer can get lots of e-mail addresses. They often ask for a name, though they almost never authenticate it.
With a proper auth system, most sites should let you do basic operations with an almost invisible sign-up. You would tell your authorization system to give credentials to the site, and you could fill out things that are useful to you (such as your name or pseudonym for commenting on blogs.) Sites could insist your credentials be "vouched" for by somebody -- to show you are a real human, or not a spammer. This could substitute for the very poor system they use of e-mailing you a link to click on to confirm the E-mail. If you use credentials that are vouched for by a domain or other agent, that should be enough.
That should handle most sites. For shopping sites, you would offer credentials given to you by a credit card company or other payment processor. After all, that's what they really want. Credit card numbers are poor substitutes for that. E-mail can be passed along, but ideally the credit card companies would offer you temporary E-mails that are easy to turn off.
Special high-security sites, such as your bank, brokerage, domain name registry and others would go through a more involved process, as they should. And those credentials should get extra protection in your computer -- local passwords, external devices and keys, etc.
But let's start with getting something in place to reliably replace the password, to the point that we can indeed deprecate sites that use them. Of course, sites will never put a warning on their password pages, but it's not out of the question that a browser tool might start adding that warning before too long.