To Home page

The login problem

Increasingly applications and activities are networked, though our operating systems are still oriented to a single computer.

Linux makes a start on fixing this, since one can routinely open a window on one computer managed by a program running on another computer, and all operating systems allow the user to have access to files on the network.

This of course means that the user has lots and lots of logins, which are usually made possible by durable secrets.  Durable secrets are a big problem, and durable shared secrets a bigger problem, so it is unsurprising we have crises such as phishing.

For machines logging into machines, this problem is, if not solved, substantially under control with public and private keys, unshared secrets which are used to generate transient shared secrets.

With humans, however, we have a big problem, for human secrets are small enough to come under dictionary attack and are commonly shared secrets, so can be phished.

Password-authenticated key agreement solves phishing - both sides authenticate to the other, and attempting to login to an impostor leaks no information to the impostor, but, of course, still vulnerable to online dictionary attack.

To prevent user enumeration, the login process should never reveal that there is no such user, merely that if there is such a user, that is the wrong password.

To prevent online dictionary attack, server should use reverse Turing test.  To avoid inflicting a reverse Turing test every time, a successful login should store a transient unprotected secret or weakly protected secret on the computer that successfully logs in.  Possession of this secret excuses a person logging in from the reverse Turing test - but every time he makes an unsuccessful login, there is a finite probability, perhaps one in six, that the server will forget that secret.

This solves the phishing attack, and the online dictionary attack, but we still have the problem that humans have too @#$% many logins, and thus too @#$% many secrets.

The obvious solution to this problem is single sign on, but various attempts to introduce single sign on, often backed by big money, big marketing, or widespread consensus, have failed, even though there is obvious and pressing need for a single sign on solution.

There are at present three solutions for single sign on, none of them having great success:

Microsoft's solution: Change the server, the client, and the end user's behavior to use an ID card metaphor. The ID card is the user interface representation of cryptographic credentials supplied by a server.
Consensus solution: Change the server, but not the client. Change user's behavior merely by using a url as a name. Oversimplifying drastically: The server bounces the client to the URL with an argument saying “log me in to the original server”. The identity server sends the client back to the original server with a validated id as an argument.
Heroic solution: Changes client to provide single server based login, but fools server into thinking this is an ordinary human user based login. Requires some thought and learning by the end user.

None of these solutions fix a major weakness in the present identity system - the lack of push. If you have a login relationship with a site, there is in general no way that site can send you validated messages, messages that you know came from the site with which you have the relationship

To fix this problem, a single sign on solution must support a user interface akin to the instant messaging interface

We need a client side signon/login tool, which also enables the client to receive messages from entities with which the client has a login relationship, analogous to the buddy list in IM, and, like the buddy list in IM, only from those entities.

The interface of the signon tool should resemble an IM interface, and also resemble the interface for a browser's favorites list. However clicking on a "buddy", instead of opening a chat window with the buddy, brings you to the web page like a "favorite", but you are logged on, unlike a "favorite". Clicking on a message, instead of opening a chat window, brings you logged on to a web page belonging to that "buddy", but a web page selected by the message author (a web page that normally contains the body of the message), instead of the web page corresponding to that "favorite".

In the present incarnation of the tool, the three parties to an interaction are the single sign on server (SSS), the client, and the relying party. The relying party is the web site the client wants to log in to, for example a bank or a blog.

As with an instant messaging system, user has to register and logon to a single signon server. Any server will do. So we then face the problem of making the signon server invulnerable to phishing: One solution to that problem is password-authenticated key agreement, and another other is to have a short list of public keys of permitted single signon servers, a list that the user can add to, but which is not easy to mindlessly do a one click add.

These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License