Ask HN: Why not log into web sites via email without any password?
15 comments
Because you don't want your sysadmin logging into your favorite dating site as you?
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'.)
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'.)
Well, the sysadmin could click on "restore password" on that super-secret site they want to steal your password to, and then check your mailbox. So this is really no different in terms of security.
Also, I'm sure I have a dozen restore password emails in GMail somewhere. And I'm sure I'm not alone.
Also, I'm sure I have a dozen restore password emails in GMail somewhere. And I'm sure I'm not alone.
Generally, password reset links will have a timeout associated with them. Also, if someone does manage to use the password reset link in your mailbox and reset the password before it expires, you will come to know that your password is not working anymore, and you can act on it. It's not same as someone silently logging into your account through your email. This doesn't in anyway mean that it's safe to send password reset links to your mailbox if it's already compromised, though.
> I'm sure I have a dozen restore password emails in GMail somewhere
Maybe that should be the next Google Labs feature. The 'Mission Impossible' option. (i.e. 'this message will self-destruct')
Maybe that should be the next Google Labs feature. The 'Mission Impossible' option. (i.e. 'this message will self-destruct')
How come people are not upset that the "forgot password" protocol is not secure?
Dating sites is an interesting example because OK Cupid does exactly this. They send occasional emails with a "Login Instantly" button which contain an authentication token.
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?
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?
> 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.
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?
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?
You could theoretically make an OpenID provider that does that, I think... rather than redirecting users to a website to enter your password, it just shoots an e-mail for you to confirm.
If you take this idea and strip out the silly email part, you have the core idea behind OpenID.
The difference between this idea and OpenID is that real people actually know their email address, but not "that thing with all the squigglies in it, you know, the email address for Google".
I really, really wish the OpenID standard had used email addresses as the identifier.
I really, really wish the OpenID standard had used email addresses as the identifier.
The problem is then verifying that that email address _is_ you.
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?
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?
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.
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.
That won't work for ISPs, will it? My email address shares a domain with hundreds of other users, and I don't think my ISP will care or want to maintain a "well known url" listing those users that want to use OpenID.
So, something like:
http://brad.livejournal.com/2357444.html
we sort of did this with Ramamia. ACtually in the first version, there were NO passwords. You would create a family, then register your email to it. From that point on, the cookie kept you logged in or you clicked the email login link. People liked it, but enough also wanted passwords that we added them soon thereafter. The real takeaways were:
* 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.
* 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.
It could be done, and pretty easily too.
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.
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.
Another problem in my mind is that we have a dependency created between me being able to access a particular email account and me being able to access the website I want to get into. That is, what if I originally signed up with my [email protected] address, but I'm at work, my work blocks the webmail interface that would have allowed me to access my [email protected] account and now I can't login to the website I really wanted to get to either.
This topic has been up for a whole hour and no comment from tptacek? What's going on??
This topic has been up for a whole hour and no comment from tptacek? What's going on??
If you mean logging in via clicking a link in an email then it is too much of a security risk. Think of all the places that URL can end up in: browser history, bookmarks, etc.
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).
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).
The URL would be different every time.
Realistically, browsers aren't going to implement this, whether it's a good idea or not.
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.
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.
I like the direction you are going.
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.
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.
Ok, but now your email password is the password to all your accounts. I know that in reality it already is since your email is used to reset the password for most accounts, but consider this: to fully automate the process, you'll have to give your browser (or plugin) your email password to store so that it can log you into the site without entering any password.
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.
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.
Google has an interesting hybrid approach: http://sites.google.com/site/oauthgoog/UXFedLogin
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.
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.
Actually, 1Password, a Mac-only app (I think) that I use reminded me of this.
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.
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.
There's a similar plugin for Firefox that accepts a "master password" salts, randomizes, hashes, performs magic, and submits that as the actual password to your service.
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).
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).
In some cases why do we use a password at all. There are many times that I register to a site to download something (a pdf in scribd, a sdk in nokia) or to see a post or a link, in any of this cases I dont care if anyone wants to log in with my username and what are the chances that someone will log in with my username just to change my age or my sex... oh no... I'd rather be exposed to that than remembering another password.
I suspect one strong reason against is because it would require you to be near your email client, or to use a webmail service for all online logins. Currently that requirement applies only when you register or forget your password. If your address is a company one, without web access, you won't be able to access any of your online resources.
What about the browser automating the procedure to openid?
What about the browser automating the procedure to openid?
He's saying the browser would automate the process. Presumably it would speak POP/IMAP and poll your INBOX. Some immediate technical issues here:
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]
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]
1) Sure, but the browser has to know your password for pop, etc, or you have to type it in, saving nothing. If it does know, then you're stuck at your own browser or you have to teach some new browser where your mail server is, and put in a 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 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'm trying to understand what you're asking.
Are 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?
Are 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?
The browser would be more involved in the log in process.
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.
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.
I still don't understand, you want to store passwords/logins in email accounts and have the browser fetch them?
You only use a single password for your email account (e.g., on gmail). There would be no passwords associated with other sites.
Why not just have the browser remember your password? Much easier to automate --- none of that messing around with pop/imap.
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.