PasswordlessLogin

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Common login protocols require the user to supply a password as a piece of information that is supposed to be easy for them to remember and hard for others to guess, and thus is supposedly PersonalIdentification. However, in practice, the former is not always easily obtained (which means that some reminder system such as a SecurityQuestion? is needed), lost, compromised, stolen, or made into generic terms that anyone can guess (which means they need to be changed periodically). More to the point, PassWord?s are SystemCodes, and it is wrong to expose system codes to the user. Can we eliminate passwords from the LoginProcess??

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.

Benefits

E-mail has the advantage that is obvious to most users.
Don't need to remember your PenName.
Don't need to remember your password.
You can create an confirmed account instantly; new users just type in their e-mail address and they will be up and running.

Drawbacks

Privacy issues around giving an e-mail address may mean in your context, this may not work. In most contexts where e-mail addresses are known, it's probably not a problem.
Spam filters may eat the authentication e-mail.
Potentially (though not necessarily) exposes e-mail addresses publically to spam bots.
Accessing sites from work will leave a paper trail in the automatically archived e-mail server.
Accessing sites from anywhere (hotel, internet cafe, ..) isn't that easy, is it? -- HelmutLeitner

Examples

Many MailingList packages authenticate new subscriptions in this way, except they don't create cookie X.

Extensions

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).

Discussion

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.

: That is true to some extent, but this is based on probabilities. For instance, that failure mode presumes the confirmation e-mail is confusing. What is the probability the e-mail is confusing? If it is sufficiently low, as a malicious user X, it would be like winning the lottery to pick a winning address. We can measure the number of times a given IP asks to generate an e-mail, and thus detect malicious users, although in practice that will likely not be done. More practically, we can time limit the duration the cookie persists. The probability of a gullible user replying immediately is much lower.

: (And of course LoginsAreEvil. AvoidIllusion.)

: By the way, concerning your URL scheme, you don't have to reuse that URL. It can (should?) be a once and only once nonce, so that even if it appears in the URL history, it will not work. Carrying an e-mail around to log in doesn't make sense as people don't necessarily have access to their e-mail from where they log in. -- SunirShah

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

: Adina: I can't necessarily provide the technical details of how this works, especially since I know there are differences among the various systems that implement this type of thing, but I do know that I don't have any problems with this at Meatball (cookies, but not password protected (yet)) or several of the other sites I use. I believe this is because the preferences are simply tied to the user name (for now). If (or as) passwords are added, various schemes already exist that do appropriate authentication. Hence there are many possible answers to your question. I'd be pleased to add what I know, if you care to direct my focus to any particular specific aspects of these security schemes. -- HansWobbe.

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

: Sunir, you say "people don't necessarily have access to their e-mail from where they log in." Doesn't that break your entire scheme? I am at the public library, without access to email (unlikely for me personally), and want to log in. How do I do it? Once the picture grows to include multiple computers, and especially public computers, this scheme seems more cumbersome (one email handshake per computer, and one per session on public computers; also you must have access to your email and be patient enough for the confirmation email to make its way to you) than the alternative (passwords).

: Maybe the answer is to support both? Either way, it's also necessary to have a clear and simple way to "expire" one's session for public computers. -- anon.

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

: This "passwordlessness" is essentially a one time password transferred over a separate and previously authenticated medium, namely email. It has some precedent, and depending on how secure the email is, it can be more secure or less secure than passwords. I'm not entirely sure users will go for it though. I certainly wouldn't be willing to jump through such a hoop every day just to post. I suppose it could be an option to use it instead of a password. -- ChuckAdams

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

CategoryWebTechnology