6 ms·

Identify with email: no need for passwords

46 points by sgustard 13y ago

airlinenut 13y ago
One downside (not security-related) would be the need for captchas to prevent people from being robo-spammed by repeated entry of email address into various forms. Alternatively you could rate-limit emails, I suppose.
captaincrunch 13y ago
This is essentially just two-factor using email... give me your phone and I can steal anything I need.
- aes 13y ago
  Assuming the phone isn't locked. A combination with email confirmation plus two-step verification like Google Authenticator could work as well.
  - parsnips 13y ago
    If the attacker has the phone, the second factor (typically sms) won't work very well.
refrigerator 13y ago
I'm not a fan of this idea: From a user experience point of view, it's much more effort (at least 3 clicks more) to have to open an email client, open an email, and click a link, as opposed to just entering a password. Also as airlinenut mentioned, it would allow others to send you an annoying email just by entering your email address, and any methods to prevent this (captcha etc) will just make it even harder for the user.
- greensand 13y ago
  People sending you annoying emails with this method is not really an issue as anyone that knows your email can (and does) find easy ways to annoy you (spam, phishing, chain letters etc.). I do agree however that the user experience is a deal breaker. I'd rather enter a password than open a client and wait for an email to arrive just so I can log in.
- biggfoot 13y ago
  Seconded. In fact, most if not all apps let you login upon sign-up instantly deferring the e-mail verification to anytime in the next 15 days.
quanticle 13y ago
Isn't this exactly what Mozilla Persona [1] does? EDIT: In fact, Persona goes one better. Persona has the browser act as an intermediary between your e-mail provider and the site that you're logging in to, so that the e-mail provider doesn't get to see the source of the authentication request, and the site that you're authenticating with doesn't get any further details beyond your e-mail address. [1] http://www.mozilla.org/en-US/persona/ http://www.mozilla.org/en-US/persona/
- bapi 13y ago
  Yes Persona do it. Better.
- Groxx 13y ago
  The intermediary part is a blessing and a curse. If the site you're logging into doesn't directly verify with your email provider, then if anyone gets your temporary signing token they can log in anywhere you use Persona, and you have no way to revoke it or even prevent future ones until the token expires naturally. Even if this is mere seconds, it's plenty of time for a scripted attack to try hundreds or thousands of sites[1]. This is noticeably unlike OpenID / OAuth[2] / many name/password systems, where you can revoke access to specific tokens / sites on the ID provider, and where many username/password sites reject all old cookies after you change your password. Anyone with your token / cookie / etc will immediately lose access with this, and the provider can prevent new sites from using old login info. [1]: and remember that they don't "phone home" to the Persona provider, so there can't be any rate limiting. virus -> botnet -> millions within seconds is totally possible, if unlikely and costly. [2]: yeah, OAuth ain't an ID system. same basic structure though.
  - fmarier 13y ago
    I think you might be confused with how Persona works, it's not quite like OAuth. There is no "token" in Persona, we have keys and assertions. The first step is for your browser to generate a public and secret keypair. Then you send the public key over to the identity provider to get it signed. Once it's signed, you use your secret key (which never leaves your browser) to sign an assertion. The assertion contains your signed public key and an expiration, but it's also tied to an audience (i.e. the URL of the site you're logging into). That's what you send to the site you're trying to log into. So if that site tries to impersonate you on a different website using the assertion you just gave it, it won't work because it can't change the audience that's inside the assertion (that would break the signature on the assertion). If the audience doesn't match, no other site will accept it. Of course if a site steals your secret key from localStorage, then it's game over. However if you find a way to do this, then you've got yourself a browser 0-day :)
Kequc 13y ago
Allow the user to sign in with their password, if they cannot remember their password or would rather sign in with their email then allow them to receive an email containing a token that logs them in. From their account settings they can change their password. This is already how most websites work isn't it?
- zzzcpan 13y ago
  Kind of, the only thing missing is proper user experience. Like having an input for e-mail and another button right on the login form.
