5 ms·

> I don't want to impose that privacy failure on my users, but I also don't want to impose the annoyance that is "Sign up with a username, email address, and pa

by wtbob 11y ago

> I don't want to impose that privacy failure on my users, but I also don't want to impose the annoyance that is "Sign up with a username, email address, and password". Why not just 'log in with email address'? The user provides his email address; you send him an email with a URL of the form http://www.invalid/path/to/resource?access_token=aSBkb25lIGF1dGhlbnRpY2F0ZWQgdGhpcw http://www.invalid/path/to/resource?access_token=aSBkb25lIGF... (where aSBkb25lIGF1dGhlbnRpY2F0ZWQgdGhpcw is a cryptographically-authenticated account identifier). When he follows the URL, you can set a cookie if you want him to be automatically logged in next time he visits your site, or not if you don't. Extending this to be one-time only (to prevent replay by an email provider) is an exercise for the reader.

agentdrtran 11y ago
Medium does this, but I'm not a fan because it takes longer than just using a username/password generated with LastPass.
sz4kerto 11y ago
However, this method can't really be used everywhere -- not all emails are encrypted up to the point where the recipient reads them.
- wtbob 11y ago
  > However, this method can't really be used everywhere — not all emails are encrypted up to the point where the recipient reads them. Neither are password-reset emails… This is no more or less secure than sending password-reset emails; any additional security intended to protect in the case of password resets can be applied to login as well (e.g. SMS or landline contact, knowledge of shared secrets of varying security).
debaserab2 11y ago
This is essentially the same thing as having your password emailed to you and is insecure for all the same reasons. Youre putting the responsibility of security on the email provider, which you can't control.
- cpeterso 11y ago
  The emailed login link is a short-lived, one-time password and can be associated with a cookie already set on the website's "send me a login email" page.
- wtbob 11y ago
  > This is essentially the same thing as having your password emailed to you and is insecure for all the same reasons. No, it's essentially the same thing as having a password-reset email sent to one, which is already the case for just about any account anyway. > You're putting the responsibility of security on the email provider, which you can't control. Your email provider is already capable of visiting a site, claiming to be you & claiming to have forgotten your password, then intercepting the password-reset email and resetting your password (about the only sites which require more than this are banks). You can extend any flow which is secure against an evil email provider resetting a password to be equally secure against an evil email provider logging in. Obviously you could add an SMS code, which would then require subverting your mobile provider as well as your email; ditto a landline call.
  - deleted 11y ago
    [deleted]
SwellJoe 11y ago
"Why not just...?" I enjoy that you offer up a quite complex, confusing, often insecure, and error-prone methodology with this phrase.
- wtbob 11y ago
  How is sending a user an email complex, confusing or error-prone? As for security, given that an account can already be accessed if one has access to the holder's email (which is the case for any password reset flow relying on email), this is no more insecure than the current state. Seriously, this sort of thing is not complex, not at all.
  - SwellJoe 11y ago
    Complex situations: - I'm logging in from a new computer. Maybe a computer I don't trust enough to log in to my email (which controls nearly everything, as you note). Not all services are that important or need the same level of care as email. - I'm a user that has greylisting enabled on my mail server, potentially delaying the email for several minutes. Confusing: - I'm a user that has never seen/used this authentication workflow. While user/pass is annoying, it is widely understood. Sometimes "ease of use" is really just "what I'm used to". Thanks to facebook and Google authentication, the "Login with..." button is now "what I'm used to". I've never seen the authentication method you've described in 20 years of web use, except as a password reset method. Error-prone: - Implementation would have to be done by me on all of my sites. There is no off-the-shelf plugin for this for Drupal or Wordpress or Mediawiki, which run 90% of the websites I am responsible for. I could develop it but I am certain I would make mistakes in said implementation. I should be clear that I think any form of authentication is error-prone, unless it's already written and well-tested. User/pass and optional email is already written and well-tested for every site I maintain. Security: - It forces login to email to login to your site. This increases the risk of a user logging in from an untrusted computer or in an untrusted location to an incredible degree. - Also, one can easily add security questions, or other second factor, to a password reset form, to make it more secure than your solution. Password resets are rare; happening every year or two, most likely. Logins are daily. One cannot impose those security questions on daily login form without paying the same annoyance price as user/pass (higher because it is unfamiliar). Cookies can mitigate this somewhat, but it doesn't solve multiple devices, and security-conscious environments that don't maintain cookies on logout. If you believe this is an acceptable workflow for authentication, I won't try to stop you. But, it simply isn't a solution for my sites. I don't like user/pass, and I want something better, but I don't believe what you've described is something better. It's a neat idea, but not a solution to logins.

