Passwords are annoying. They're hard to remember, but often easy to guess. People choosing simple passwords often have trouble keeping them secret. Those who choose more difficult ones have to write them down, which also makes it easy to steal.
The main idea here is to avoid using passwords altogether, so that web sites automatically recognize users based on credentials stored by the browser. In addition to being easier to access and less error-prone, a proper implementation can make this scheme safer than the password-based authentication model.
The problem of web site authentication is simple: web sites need to know who they're dealing with when making transactions. Stores need to know who is buying their products, so that they can charge the right people and ship to the right address. Email clients need to show the right emails to the right users.
Maintaining a session is a related problem addressed separately by the author. The difficulty discussed here is that of identifying the user when they first enter a site. It is assumed that, once entered, the site can keep track of who the user is on subsequent pages.
The username/password pair is the most common credential required to access web sites. From email clients to bank accounts, nearly every web site that keeps track of users employs this model of authentication. Since the space of passwords is fairly large, it's very difficult to guess them randomly, and only authorized users are given the passwords.
Of course, in practice, people often choose easy passwords, like their dog's name or their birthday. Otherwise, they write them down, exposing them to easy theft. Either of these represents a real security risk. Many web sites argue that their data is not important enough to protect with more serious security, but they neglect the fact that most people use the same or similar passwords for all (or at least many) of their accounts. Thus, finding the password to one's spam-bait email account, which may not contain sensitive information, might lead an attacker directly to the person's bank account!
Additionally, it's annoying for users to have to enter user names and passwords into every web site they wish to use, especially if they follow good practice and use different username/password combinations for each web site.
A different solution to the web site authentication problem uses public key encryption instead of passwords. Under this system, there is a central authority for public keys, which associates them with email addresses.1 Every user has a public/private key-pair, whose public member resides in this central authority. The private member is kept secret, available only to the user himself.
When a user wants to enter a website, he enters his email address into a form. Upon verifying that the given email address corresponds to a real user of the web site, the web server then queries the central key authority for the user's public key. Using a challenge-response authentication mechanism, the server can verify the identity of the user.2
By the end of this process, the web site is sure that the user is who she says she is. The only way to pass the authentication test is to have the correct private key, which (presumably) is only stored on the user's computer. The user didn't even have to remember or enter a password! In fact, one could implement this system in such a way that the browser sent the user's email address as an HTTP request header, so that the user need take no action at all to login to a website (and yet, it is still safer than using passwords).
Clearly, the public key system is easier for users after the initial setup; there is nothing for them to do after that. It's also not very difficult for server developers to implement the authentication scheme in their software.
The primary implementation difficulty is in the central repository of public keys, which absolutely needs to be trusted, fast, and safe from attackers. It must be trusted so that people can be sure that they are getting the right public key when they lookup a person's key. It must be fast if it's part of every login session for every web site. And it must be safe from attackers who might try to replace a user's public key with their own, gaining access to their accounts.
There is a small amount of initial setup required for the end user; they must create a public/private key pair. They must confirm their email address and submit their public key to the central key server. Then, they must store the private key on their own machine. However, with a well-designed browser extension, all of this could be automated and behind the scenes except the user's email verification.
Browser writers must implement this challenge-response protocol; that could be challenging over HTTP, but is certainly not terribly hard.
Finally, there is the limitation that a user can only log into websites from the computer on which they created their public/private key-pair. This could be overcome by putting the private keys on a remote server, which a person could (with difficulty, and some form of serious verification) access. But this solution requires even more care on the part of the central repository maintainers, as real secret data would now be contained there.
With large enough keys, it can be made arbitrarily computationally infeasible to employ a brute force attack on this system. It is effectively like using very large, random passwords which users don't have to remember.
With access to a user's personal files, however, an attacker gains access to the private key and thus all the user's accounts. However, in this case, the attacker likely already has a great deal of sensitive information, and this is a worst-case scenario in most respects.
In fact, access to a user's files is really the only way the author currently sees to break this system.
First, assume a central repository of public keys exists. It has a web frontend through which people can sign up and edit their accounts, which are fairly minimal in data (email address and public key).
Imagine an extension to the Firefox browser (or Internet Explorer, of course). When first installed, it asks the user for their email address. It sends them a confirmation email with a random code that they must re-enter into the browser plugin.3 The plugin then takes care of the public key generation and submission to the key server.
The browser extension also recognizes, perhaps by the presence of an HTTP header, when a web site is equipped for this type of login. It handles the challenge-response authentication behind the scenes. In this way, very little interaction is required by the user.
This system works even for the variant described above where private keys are also stored on the key server. The user could at any time request (either through the browser extension or the key server's web frontend) a new random code to be sent to their email address. They could then enter this code to obtain their private key, to be used from that browser. Quickly and easily, they can use secure authentication from any web browser.
The weakest link here is the email security, but that can be handled similarly (using public/private keys), and all transactions should take place over SSL (security) enabled connections anyway.
This would be great for authentication on all web sites, but the application of e-commerce is particularly in need of this sort of system. If users were required to digitally sign4 all online purchases, credit card fraud would be much more difficult.
Users could digitally sign their final order with a web site. Now if the user, upon signup with a credit card company, was required to provide an email address, then the credit card company could keep track of that user by that address. In particular, whenever the user makes a purchase online with the credit card, the credit card company mandates that the transaction be digitally signed by the public key associated with that email address. In this way, a hopeful fraudster could not use a credit card to make an online purchase.
It has been shown that better method of web site authentication exists in the idea of public key encryption. Every user has a public/private key-pair tied to their email address. They use this key-pair to gain access to web sites. In the end, this method is safer (since access to web sites is effectively tied to access to one's personal computer files) as well as easier for users (since they don't have to remember anything but their email address).
This document was generated using the LaTeX2HTML translator Version 2002-2-1 (1.70)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -local_icons -split 0 -t 'Public key encryption for web site authentication and identification' pubkey.tex
The translation was initiated by Dave Pacheco on 2005-08-08