drivebyacct2 13y ago
Fucking christ. How many times are people going to "reinvent" email login. Persona, mother fucker, have you heard of it?
crazygringo 13y ago
I've implemented a site before that did exactly that, because logins would be very infrequent so users were probably just forget a password anyway. It worked great. BUT, it would drive me nuts if I had to do that every time I logged into my bank, for example, because sometimes e-mails take 1-2 min to arrive, very occasionally even half an hour. They get queued up somewhere along the way, who knows -- maybe the spam filter's being overloaded. Sometimes your organization's e-mail simply goes down. Sometimes your webmail goes down. Heck, sometimes your e-mail gets inadvertently disabled. If it were instantaneous, and your e-mail account always worked perfectly, then it would be great. But the way things are set up right now... this isn't a viable option for a lot of sites. And it's certainly not going to replace your e-mail password ;)
- zzzcpan 13y ago
  It's viable. Just don't replace passwords with it, offer it as an alternative way to log in alongside.
  - georgemcbay 13y ago
    I agree and would love to see this as an option on sites where full blown 2-auth validation isn't required. I wouldn't use this feature on every site but there are some sites I use infrequently enough that virtually every time I use them I have to do an email based password reset anyway, which is often implemented in a way that makes it a very clumsy version of this system anyway (since following the reset link often gives you a valid login cookie).
- yogo 13y ago
  ...sometimes your email provider could temporarily be on some block list For the most part I consider email to be unreliable. There are simply too many things that can go wrong. I'm also amazed that there hasn't been some kind of messaging protocol to replace the damn thing (throw it on top of http even). I guess spam really ruined it for everyone.
  - betterunix 13y ago
parsnips 13y ago
How is this not identical to sending the user password in the clear via email?
- zippergz 13y ago
  For one thing, it doesn't allow someone who intercepts it to login to all the other sites the user has used that password (or password pattern) on.
- eberfreitas 13y ago
  I guess it is as good as sending an email with a link to reset a password. In theory, the link that gives you access to your account couldn't be used after X minutes and could be use only once, making it useless for future attempts.
smackfu 13y ago
Besides the problems with email delivery speeds, which tend to make this frustrating in reality, this also has the problem of being different. And users don't really want to deal with different just to log in to your site. They know userid + password, and there is no learning curve.
deleted 13y ago
[deleted]
lkbm 13y ago
> They now need not implement any cryptography. This sentence implies to me that under the current system, sites need cryptography, because sending login information in plaintext is not secure enough. ...and that the solution is to use email, because we already treat it as if it's secure. ...even though it sends the data in plaintext. Okay, so most end-users probably accesses their email via https these days, but it's a (potentially) long journey from the website to the email provider's server. Is any of that server-to-server journey ever encrypted? I'm no expert, but my impression has always been that it's not.
- prutschman 13y ago
  > Is any of that server-to-server journey ever encrypted? It can be, thanks to RFC 3207 (STARTTLS). However, unless you configure your sending MTA to require TLS (and in turn give up the ability to send email to a large swath of the internet) you have no protection against a MITM adversary hiding the recipient's advertisement of STARTTLS.
- betterunix 13y ago
  A key difference here is that the proposal is to send a short-lived login token via email. Even if this is intercepted the attacker will not be able to do much before getting caught -- the window is going to be less than a minute. After that the token is a cookie stored on the user's computer. It is also worth pointing out that a number of sites allow passwords to be reset via email, and so an attacker who can read your email can potentially gain access anyway.
eksith 13y ago
This is actually the same method we use for logins, when the cookie is absent or expired, at a forum I'm currently running. They get sent a unique login token that expires in a few minutes (or is force expired if they request a resend of the login token) and get presented a CAPTCHA after following the link if they've already tried a few times. Login email delay increases exponentially with each request.
brianwillis 13y ago
And believe it or not, some people do not use, like, or trust Facebook or Twitter. Yup, I'm one of those people. I don't use Facebook, and it's unreasonable to expect me to sign up for a Facebook account so that I can use your service. I do use Twitter, but I'd rather not share my account details (even just the username) with someone I've just met. I've always thought that being able to explore the web of information out there about me was kind of creepy, and I'm not about to make it easier for someone to do by creating connections between the accounts I have with disparate service providers. I like when my data is siloed, and only shared on my terms, with my explicit consent.
- ashray 13y ago
  Not only that but facebook may block your account at a whim. Happened to me once for posting 'explicit pictures'. The picture was not even explicit, apparently something tripped their automatic 'skin detection system'. But the result ? I couldn't log into any 'facebook connected' sites. Better to create separate accounts on each site and minimize dependencies. Also, if you lose your facebook password, it's just your facebook account that'll potentially get affected.