by wtbob 11y ago

agentdrtran 11y ago

Medium does this, but I'm not a fan because it takes longer than just using a username/password generated with LastPass.

sz4kerto 11y ago

However, this method can't really be used everywhere -- not all emails are encrypted up to the point where the recipient reads them.

wtbob 11y ago
> However, this method can't really be used everywhere — not all emails are encrypted up to the point where the recipient reads them. Neither are password-reset emails… This is no more or less secure than sending password-reset emails; any additional security intended to protect in the case of password resets can be applied to login as well (e.g. SMS or landline contact, knowledge of shared secrets of varying security).

debaserab2 11y ago

This is essentially the same thing as having your password emailed to you and is insecure for all the same reasons. Youre putting the responsibility of security on the email provider, which you can't control.

cpeterso 11y ago
The emailed login link is a short-lived, one-time password and can be associated with a cookie already set on the website's "send me a login email" page.
wtbob 11y ago
> This is essentially the same thing as having your password emailed to you and is insecure for all the same reasons. No, it's essentially the same thing as having a password-reset email sent to one, which is already the case for just about any account anyway. > You're putting the responsibility of security on the email provider, which you can't control. Your email provider is already capable of visiting a site, claiming to be you & claiming to have forgotten your password, then intercepting the password-reset email and resetting your password (about the only sites which require more than this are banks). You can extend any flow which is secure against an evil email provider resetting a password to be equally secure against an evil email provider logging in. Obviously you could add an SMS code, which would then require subverting your mobile provider as well as your email; ditto a landline call.
- deleted 11y ago
  [deleted]

SwellJoe 11y ago

"Why not just...?" I enjoy that you offer up a quite complex, confusing, often insecure, and error-prone methodology with this phrase.

wtbob 11y ago
How is sending a user an email complex, confusing or error-prone? As for security, given that an account can already be accessed if one has access to the holder's email (which is the case for any password reset flow relying on email), this is no more insecure than the current state. Seriously, this sort of thing is not complex, not at all.
- SwellJoe 11y ago
  Complex situations: - I'm logging in from a new computer. Maybe a computer I don't trust enough to log in to my email (which controls nearly everything, as you note). Not all services are that important or need the same level of care as email. - I'm a user that has greylisting enabled on my mail server, potentially delaying the email for several minutes. Confusing: - I'm a user that has never seen/used this authentication workflow. While user/pass is annoying, it is widely understood. Sometimes "ease of use" is really just "what I'm used to". Thanks to facebook and Google authentication, the "Login with..." button is now "what I'm used to". I've never seen the authentication method you've described in 20 years of web use, except as a password reset method. Error-prone: - Implementation would have to be done by me on all of my sites. There is no off-the-shelf plugin for this for Drupal or Wordpress or Mediawiki, which run 90% of the websites I am responsible for. I could develop it but I am certain I would make mistakes in said implementation. I should be clear that I think any form of authentication is error-prone, unless it's already written and well-tested. User/pass and optional email is already written and well-tested for every site I maintain. Security: - It forces login to email to login to your site. This increases the risk of a user logging in from an untrusted computer or in an untrusted location to an incredible degree. - Also, one can easily add security questions, or other second factor, to a password reset form, to make it more secure than your solution. Password resets are rare; happening every year or two, most likely. Logins are daily. One cannot impose those security questions on daily login form without paying the same annoyance price as user/pass (higher because it is unfamiliar). Cookies can mitigate this somewhat, but it doesn't solve multiple devices, and security-conscious environments that don't maintain cookies on logout. If you believe this is an acceptable workflow for authentication, I won't try to stop you. But, it simply isn't a solution for my sites. I don't like user/pass, and I want something better, but I don't believe what you've described is something better. It's a neat idea, but not a solution to logins.