To Home page
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:
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