capex 13y ago
Sometimes there is a significant delay in Gmail sending new emails to a desktop client. That can be a dealbreaker for this.
daave 13y ago
> It would tremendously simplify for services. They now need not implement any cryptography. Uhh.. I sure hope the cookie tokens are not stored directly on the server-side, but rather verified against a (cryptographic) hash of same. These credentials are as valuable to an attacker as a password (albeit relatively short-lived).
samweinberg 13y ago
I don't know if I would trust this as the sole authentication method for any of my online accounts, but this could be useful as a multi-factor authentication method instead.
swanson 13y ago
I tried a similar approach on https://www.moraleapp.com https://www.moraleapp.com with mixed results. It makes sense for a manager/boss to have an account, but I didn't want to have every team member sign up for yet another service. So each email sent out gets a randomly generated token that allows the recipient to "log in" (all responses are anonymous, each sent email has a token - not each email address). I think the idea is really great and helps with adoption within a team, but it has also led to some confusion because there is also a traditional Login page. My take-away is that it is probably better to go all-in on one approach (all email-based or regular logins) than a half measure. It is kind of interesting because it seems to cause trouble for users that are semi-technical; the ones that know how a username/login works in general, but are thrown for a loop with this whole "email is how you login to our special app!" thing. Super technical users understand and super newbies don't really seem to notice, but those middle ground users are a bit confused.
yuliyp 13y ago
Don't most sites let you do this already? It's usually behind a button labeled "forgot password"
zeckalpha 13y ago
Emails are postcards.
fakeanon 13y ago
E.g.: http://hi-games.net/login.cgi http://hi-games.net/login.cgi
duck 13y ago
I've thought about this exact thing. Couple additional ideas - I would make it email or SMS and two, you could reduce the number of steps by using gmail actions - https://developers.google.com/gmail/actions/actions/actions-overview#go-to_actions https://developers.google.com/gmail/actions/actions/actions-...
MaxGabriel 13y ago
If you wanted to later make an iOS or android app, wouldn't you need a password since you wouldn't have the cookies?
ripvanwinkle 13y ago
This doesn't change much does it. You could have one email account in which case it becomes the single point of failure / attack and you are only as secure as that email provider. Or you have multiple email accounts in which case you have multiple email account passwords to remember manage. You might as well have multiple site passwords
vesnalorem 13y ago
http://pixelpin.co.uk/ http://pixelpin.co.uk/ ?
- drill_sarge 13y ago
  thats basically the same what windows 8 does. curious that microsoft didn't patent this in some way?
  - vesnalorem 13y ago
    PixelPin's mission is to rid the world of passwords for ever and replace them with an engaging and easy to use picture based system. They provide businesses and organisations an authentication service for their customers. The service is enabled for all web applications, and can be accessed from any user device. PixelPin replaces the current password solution which is expensive to manage and full of vulnerabilities with a very user friendly and memorable solution that uses personal pictures from the users own device as a means of authentication. The service is very secure and maintains the users privacy. Once a user has completed the simple process to set up a PixelPin account, they can then login to any PixelPin enabled web service. Info and the Dev pages at https://login.pixelpin.co.uk/Developer/Index.aspx https://login.pixelpin.co.uk/Developer/Index.aspx for tech integration info. Integration can be achieved in 2 to 4 hours. By the way Windows 8 can not do this, but PixelPin can replace Windows 7 and 8 login
brianmcconnell 13y ago
Since virtually every service has a 'forgot password' option, all the OP is suggesting is to formalize this as a default login process for second tier services that are too much of a bother to keep track of. The net positive, if this were implemented across the board, is that users would focus their efforts on securing a few high value accounts, versus reusing the same password across dozens of low value accounts (chain, meet weakest link).
alexsmolen 13y ago
I built a Rails engine that does this, see https://github.com/alsmola/nopassword https://github.com/alsmola/nopassword and https://nopassword.alexsmolen.com https://nopassword.alexsmolen.com

