Simplest Email Identity
---
Ah, last of the month again. Why not write about something useful?
One things that bugs me, is how web sites do identity or login in ways more or less clumsy and terrible.
But let's not get into rant mode, I'll just tell you of a simple solution. And _then_ maybe go on a rant.
It's really simple: show an email input field. Send access token to that email as a link. When user clicks link and reaches your web site, add the token, or a variation of it, as a cookie. Done. Now you have a cookie that verifies the email identity, and can be used to authorize operations.
Note that the access token can be simply a signed message. That way, no storage is needed on the server. So no statefulness _at_ _all_. So no scalability limit here.
Encode a time of issue in the access token, and have a max age for some operations. Sill no storage needed. Just keep your server clocks somewhat accurate.
The email can be used for easier reissuing of a new token. No need to fill it in again. Can even be sent out automatically before expiry, or when user accesses site, for instance tries operation requiring an access token younger than the one set as cookie.
The email input field should have the type='email' attribute. This way, the browser can check syntax, or even fill in the email for the user. So 'signing up' for a site could be done with minimum effort, and then only require waiting for an email that should be arriving shortly.
--
So, that's the gist of it. I've implemented this in Java, and am currently re-implementing it, simplifying it further, and I might publish more details helping to implement this, or even code or a jar to run a demo of such a site.
So, there it would obviously be much better if this was handled some other way, perhaps as a standard interaction with browsers, where the user is asked if it wants to reveal his or her identity to a site asking for it. Or partially reveal.
And/or there could be trust networks; e.g. there could be sites issuing or guaranteeing identities. There already is standards and players here, of course; OpenID, Facebook. But then you'd have to trust them. And Facebook reveals too much, I'd say. There should be steps, so that you have the option to only establish an identity without going further with details like names and friends.
Now, you might say that an email is already too much. But a user could have a secondary email just for testing sites out. A problem then might be transferring to a real email if you want to be known more as yourself, e.g. if the site provides social services where people can get to know you by email.
---
There is the ever-present safety and security considerations. What can of damage can an attacker do to the described scheme?
Using the signed-token implementation, scalability is of course a first defence.
A serious issue with email verification is always sending too many unwanted emails to people; even though there is not much an attacker could get out of it, except hurting the reputation of the targeted site. Rate limits per email address, is one thing. This requires storage and synchronization, thus hurting scalability.
An attacker could create unlimited numbers of email accounts, perhaps using a mail server specifically for this purpose, and register each of them automatically. Using the encrypted-token implementation, no storage is used, so this attack is not so useful in a first stage, but the attacker might go on to use whatever resources are afforded by the site to each identity. Per-domain limits might help.
--
Additional small things to help.
Email apps could have separate folders or filtered tabs for identity mail, like 'forgot password' messages.
Email apps could throw away reset link messages after they are used or after they're expired. Or perhaps just default to discarding them after a month.
--
Now for the ranting. (Separate article?) A web site should not...
A web site should not require a username. This means the user must come up with, and remember a user name. Come on, I've better things to do. We all have, I hope.
A web site should not require a password, if there is any other way to do it.
A web site should do this in their own interest. How many simply balk at signing up, and just leave the site?
A web site should not require a real name on sign-up. In addition to requiring even more extra work, unless auto-fill can be leveraged, a user might not want to tell. A user may want to gain confidence in the utility and seriousness of a site before contributing private information.
Worst case when a web site requires a username and a password: you forget them both. You'll have to:
(*) guess username/password. Get told 'username or password wrong'.
(*) what now? Have to guess which one is wrong. Site could've told if it didn't know the username. Of course, you could still have guessed somebody else's username.
(*) click 'forgot username'. Fill in email. By hand, no auto-fill. Click 'send', or whatever.
(*) wait several minutes for mail.
(*) fill in username; there not being a link in the mail doing this via URL params.
(*) fill in password again, it was not saved in browser's local storage.
(*) Get told 'wrong password'.
(*) click 'forgot password'. Fill in email. By hand, no auto-fill. Click 'send', or whatever.
(*) wait several minutes for mail.
(*) now you'll have to reset your account password, filling in password twice.
(*) you'd think the site could log you in from there, but no; now you have to log in again.
(*) Done, if you've managed to stay. Now you can check the status of your ticket or do whatever trivial thing you needed to do.
--
Odds and ends: use HTTPS, further automation, fine-grained authorization, finding similar existing implementations, compare to existing non-similar implementations and thinking about tweaks in this direction, password managers as a solution, what is the 'culture' and sociology that has made this bad state a reality, etc, etc.
