Another piece of PersonalIdentification that is commonly supplied is a user's e-mail address. Usually this is supplemental to the 'login', but LoginsAreEvil and not personally identifying information. Consequently, the PenName that people choose for themselves are not critical to identifying themselves, but rather it is the PenName that is supplemental. This is self-evident as users may have to have different logins in different spaces, especially if they have a PenName that conflicts with someone else. Users should rather log in with their e-mail addresses, since at least that is consistent across spaces.
E-mail addresses aren't just names, but they are functional addresses that tie into wider technology--that is, their e-mail. Their e-mail inbox is something unique to each person. A PasswordlessLogin could use e-mail as the authentication method, rather than a password.
To do this, when a user wants to authenticate themselves on a website, create a cookie for them (just as you would do in normal login systems), and put a unique randomly generated number (a nonce) X in that cookie. Create another nonce Y and associate the two nonces on the server side. Hold the cookie with the nonce X in limbo until it is authenticated. Send an e-mail to the user with Y. All the user has to do is reply to the e-mail with Y, and the cookie with X will now uniquely identify the user to the system.
If someone tried to spoof the user by requesting an authentication e-mail, thereby generating a cookie for themselves, and then replying with FakeMail. Since they don't know Y as it is sent to someone else, they can't authenticate their cookie.
Understandably, people do often change their e-mail addresses, yet they want to maintain a SerialIdentity. The easiest answer is to just not have any critical information associated with a login (i.e. beyond basic customizations). Certainly the benefit of the UseRealNames policy is that SerialIdentity is mostly persistent against superficial changes. Since e-mail addresses are usually quite identifying, this is usually not too much of a problem. Alternatively, one could employ the slightly more risky scheme where one can take over another e-mail address's profile by simply making a request by e-mail. The system sends an e-mail to the old address. If no one replies within a period (say 30 days), then the new address can take over the old address's profile. Of course, this is only necessary if the old address is no longer accessible. Otherwise, a simple change in configuration would suffice.
Finally, if you would still like to use PenName's, there is nothing stopping you from associating an e-mail address to a PenName, and then going through the same process.
Many MailingList packages authenticate new subscriptions in this way, except they don't create cookie X.
This idea can be extended into other password challenge environments, provided the users are attached to a network that is simultaneously connected to by the server, and the user's point of interface to the network is unique to that user. For instance, rather than ask a user to log into the company network with a password, the network can phone the user's CellPhone and ask for confirmation. For added security, the system can take a voice print of the user saying their own name, or have the user punch in a nonce presented on screen (which admittedly defeats the purpose of hiding the system code).
The approach described above provides a chance at impersonation. If a malicious user logged in using someone else's email address, they'd be given cookie X. If the actual user ever replied to the automatic email that was generated as a result (perhaps thinking it was some periodic account confirmation), then the malicious user would be automatically confirmed.
A simpler and more secure approach would be to generate one random number, Z, store it on the server, and email it to the user as a URL (e.g., http://.../index.cgi?login=08A6BDC4C2BE0BE6). Once they click on the URL, they get a cookie containing Z. Now if they lose their cookie, logout, or move to another computer, all they need to do is go back to their email and click.
On a shared public computer you'd want to provide a form to paste Z in, so that it didn't appear in URL history. That is simpler than the approach described above, which would require another email reply sequence just to re-login.
But if you're asking the user to paste Z into a form, it's essentially a password. Now it's less user-friendly to ask the user to type in Z than it is to ask them to type in their email address and a password. So it seems we've come full circle to an email/password login, at least when you consider the needs of shared public computers. -- anon.
Making login depend on a cookie ties identity to a single computer. How does this work in the rather frequent case that a user uses more than one computer to use a web-based service? The user could presumably go through the email cookie-generation process additional times for each computer used. The system would need to associate a single user identity with multiple cookies so the username and preferences would be consistent, regardless of which computer the person signed in from. -- AdinaLevin
It is already possible to log in to web services from multiple locations. User management post-authentication will remain the same as with the login/password scheme. The only thing being replaced is the authentication challenge (i.e. the password). -- SunirShah
I think the answer is to support both. For long term cookies, use e-mail. For short term cookies, use passwords. I don't know if this is cumbersome or not. -- SunirShah
On second thought, the main purpose of this scheme is to defeat spammers, vandals, and other anonymous goondas. I don't care if it's harder for people to log in from public access machines, since that should be an exception. In fact, I am aiming to make that harder since Internet cafes are my target. While I accept this will burn out large parts of the world, I believe that for Meatball's purposes, people who do not normally have dedicated Internet connections, e-mail boxes, and personal computers are not relevant. -- SunirShah
Also, something similar to this does exist @ http://tintower.co.uk. When you create an account there, you specify an email address & a randomly generated password is emailed to you, however, all non web based email accounts are actually more specific to e.g. households than to individual persons. All web-based email accounts require the user to login, which requires the security of a password. One idea would be to provide computers with hand print recorders (which could easily be integrated into the computer mouse) and retina scanners. By designing some sort of plug-in for browsers, all one would need to do to register, is provide their hand print and retina scan and a random password is automatically provided. So, when they login, all they need to do is provide hand print and retina scan and the login occurs automatically. - anon2