46 points by sgustard 13y ago

One downside (not security-related) would be the need for captchas to prevent people from being robo-spammed by repeated entry of email address into various forms. Alternatively you could rate-limit emails, I suppose.

captaincrunch 13y ago

This is essentially just two-factor using email... give me your phone and I can steal anything I need.

aes 13y ago
Assuming the phone isn't locked. A combination with email confirmation plus two-step verification like Google Authenticator could work as well.
- parsnips 13y ago
  If the attacker has the phone, the second factor (typically sms) won't work very well.

refrigerator 13y ago

I'm not a fan of this idea: From a user experience point of view, it's much more effort (at least 3 clicks more) to have to open an email client, open an email, and click a link, as opposed to just entering a password. Also as airlinenut mentioned, it would allow others to send you an annoying email just by entering your email address, and any methods to prevent this (captcha etc) will just make it even harder for the user.

greensand 13y ago
People sending you annoying emails with this method is not really an issue as anyone that knows your email can (and does) find easy ways to annoy you (spam, phishing, chain letters etc.). I do agree however that the user experience is a deal breaker. I'd rather enter a password than open a client and wait for an email to arrive just so I can log in.
biggfoot 13y ago
Seconded. In fact, most if not all apps let you login upon sign-up instantly deferring the e-mail verification to anytime in the next 15 days.

quanticle 13y ago

Isn't this exactly what Mozilla Persona [1] does? EDIT: In fact, Persona goes one better. Persona has the browser act as an intermediary between your e-mail provider and the site that you're logging in to, so that the e-mail provider doesn't get to see the source of the authentication request, and the site that you're authenticating with doesn't get any further details beyond your e-mail address. [1] http://www.mozilla.org/en-US/persona/ http://www.mozilla.org/en-US/persona/

bapi 13y ago
Yes Persona do it. Better.
Groxx 13y ago
The intermediary part is a blessing and a curse. If the site you're logging into doesn't directly verify with your email provider, then if anyone gets your temporary signing token they can log in anywhere you use Persona, and you have no way to revoke it or even prevent future ones until the token expires naturally. Even if this is mere seconds, it's plenty of time for a scripted attack to try hundreds or thousands of sites[1]. This is noticeably unlike OpenID / OAuth[2] / many name/password systems, where you can revoke access to specific tokens / sites on the ID provider, and where many username/password sites reject all old cookies after you change your password. Anyone with your token / cookie / etc will immediately lose access with this, and the provider can prevent new sites from using old login info. [1]: and remember that they don't "phone home" to the Persona provider, so there can't be any rate limiting. virus -> botnet -> millions within seconds is totally possible, if unlikely and costly. [2]: yeah, OAuth ain't an ID system. same basic structure though.
- fmarier 13y ago
  I think you might be confused with how Persona works, it's not quite like OAuth. There is no "token" in Persona, we have keys and assertions. The first step is for your browser to generate a public and secret keypair. Then you send the public key over to the identity provider to get it signed. Once it's signed, you use your secret key (which never leaves your browser) to sign an assertion. The assertion contains your signed public key and an expiration, but it's also tied to an audience (i.e. the URL of the site you're logging into). That's what you send to the site you're trying to log into. So if that site tries to impersonate you on a different website using the assertion you just gave it, it won't work because it can't change the audience that's inside the assertion (that would break the signature on the assertion). If the audience doesn't match, no other site will accept it. Of course if a site steals your secret key from localStorage, then it's game over. However if you find a way to do this, then you've got yourself a browser 0-day :)

Kequc 13y ago

Allow the user to sign in with their password, if they cannot remember their password or would rather sign in with their email then allow them to receive an email containing a token that logs them in. From their account settings they can change their password. This is already how most websites work isn't it?

zzzcpan 13y ago
Kind of, the only thing missing is proper user experience. Like having an input for e-mail and another button right on the login form.

drivebyacct2 13y ago

Fucking christ. How many times are people going to "reinvent" email login. Persona, mother fucker, have you heard of it?

crazygringo 13y ago

