No protocol is so behind on authentication as the web. It is the most important vehicle for many of us, but we are still dealing with site-specific passwords. And letting this be solved by large corporations isn't quite the Internet style of doing things either.
This document is part of an article series on Web Architecture.
The original idea
Websites make resources such as documents accessible over the Internet, which is a great utility that avoids that we need to remember to pack not just our suitcases, but also our laptops (and batteries!) before we travel.
Some of the documents shared this way are not supposed to be public, so their access can be protected. This is a normal practice on the Internet at large; you would be rather surprised if your mailbox didn't require you to provide a credential of some sort.
Very strong security mechanisms have been developed to stop people from attacking the privacy of our online documents. And these mechanisms are so powerful that everything but the actual credential can be made public -- all that public knowledge will not help an attacker one bit.
How we wrecked it
The customary "technology" for website protection is a password. That in itself is rather lame, because the same passwords are often used in many places, and so one website could use it to login on another, and act on your behalf.
Users being as they are, they cannot be trusted to memorise difficult passwords. Some site administrators realise this and come up with frivolous requirements about characters that should and should not occur inside passwords. Yet others impose an upper limit to the number of characters in a password (really!) or have other frivolous ideas about pesturing users into behaviour to compensate for their site administration shortcomings.
Like it or not, passwords are bad. They have never been much good, but very little is available as an alternative. And so we keep typing them. Over and over again. Even if we are aware that they cause grand trouble.
We have recently seen a different movement on the web. "Free" service providers who represent many online users are offering login services. What this means is that a user will login with these sites, and web site owners go through a quick exchange with the "free" service's site to establish that the user can indeed login.
There are a few disadvantages to this scheme. First, it usually applies only to the web, as if there is nothing more of use to our online behaviour. Second, it makes the user a subject under that "free" service's umbrella, which means that the online identity of a user is not fully under his own control; it is subjected to the well-being and agreement of a that party's definition of "free". Third, providing information about each and every login provides an excellent opportunity to track and trace a user's online behaviour. And, seeing how the web is developing, I would not even be surprised if login service user agreements in the near future will permit the "free" service to login to your account and look around -- perhaps to "make sure you are not doing anything illegal". Yeah, right...
When it comes down to authentication the web is very, very much out of control. Specifically, it is out of the control of end users.
How we can fix the web
Surprisingly, there are a few good solutions for authentication with websites. Some of these are fairly new and still getting started. Others have been rolled out in the interest of large corporations who require single sign-on and proper security because they are internally accountable; it is easier to command an employee to adhere to a usage policy than it is with the web at large, but do we really want that to stop us from getting some decent security?
Large-corporation solutions revolve around infrastructure, the precise thing that many small-office and home users don't have. The common forms of infrastructure are a Public Key Infrastructure, usually based on X.509 certificates, and Kerberos which is a single-signon system that involves much more than the web alone. Of the two, Kerberos is by far the most refined method, but Kerberos authentication to web servers is not ideal, so we are working on an improvement that is helpful for anyone from an individual to large corporations.
Both infrastructures are well-spread, that is they are embedded in a sufficient number of browsers to offer it to anyone. For X.509, the user would install a certificate and with Kerberos they would acquire a ticket, usually once a day and usually automatically when the login to their desktop. Both systems make it possible to run in and out of a protected site without explicit authentication, but they do establish strong trust.
A few down-scaled alternatives are also moving in, albeit slowly. One of them is SRP, a password system that does not tell the website what the password is, but instead juggles cryptographic numbers around to prove knowledge of the password that matches a verifier that is known to the website. And for those without an X.509 certificate and some reason not to get one from CAcert of StartSSL, OpenPGP keys can provide an alternative to authenticate with a website, although most browsers don't support that yet.
These last few options are helpful for small players who lack the infrastructure of large corporations, but they are not as widely usable. We believe that end users should have the same comfort level (and security level) as large corporations, so why not share their technology? For this reason, we are aiming at the development of Kerberos and PKI solutions for those who host their domain name with a hosting provider.
The end result is that everyone who goes online has a fair option of being their own identity provider. Or perhaps a family can pick a member to arrange it for them. But at least control stays where it is most democratic: nearby the people who are subjected to it.
Go Top