I swear I’ve been meaning to write up this exact idea for a long time, but Lucas Gonze does it better anyway:
It would be cool to be able to log in to a web site using just your email, without even a password. It would work just the same way that password recovery does now, except that you wouldn’t ever type in your password.
That’s it, but read the whole post for more explanation and rationale.
I just have two tiny points to add. Gonze:
I am thinking about this because Facebook constantly makes me log in, and I don’t care about it enough to memorize that password.
I’ve thought of it because I don’t know whether I can trust a site. Even if they store a hashed version of the password (I hate it when a “forgot your password?” procedure sends the one I forgot rather than generating a new password, which means they’re storing the actual password — that’s why I got a bit of a kick out of this extreme), they have access to the password I’ve selected at some point.
Of course you can effectively do this now — just register with a random password and when forced to login again, request a new password. But sites that force you to login frequently make this painful.
Why do sites force frequent logins anyway? The real mystery is sites that do not force login every session (presumably this reduces problem of people forgetting to log out of public terminals), but something longer than a session and shorter than many years. What problem is that addressing?
What about OpenID and the like? Orthogonal, and not nearly as widely deployed as email (or IM or SMS, which would also work as password recovery/routine authorization token delivery mechanisms).
On a completely different topic, check out “Cover Yourself” podcast, an awesome Gonze post I’ve been planning to say more about since July, and will eventually.
[…] 12th, 2007 Mike Linksvayer » Passwordless login Why do sites force frequent logins anyway? The real mystery is sites that do not force login every […]
There’s a Dutch website which does this:
No password needed for this website :)
They are located in my hometown, The Hague, Holland.
Once upon a time not everyone had a continuously accessible e-mail address.
Websites had to cater for people without them.
Even today, many people don’t have their e-mail accessible via the web, but only via a pop client on their home PC.
However, yes, for those people able to retrieve their e-mail at the time they register with a web site, e-mail based authentication is just as sufficient as a simple name/pwd pair.
But, are new sites yet able to dispense with name/pwd? Perhaps they can now offer some varieties:
1: Name/pwd – optional e-mail
2: E-mail/pwd – e-mail only occassionally accessible
3: E-mail – e-mail always accessible
Half the problem is keeping the registration process simple and familiar.
Marco, cool, thanks for pointing that one out.
Crosbie, all very good points. Explains why things are the way they are and will continue to be for some time.
[…] because he was ticked off that Facebook constantly made him log in. He then highlighted part of my response: Why do sites force frequent logins […]
Brad Templeton explains why sites should not store plaintext passwords http://ideas.4brad.com/dont-e-mail-me-my-password
[…] In the meantime, I’m still a big fan of super simple methods of going passwordless. […]
Interesting idea… I came across this while reading up on peoples thoughts of OpenID, to me this seems a much simpler idea for avoiding the problem of forgetting passwords.
As for the problem about people who aren’t always able to access their email, this problem occurs already as most sites require you to verify your email by clicking on a link or entering a code. If you aren’t bothered about verifying your users email (most sites shouldn’t be) then you can just setup the users session once the registration is complete so they only need to click the link if it expires.
It would be relatively easy to make an OpenID server that only used an email ping as the authentication method. Your OpenID identity could be something like:
…with no prior account at mailauth.example.com needed (unless you wanted to store some profile information there). This would centralize the email confirmation round-trip process, and make it easier for people with spam controls to whitelist just one confirmation server.
You could do just one email confirmation once per browser session (or even longer, at your option) — after that, you stay logged into mailauth.example.com. You wouldn’t have to confirm once for every site you log into.
This seems like it could be fun… I might try to hack it together.