I've implemented a site before that did exactly that, because logins would be very infrequent so users were probably just forget a password anyway. It worked great. BUT, it would drive me nuts if I had to do that every time I logged into my bank, for example, because sometimes e-mails take 1-2 min to arrive, very occasionally even half an hour. They get queued up somewhere along the way, who knows -- maybe the spam filter's being overloaded. Sometimes your organization's e-mail simply goes down. Sometimes your webmail goes down. Heck, sometimes your e-mail gets inadvertently disabled. If it were instantaneous, and your e-mail account always worked perfectly, then it would be great. But the way things are set up right now... this isn't a viable option for a lot of sites. And it's certainly not going to replace your e-mail password ;)

zzzcpan 13y ago
It's viable. Just don't replace passwords with it, offer it as an alternative way to log in alongside.
- georgemcbay 13y ago
  I agree and would love to see this as an option on sites where full blown 2-auth validation isn't required. I wouldn't use this feature on every site but there are some sites I use infrequently enough that virtually every time I use them I have to do an email based password reset anyway, which is often implemented in a way that makes it a very clumsy version of this system anyway (since following the reset link often gives you a valid login cookie).
yogo 13y ago
...sometimes your email provider could temporarily be on some block list For the most part I consider email to be unreliable. There are simply too many things that can go wrong. I'm also amazed that there hasn't been some kind of messaging protocol to replace the damn thing (throw it on top of http even). I guess spam really ruined it for everyone.
- betterunix 13y ago

parsnips 13y ago

How is this not identical to sending the user password in the clear via email?

zippergz 13y ago
For one thing, it doesn't allow someone who intercepts it to login to all the other sites the user has used that password (or password pattern) on.
eberfreitas 13y ago
I guess it is as good as sending an email with a link to reset a password. In theory, the link that gives you access to your account couldn't be used after X minutes and could be use only once, making it useless for future attempts.

smackfu 13y ago

Besides the problems with email delivery speeds, which tend to make this frustrating in reality, this also has the problem of being different. And users don't really want to deal with different just to log in to your site. They know userid + password, and there is no learning curve.

deleted 13y ago

[deleted]

lkbm 13y ago

> They now need not implement any cryptography. This sentence implies to me that under the current system, sites need cryptography, because sending login information in plaintext is not secure enough. ...and that the solution is to use email, because we already treat it as if it's secure. ...even though it sends the data in plaintext. Okay, so most end-users probably accesses their email via https these days, but it's a (potentially) long journey from the website to the email provider's server. Is any of that server-to-server journey ever encrypted? I'm no expert, but my impression has always been that it's not.

prutschman 13y ago
> Is any of that server-to-server journey ever encrypted? It can be, thanks to RFC 3207 (STARTTLS). However, unless you configure your sending MTA to require TLS (and in turn give up the ability to send email to a large swath of the internet) you have no protection against a MITM adversary hiding the recipient's advertisement of STARTTLS.
betterunix 13y ago
A key difference here is that the proposal is to send a short-lived login token via email. Even if this is intercepted the attacker will not be able to do much before getting caught -- the window is going to be less than a minute. After that the token is a cookie stored on the user's computer. It is also worth pointing out that a number of sites allow passwords to be reset via email, and so an attacker who can read your email can potentially gain access anyway.

eksith 13y ago

This is actually the same method we use for logins, when the cookie is absent or expired, at a forum I'm currently running. They get sent a unique login token that expires in a few minutes (or is force expired if they request a resend of the login token) and get presented a CAPTCHA after following the link if they've already tried a few times. Login email delay increases exponentially with each request.

brianwillis 13y ago

And believe it or not, some people do not use, like, or trust Facebook or Twitter. Yup, I'm one of those people. I don't use Facebook, and it's unreasonable to expect me to sign up for a Facebook account so that I can use your service. I do use Twitter, but I'd rather not share my account details (even just the username) with someone I've just met. I've always thought that being able to explore the web of information out there about me was kind of creepy, and I'm not about to make it easier for someone to do by creating connections between the accounts I have with disparate service providers. I like when my data is siloed, and only shared on my terms, with my explicit consent.

