Ask HN: Why not log into web sites via email without any password?
That's the process currently used for changing your password.
But why bother with a password at all? To make it convenient, you could have the browser automate the procedure for logging in via email.
39 comments
[ 4.8 ms ] story [ 76.8 ms ] threadAre you proposing that browsers get more involved in a user's activities on the internet? That a browser should remember a [email address|username] for various websites... and that alone would be sufficient for the user?
It would know when you attempt to log in somewhere via your email, it would look for a login email from the site (e.g., going to your gmail account), and it would go to the login link specified in the email automatically.
If you are going to do this right, you need email encryption. In which case, you have a client-side certificate. In which case, you might as well just authenticate over SSL with that certificate.
But hey, why do something secure and built-in to every browser (even IE) when you can invent your own protocol instead? It's the Internet!
Also, any reason why this is an "Ask HN" and not a blog post? (Not saying it should be one or the other... just askin'.)
Database of Christian dating site logins -> Same password as email -> Same password as Facebook and/or use email to reset
Also, I'm sure I have a dozen restore password emails in GMail somewhere. And I'm sure I'm not alone.
Maybe that should be the next Google Labs feature. The 'Mission Impossible' option. (i.e. 'this message will self-destruct')
In general, if someone can read your email, they can steal almost any of your accounts. Are email accounts generally that insecure? I trust any major Webmail provider to not steal my bank account, but is trust the only thing really keeping our bank accounts secure?
If we really are that insecure, then people are probably going to attack your bank account long before they attack your random web-app account. If your site isn't guarding valuables, it's probably perfectly "safe" to send authentication tokens in mail messages. No?
Maybe I'm reading this wrong, but isn't most email encryption done with GPG/PGP or S/MIME? Where do client-side SSL certificates come in?
To log in, you type in the e-mail. The server sends an email with a link (with secret code), which in turn sets a cookie when visited. The cookie expires in a month or so, and gets refreshed with every visit to the site. So the user only goes through the login process on a new computer.
One problem with this: it's too different from what's in place now. So users will be confused, at least initially. But this is actually an interesting idea.
This topic has been up for a whole hour and no comment from tptacek? What's going on??
It works for password reset because the window of opportunity is small (just a few minutes) and it is a once-only operation (visiting the URL again should not reset your password again).
What about the browser automating the procedure to openid?
1. If you're not using a service with super fast SMTP processing (i.e. Google) your email might not show up immediately. This would delay the login process while you're waiting for the email to arrive.
2. What happens when the email is dropped? (due to some stupid spam IP/Domain blacklist at the server-level)
3. What happens when the email ends up in your spam folder?
4. In relation to point #1, what happens when your email provider has an outage? You can't log into any other websites? This seems counter to the idea that the internet routes around problems. Your email account becomes a single point of failure. [I know that it's already a single point of failure from a security standpoint with password reset emails, but if my email server goes down, I can still login to sites as long as I remember my password]
I was saying any automation benefit for email would also help openid (for example) because it's already browser-based. If you can automate POP, you can automate openid.
I really, really wish the OpenID standard had used email addresses as the identifier.
With a URL it's trivial. Take mine for instance - andrewducker.livejournal.com
1) Go to that URL. Look for something like this: <link rel="openid.server" href="http://www.livejournal.com/openid/server.bml />
2) Forward the user there, saying that you're expecting them to be "andrewducker.livejournal.com"
3a) If you're already logged in and have given permission to that server to authenticate you to the page you came from then you just bounce back to the "success" page.
3b) If not then you have to log in and then it bounces you back.
4) Success
How would you do this with an email address?
My single change to the OpenID spec: perform discovery on a "well known url" on the same domain the email address comes from. After that, its the same as OpenID is now.
* Give before getting - we let you use the service before we ask for your email. * Make logging in via email simple. ie- Someone in your family posts a photo, you click on the link and you're logged in. * Don't get rid of norms (having passwords), but its okay to have new ways to get around it.
But I could see this working for websites in the lowest tier of security (like HN). Set a cookie for a year, and if you lose it or move to a different computer, receive a secret link via mail.
Access to your website stays in my control. I'm not depending on a 3rd party service, OpenID, or anything else, it's my own personal email account, and that email account's ability to receive email is all that's required for it to work.
1) I enter my email address on your site.
2) My browser plugin sees that I've done this.
3) It checks my email for the link from your site, returns to your site, logs me in with that secure link, and I never had to enter a password.
This feels very similar to OpenID, only I don't need to rely on a service that's a part of the OpenID movement, and my password stays with me, my domain, and my email account wherever I choose to host it.
On a lighter note, even if someone has to enter their email password each time, it won't be such a pain to most people since they already use the same password everywhere. And hopefully this will be slightly more secure than having hundreds copies of the same password scattered about the 'net on servers with varying levels/quality of security.
For the unaware, the app basically plugs in to your browser and with a "master password" recalls all your logins. I basically go to a webpage, hit the 1p button and I'm golden. If it's the start of a session, I'm asked to enter my master password and that's about it.
Obviously the service doesn't have any control of this, and I am reliant on 1password's security and the security of my password, but it's convenient. I can't see email being the only login because I'd be worried of giving my email password to anybody.
The end result is all of your accounts have a different and secure password, whereas you (the end user) only work with the single password.
I've been thinking of giving this a shot but just keep putting it off for various reasons (the long time commitment of resetting all of my passwords to the newer/safer credentials, what if I am on a machine w/o Firefox or the plugin, etc).
If the user is logging in with an email account on a domain whose email is handled by an openid provider, it will switch over to logging you in with openid.
Though I'm dubious though about their wording suggestion of "No, help me log in" for the situation where you don't need a password because you can use openid.
A combination of your idea and Google's idea: let users login with only an email address. If the email's domain supports openid, use that, otherwise send an email with a link to log the user in.