5 ms·

Emailing a single-use "sign in link" to a user (Slack calls these "Magic Links") is the way forward. Yes, it move the single point of failure to the user's emai

by grrowl 10y ago

Emailing a single-use "sign in link" to a user (Slack calls these "Magic Links") is the way forward. Yes, it move the single point of failure to the user's email account, but expecting the regular user to use (and remember) unique passwords for each service is impossible -- they simply won't do it. Plus, when/if your service is breached, you won't compromise all their other accounts as well.

jcrites 10y ago
It's really a shame that we haven't solved this problem yet as an industry. I was thinking we could build a general purpose version of "Magic Links" for logging in, where the format of the email is well-defined, and the user's browser is able to receive these messages on their behalf through some form of integration. You could imagine a webmail provider offering some kind of polling or websocket API for listening for when these messages arrive. When the site they're visiting indicates through its web page that, "I'm trying to authenticate you by email", then the browser can fetch recent incoming messages of this type, then parse them and display UI chrome like "Xyz.example.com wants to authenticate you". You click a button to log in passwordlessly, which involves sending an HTTP request to a link specified in the email. Coordination occurs on the server side and the login is allowed. There are probably some details I'm not considering, but it doesn't seem like it'd be too hard to build a prototype, and if standardized and deployed it would eliminate the need for passwords. I gather that Mozilla Persona works along similar lines, though I confess to not knowing the exact details. There would be practical difficulties integrating all of these things together, though: email, browser, and website login, and gaining adoption in the real world. There are also sites that don't require email on signup, but this feature could be supported only for people who want to supply email. The email address used for this feature could also be a different technical address unrelated to the primary mailbox, where only login requests are sent. This could also help expedite the email traffic to ensure it's real-time. The browser could automatically fill in the email address when challenged by a website supporting this login method. Alternatively, perhaps a browser vendor could introduce a de facto standard where sites can integrate via an API with the browser's password safe features. Chrome can save passwords and synchronize them across devices. Maybe it wouldn't be too hard for sites to comply with a microformat that helps the browser understand when to generate a password on signup, and when to provide it, etc.
- kodfodrasz 10y ago
  You seem obsessed with one implementation. Passwords themselves are obsolete. Actually the problem is already solved for at least a decade: Certificate based authentication. Browsers support it. Try StartSSl registration, for example.
  - bigiain 10y ago
    Yeah - but that's like saying "email security and integrity has been solved for two decades", while _technically_ true, how many of you have talked your mom through setting up PGP and had her then "just use it"? (or tried to handhold a less-than-technical colleague through getting a StartSSL account?) I'm pretty sure if any service less-technical than a CA authority starts pushing wide-spread user-driven in-browser certificate-based authentication, within days there'll be scammers and phishers faking the setup process to install untrustworthy ssl root certs so they can mitm Paypal/Facebook/everybody... How would _you_ explain to your mom the difference between installing Pinterest's new authentication certificate, and installing, say, the Charles Proxy ssl MITM cert?
    - drdaeman 10y ago
      > How would _you_ explain to your mom the difference between installing Pinterest's new authentication certificate Actually, even with current terrible UIs, there's a reasonably big difference between installing client certificate (there even used to be a <keygen> HTML tag for those - although it's unsurprisingly marked as "deprecated" now) and trusted CAs.
    - theandrewbailey 10y ago
      > (or tried to handhold a less-than-technical colleague through getting a StartSSL account?) I tried getting one myself a few years ago, and I couldn't. The process was too obtuse and obscure for me to follow along the entire way.
  - drdaeman 10y ago
    Sadly, it's only theoretically solved. Browser vendors have refused to touch that for years, so everything PKI-related has a cryptic UI hidden beneath 3+ clicks deep in the most obscure settings dialog areas. And some pieces are completely missing, like session state management (it's just like with HTTP auth - there are hacks to implement it, but they're hacks). Another issue is, with current implementations not really fancying the idea of CA-less self-signed client certificates, so you'll most probably need a certificate-per-site approach. And with a ton of certificates (even if they all for the same public key), you'll need to automatically sync them to another devices somehow. (The usual reasoning for not doing anything I saw was "no one uses this". Sure thing, given it's barely usable.)
