Last time, I blamed our security woes on the inadequacies of password-based web authentication. Users are poor at keeping their passwords secret, and tend to re-use passwords. Some sites will inevitably use poor security. Users can’t readily identify good security from poor security, and even when they can, there’s not a lot that they can do about it. Given this, implementing an authentication system that relies on a well-known username, and a secret password is a recipe for disaster. It is not a question of when a user’s credentials will be compromised, but what fraction of them already are.
If we know that l:p authentication is so flawed, why do we keep using it. More importantly, why did we ever start using it?
There once was a time where the internet was not the all-pervading thing that it is today. There was a time when there was no such thing as the world wide web. In these halcyon days, user authentication did not take place over public networks. If you were logging on to the mainframe (in those days, one had mainframes, not servers), you were doing it over a dedicated line. You were also a techie, one of the select few who had access, and you knew the value of the logon credentials entrusted to you. You did not have a vast array of accounts, just the one or two, and you guarded them well.
In these days, l:p was a good system for user authentication. Most of the situations which give rise to the current shortcomings had not yet come to pass. Systems and behaviours were different, as were the economic pressures surrounding them. Unfortunately, however, times have changed. The background to user authentication looks quite different now. Everyone and their mum has dozens of accounts with various websites. Unfortunately, neither everyone nor their mothers are universally good at l:p management. Why should they be? It’s a hassle, and one that’s very costly to do right, even if one understands how. There’s money to be made stealing Ebay and Paypal accounts, among many others. The ubiquity of l:p authentication means that a single insecure sign-on brings the security house of cards crashing down.
Alternate user authentication schemes have been studied extensively. Although no system has been determined to be perfect, many good alternatives have been developed, which solve a good range of the shortcomings of l:p. It’s possible that there’s an Arrow’s theorem-like property of user authentication that precludes the existence of a system which exhibits all the properties which we would like. However, there are still many system that exhibit most of the properties that we would like, and l:p certainly exhibits very few of them. Why does l:p soldier on so?
L:p is just easy to do. Every language has some easy-to-use l:p module, and writing good user-authentication is not an easy thing to do. If l:p fails, one can blame the users, or simply throw up one’s hands and say that it’s the state of the art. Finally, users are accustomed to l:p. If you bring out an alternate authentication system – like using unauthenticated HTTPS – users may be spooked. If you’re new to the market, this may just be too much.
Because of this collective action problem, it’ll take a big player to move us away from l:p, and towards a more effective system. Federated logins like OpenID, Facebook connect, &c. are a good first step. They move responsibility for user authentication away from the site, and towards the hosting provider – the site just has to include the federated login code. However, when the central login is l:p too, there’s still a single, weak point of failure. When – like with Facebook – it’s insecure l:p, the problems get worse. However, with secure federated logins, the potential exists for the provider to move to a more secure authentication system. Such a change would be propagated across all sites using that login system – making them all more secure.