ashray 13y ago
Not only that but facebook may block your account at a whim. Happened to me once for posting 'explicit pictures'. The picture was not even explicit, apparently something tripped their automatic 'skin detection system'. But the result ? I couldn't log into any 'facebook connected' sites. Better to create separate accounts on each site and minimize dependencies. Also, if you lose your facebook password, it's just your facebook account that'll potentially get affected.

capex 13y ago

Sometimes there is a significant delay in Gmail sending new emails to a desktop client. That can be a dealbreaker for this.

daave 13y ago

> It would tremendously simplify for services. They now need not implement any cryptography. Uhh.. I sure hope the cookie tokens are not stored directly on the server-side, but rather verified against a (cryptographic) hash of same. These credentials are as valuable to an attacker as a password (albeit relatively short-lived).

samweinberg 13y ago

I don't know if I would trust this as the sole authentication method for any of my online accounts, but this could be useful as a multi-factor authentication method instead.

swanson 13y ago

I tried a similar approach on https://www.moraleapp.com https://www.moraleapp.com with mixed results. It makes sense for a manager/boss to have an account, but I didn't want to have every team member sign up for yet another service. So each email sent out gets a randomly generated token that allows the recipient to "log in" (all responses are anonymous, each sent email has a token - not each email address). I think the idea is really great and helps with adoption within a team, but it has also led to some confusion because there is also a traditional Login page. My take-away is that it is probably better to go all-in on one approach (all email-based or regular logins) than a half measure. It is kind of interesting because it seems to cause trouble for users that are semi-technical; the ones that know how a username/login works in general, but are thrown for a loop with this whole "email is how you login to our special app!" thing. Super technical users understand and super newbies don't really seem to notice, but those middle ground users are a bit confused.

yuliyp 13y ago

Don't most sites let you do this already? It's usually behind a button labeled "forgot password"

zeckalpha 13y ago

Emails are postcards.

fakeanon 13y ago

E.g.: http://hi-games.net/login.cgi http://hi-games.net/login.cgi

duck 13y ago

I've thought about this exact thing. Couple additional ideas - I would make it email or SMS and two, you could reduce the number of steps by using gmail actions - https://developers.google.com/gmail/actions/actions/actions-overview#go-to_actions https://developers.google.com/gmail/actions/actions/actions-...

MaxGabriel 13y ago

If you wanted to later make an iOS or android app, wouldn't you need a password since you wouldn't have the cookies?

ripvanwinkle 13y ago

This doesn't change much does it. You could have one email account in which case it becomes the single point of failure / attack and you are only as secure as that email provider. Or you have multiple email accounts in which case you have multiple email account passwords to remember manage. You might as well have multiple site passwords

vesnalorem 13y ago

http://pixelpin.co.uk/ http://pixelpin.co.uk/ ?

drill_sarge 13y ago
thats basically the same what windows 8 does. curious that microsoft didn't patent this in some way?
- vesnalorem 13y ago
  PixelPin's mission is to rid the world of passwords for ever and replace them with an engaging and easy to use picture based system. They provide businesses and organisations an authentication service for their customers. The service is enabled for all web applications, and can be accessed from any user device. PixelPin replaces the current password solution which is expensive to manage and full of vulnerabilities with a very user friendly and memorable solution that uses personal pictures from the users own device as a means of authentication. The service is very secure and maintains the users privacy. Once a user has completed the simple process to set up a PixelPin account, they can then login to any PixelPin enabled web service. Info and the Dev pages at https://login.pixelpin.co.uk/Developer/Index.aspx https://login.pixelpin.co.uk/Developer/Index.aspx for tech integration info. Integration can be achieved in 2 to 4 hours. By the way Windows 8 can not do this, but PixelPin can replace Windows 7 and 8 login

brianmcconnell 13y ago

Since virtually every service has a 'forgot password' option, all the OP is suggesting is to formalize this as a default login process for second tier services that are too much of a bother to keep track of. The net positive, if this were implemented across the board, is that users would focus their efforts on securing a few high value accounts, versus reusing the same password across dozens of low value accounts (chain, meet weakest link).

alexsmolen 13y ago

I built a Rails engine that does this, see https://github.com/alsmola/nopassword https://github.com/alsmola/nopassword and https://nopassword.alexsmolen.com https://nopassword.alexsmolen.com