camtarn 10y ago
It's worth pointing out that in this particular case, some people will have created their Last.fm accounts more or less solely for use with Audioscrobbler, a protocol which allows them to track music listens through various third-party music players. The important bit about that is that the Last.fm/Audioscrobbler account credentials get typed directly into the third-party players - usually there's no browser involved in authentication, and in some cases the players will also be on a mobile device. There's a definite incentive for passwords to be simple (if you're going to type them in on a mobile keyboard) and weak (because it's just music metadata). So, a 'magic link' style of logging in might work here, but it would have to be complemented by an easy way of generating auth tokens for player apps - for instance, short one-time-use codes that expire quickly.
- flushandforget 10y ago
  I wrote a simple web app to work with last.fm's api. A little fiddly, but in essense it worked. Somewhere buried in settings were all the apps that have access to my account. I then went back to Spotify and noticed it wanted my username and password. And ever since, I just haven't been bothered. I'd rather some throwaway autogenerated app linking passwords and authenticating consistency. Copying and pasting links isn't that hard. Go to last.fm, generate OTP token/link, paste into Spotify. Done. I should have some easy way to identify authenticated apps under my account and kick them out, or reset all. Not all of us use Web mail. And I might not want a link automagically opened there and then, under a browser.
wepple 10y ago
> Yes, it move the single point of failure to the user's email account This isn't even that greater of a concern; it currently is in 99% of cases the method for password reset anyhow.
Nadya 10y ago
>Yes, it move the single point of failure to the user's email account That is already the case for the supermajority of people. They use one email account for everything and you can simply "Recover Password" on various services once you gain access to their email account. Not many people purposefully use unique, individual email addresses for every single service they sign up for...
- ryan-c 10y ago
  > Not many people purposefully use unique, individual email addresses for every single service they sign up for... When they do, generally email for all of them ends up in the same account anyway.
discordance 10y ago
If you're going to recommend emailed 'magic links', then might as well use Google/Facebook/etc as an SSO indentity provider

by grrowl 10y ago

jcrites 10y ago

It's really a shame that we haven't solved this problem yet as an industry. I was thinking we could build a general purpose version of "Magic Links" for logging in, where the format of the email is well-defined, and the user's browser is able to receive these messages on their behalf through some form of integration. You could imagine a webmail provider offering some kind of polling or websocket API for listening for when these messages arrive. When the site they're visiting indicates through its web page that, "I'm trying to authenticate you by email", then the browser can fetch recent incoming messages of this type, then parse them and display UI chrome like "Xyz.example.com wants to authenticate you". You click a button to log in passwordlessly, which involves sending an HTTP request to a link specified in the email. Coordination occurs on the server side and the login is allowed. There are probably some details I'm not considering, but it doesn't seem like it'd be too hard to build a prototype, and if standardized and deployed it would eliminate the need for passwords. I gather that Mozilla Persona works along similar lines, though I confess to not knowing the exact details. There would be practical difficulties integrating all of these things together, though: email, browser, and website login, and gaining adoption in the real world. There are also sites that don't require email on signup, but this feature could be supported only for people who want to supply email. The email address used for this feature could also be a different technical address unrelated to the primary mailbox, where only login requests are sent. This could also help expedite the email traffic to ensure it's real-time. The browser could automatically fill in the email address when challenged by a website supporting this login method. Alternatively, perhaps a browser vendor could introduce a de facto standard where sites can integrate via an API with the browser's password safe features. Chrome can save passwords and synchronize them across devices. Maybe it wouldn't be too hard for sites to comply with a microformat that helps the browser understand when to generate a password on signup, and when to provide it, etc.

kodfodrasz 10y ago
You seem obsessed with one implementation. Passwords themselves are obsolete. Actually the problem is already solved for at least a decade: Certificate based authentication. Browsers support it. Try StartSSl registration, for example.
- bigiain 10y ago
  Yeah - but that's like saying "email security and integrity has been solved for two decades", while _technically_ true, how many of you have talked your mom through setting up PGP and had her then "just use it"? (or tried to handhold a less-than-technical colleague through getting a StartSSL account?) I'm pretty sure if any service less-technical than a CA authority starts pushing wide-spread user-driven in-browser certificate-based authentication, within days there'll be scammers and phishers faking the setup process to install untrustworthy ssl root certs so they can mitm Paypal/Facebook/everybody... How would _you_ explain to your mom the difference between installing Pinterest's new authentication certificate, and installing, say, the Charles Proxy ssl MITM cert?
  - drdaeman 10y ago
    > How would _you_ explain to your mom the difference between installing Pinterest's new authentication certificate Actually, even with current terrible UIs, there's a reasonably big difference between installing client certificate (there even used to be a <keygen> HTML tag for those - although it's unsurprisingly marked as "deprecated" now) and trusted CAs.
  - theandrewbailey 10y ago
    > (or tried to handhold a less-than-technical colleague through getting a StartSSL account?) I tried getting one myself a few years ago, and I couldn't. The process was too obtuse and obscure for me to follow along the entire way.
- drdaeman 10y ago
  Sadly, it's only theoretically solved. Browser vendors have refused to touch that for years, so everything PKI-related has a cryptic UI hidden beneath 3+ clicks deep in the most obscure settings dialog areas. And some pieces are completely missing, like session state management (it's just like with HTTP auth - there are hacks to implement it, but they're hacks). Another issue is, with current implementations not really fancying the idea of CA-less self-signed client certificates, so you'll most probably need a certificate-per-site approach. And with a ton of certificates (even if they all for the same public key), you'll need to automatically sync them to another devices somehow. (The usual reasoning for not doing anything I saw was "no one uses this". Sure thing, given it's barely usable.)

camtarn 10y ago

It's worth pointing out that in this particular case, some people will have created their Last.fm accounts more or less solely for use with Audioscrobbler, a protocol which allows them to track music listens through various third-party music players. The important bit about that is that the Last.fm/Audioscrobbler account credentials get typed directly into the third-party players - usually there's no browser involved in authentication, and in some cases the players will also be on a mobile device. There's a definite incentive for passwords to be simple (if you're going to type them in on a mobile keyboard) and weak (because it's just music metadata). So, a 'magic link' style of logging in might work here, but it would have to be complemented by an easy way of generating auth tokens for player apps - for instance, short one-time-use codes that expire quickly.

flushandforget 10y ago
I wrote a simple web app to work with last.fm's api. A little fiddly, but in essense it worked. Somewhere buried in settings were all the apps that have access to my account. I then went back to Spotify and noticed it wanted my username and password. And ever since, I just haven't been bothered. I'd rather some throwaway autogenerated app linking passwords and authenticating consistency. Copying and pasting links isn't that hard. Go to last.fm, generate OTP token/link, paste into Spotify. Done. I should have some easy way to identify authenticated apps under my account and kick them out, or reset all. Not all of us use Web mail. And I might not want a link automagically opened there and then, under a browser.

wepple 10y ago

> Yes, it move the single point of failure to the user's email account This isn't even that greater of a concern; it currently is in 99% of cases the method for password reset anyhow.

Nadya 10y ago

>Yes, it move the single point of failure to the user's email account That is already the case for the supermajority of people. They use one email account for everything and you can simply "Recover Password" on various services once you gain access to their email account. Not many people purposefully use unique, individual email addresses for every single service they sign up for...

ryan-c 10y ago
> Not many people purposefully use unique, individual email addresses for every single service they sign up for... When they do, generally email for all of them ends up in the same account anyway.

discordance 10y ago

If you're going to recommend emailed 'magic links', then might as well use Google/Facebook/etc as an SSO indentity provider