6 ms·

It Is Time for Passwordless Login (2015)

44 points by atomical 11y ago

jessaustin 11y ago
I wrote a Koa middleware that I've found handy for this: https://www.npmjs.com/package/koa-signed-url https://www.npmjs.com/package/koa-signed-url It introduces the idea of a "signed URL", which can be verified or rejected based on checking a signature query parameter. You can send such a signed URL via email, text message, etc.
d0lph 11y ago
This seems to make urls themselves passwords, and your email a password safe.
- elcapitan 11y ago
  True, but arguably whoever can access your email could just as well use password reset functionality for a given site you are using. The generated url-login-tokens on the other hand will be long random strings and harder to impossible to crack.
- WorldMaker 11y ago
  These are one-time use tokens, just like you should use for a "Forgot Your Password" email login. It's literally the same steps, just there's no new password to input, the website just gives you a login cookie and you can go about your day.
  - mattashii 11y ago
    The point is that the most commonly used e-mail protocols do not have safety built in. The solutions for this problem (e.g. PGP signing) are not adapted widely enough to be considered adapted by the market. If you'd want to use two-factor authentication by verifying access to the mailbox, you have to make sure that that (the connection to) the mail box is safe as well, which can potentially be very hard. The mailbox still is a safe, but only from the moment that the mail has been sent to the moment the page has been requested. Mind that a safe connection to your mailbox does not also mean a safe connection to the server, but that is something that is covered by https+certificates (mostly).
    - WorldMaker 11y ago
      This is no worse a security footprint than the existing, requisite "Forgot Your Password" flow. It's the exact same security footprint. TLS is already an under-spoken requisite of SMTP communications from any webserver doing "Forgot Your Password" workflows. TLS between mail servers is also already a de facto SMTP requirement for most bare minimum spam fighting mechanisms.
      - mgreg 11y ago
        True that the password reset and the "login" using this proposal travel the same path and present the same attack vector but there is some disadvantage to the frequency in which the "login" system would travel down this less-than-secure path. The more times you use this the more likely that someone will just happen to be watching and waiting at the right time. Let's not forget that most of the email system is still not encrypted (last time I checked anyway) even though the last mile between your mail server and your client may be.
        WorldMaker 11y ago
        Frequency is also essentially the same: you can request a new login token equally as often as you can request a new "Forgot Your Password" token in that they are both manually requested with only an email address. There are also already a growing number of users that use "Forgot Your Password"-only login (most accidentally; human memory is porous) day to day. Which is not to say that we shouldn't make email better and more secure, but that the security of our email infrastructure is a red herring of sorts in the larger security discussions of "passwordless" login, given that we are already equally insecure in every website that has a "Forgot Your Password" button that accepts anyone's email address.
        jessaustin 11y ago
        An attacker who can "watch", can also click the "forgot my password" button whenever she happens to be watching.
    - mynameisvlad 11y ago
elbigbad 11y ago
So does this mean one has to go into their email everytime they need to log in, or just until the cookie expires? I assume it's the latter. It's a little more inconvenient in the second instance that traditional password entry (given that all my passwords are saved in Chrome), but sounds a lot more secure. Especially since I use a hard gmail password and two factor authentication to access email. Would be nice to add a 'log out on all machines' link to the email with the password button as well.
- WorldMaker 11y ago
  Just until a session cookie expires. Session management can/should be much the same as you would expect. The benefit here for you, though, is that you get "free two factor" on these sorts of sites, without those sites having to implement it, simply because you use a two factor email. It's a rising security tide, of a sort.
shanecleveland 11y ago
http://searchpath.io http://searchpath.io does this nicely.
paulcole 11y ago
I don't see any mention of how log out works. Is it as soon as the browser window is closed? I'd find that a little annoying on my own device, but it would be essential on a shared computer-- at the library for example. I'm thinking a checkbox saying "Shared Computer" and issues a link with a different session length (or logout on window close) if checked? Personally I love this idea as managing passwords has become really unwieldy and I don't trust any password manager service. Plus for a few sites that require really bizarre password length/character requirements/etc., I just reset them overtime I want to log in anyway.
- josephorjoe 11y ago
  I don't think this pattern requires a change to how log out works. It's just a change to creating a session and shouldn't impact ending one. I'm definitely in favor of making people create fewer passwords. It's a nuisance that probably has a net negative affect on security by encouraging people to re-use weak passwords.
  - criddell 11y ago
    I wonder how many public computers are configured to end sessions when the browser is closed? Actually, can you even configure that anymore?
    - WorldMaker 11y ago
      Incognito Mode, In Private Mode, whatever you want to call it. Browsers now give you a spiffy, hard to miss logo when in such a mode these days now too.
      - criddell 11y ago
        Oh right. I wonder if libraries could configure their computers to always be in private or incognito mode?
        11y ago
digitalengineer 11y ago
WordPress has CLEF. Any thoughts? https://nl.wordpress.org/plugins/wpclef/ https://nl.wordpress.org/plugins/wpclef/
- throwaway2016a 11y ago
  Clef works for way more than just Wordpress.
fosco 11y ago
This is inherently a password in the form of a url similar to using REST which still requires a password to obtain the link in the first place (email) I only see this as a partial solution.
- eximius 11y ago
  All non-PK cryptography eventually boils down to a 'password' if you call it that. But this isn't a password, it's a shared secret. Which IS a good solution (not GREAT, but better), it just shifts the problem into communicating the shared secret. This is where TOTP comes in for most 2FA implementations. This particular scheme just uses email.
umut 11y ago
It would be cool if someone does an A/B testing over a significantly big population of users and show us the dropoffs on each version. I would love to have no password login (temp token), but if the users don't receive them on time (email deliverability might be laggy at times), or they don't get the idea, or they don't care/like the method.. Well, you got my point.
sareiodata 11y ago
For WordPress I developed this simple plugin based on the initial article https://wordpress.org/plugins/passwordless-login/ https://wordpress.org/plugins/passwordless-login/ http://www.cozmoslabs.com/31550-wordpress-passwordless-login/ http://www.cozmoslabs.com/31550-wordpress-passwordless-login...
d0lph 11y ago
Another concern, this is going to be saved to the browser's history, and thus to the HDD.
- WorldMaker 11y ago
  These tokens should not be able to be reused, even if found in browser history. Additionally, the HTTP flow is to 301 redirect to the user's homepage or dashboard and browsers tend not to bother storing URLs that result in 301 redirects.
bendykstra 11y ago
There is another passwordless system called SQRL which is automated and more secure. From the user's perspective, they scan a QR code or click a browser extension and are signed into the site. Behind the scenes, a cryptographic challenge (a response URL + nonce) is presented to the user's phone or browser extension. The client signs the challenge using a per-site private key and sends the result to the provided URL. https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm
- Natanael_L 11y ago
  Tiqr predates it and does the same thing. However, U2F and UAF from FIDO alliance are the new protocols that are being standardized, and they're looking good too. It is even designed to inherently resist tracking across services by using unique keypairs per service in a clever way. No device identifier is ever shared.
  - ronancremin 11y ago
    According to Steve Gibson (SQRL's inventor) tiQr is quite different: "It superficially appears to offer a user experience similar to SQRL. However, as is every other such system, what's going on is actually far more complex and involves/requires establishing “shared secret” account credentials with the authenticating website. As they explain on their technical page, TiQr is based on the OATH (open authentication) OCRA protocol suite, which was standardized by RFC6287." https://www.grc.com/sqrl/other.htm https://www.grc.com/sqrl/other.htm
stanmancan 11y ago
I like the idea, but doesn't it come with a few security concerns? One blaring issue is that email is sent in plain text, so anyone can intercept it and log in as you. I was originally going to complain that anyone who has access to your email now has access to all of your accounts, but upon further thought I don't know how much of a concern this really. First, the vast majority of people use the same password everywhere anyways. Second, most services use your email to reset your password anyways. The only security difference I can think of is if someone uses your email for a password reset and changes your password, it becomes very obvious there might have been a security issue when you try to log in and your password doesn't work. If all someone has to do is follow the link, there's nothing to create that suspicion. A few other things to consider: - How long does the token emailed to you last for? - If I send a new token, do previous sessions expire? ---- If so, how can I be logged in via multiple browsers/computers? ---- If not, does an attacker have permanent access to my account if they got access to a single link?
- WorldMaker 11y ago
  Links would be one-time-use tokens, just as with existing password reset links. Security footprint is essentially the same as today.
- joeyh 11y ago
  When I implemented this, I made the following choices: 1 hour login email expire time by default, tunable. I'd make it shorter, but it has to get around greylisting. Sending a login mail and logging in does not affect existing browser sessions. Only allow a login email to be used one time. Only allow the last login email sent to be used, not old ones. This and the expiry keep email archives from becoming a problem. Another thing you could do is set a cookie and have the login link check for the cookie. That makes the link worthless even if the attacker intercepts it. But, it lets the attacker DOS a user and prevent them from logging in by continually requesting new login emails, so you'd probably want to allow previous login emails to be used. Of course, as a user, how do I know which of these security tradeoffs a site has chosen? It's as bad as using a password and hoping they don't store in clear text. It would be better to have a protocol for login that makes clear choices.
- 11y ago
vacri 11y ago
Great, so now instead of a password to remember, I have to remember a link? How is that substantially different from carrying around emails with passwords in them? Or with dynamic links, I now have to go through a separate application with an extra click-link-to-login-then-close-tab-and-find-original-tab motion? Instead of logging in by opening a password safe, I now have to log in by opening email... and have a new source of email clutter... and can't share an account with other people... and disposable emails for signing up to less reputable services becomes less of an option. And what happens when you move email addresses? Or there's a problem with email (delays are common)? A password safe that relies on an asynchronous messaging protocol? Yuck.
- gknoy 11y ago
  I like Steam's solution: Login on new machine (Email + password) They send me an email with a short code (~6 characters) I copy/paste those few characters They remember that machine for ${a-long-time}
joeyh 11y ago
This is clearly a Worse is Better solution. Where the "worse" is the complicated and often not user-visible process involved in getting the login email to them in a timely manner. That said, I implemented it a while ago, since there's no widely deployed distributed alternative, and as seen with OpenID, attempts to create one will be frustrated by entrenched interests and technical debt. I still think that Mozilla could have gotten around that problem with Persona if they had built it right into the browser. Pity.
- WorldMaker 11y ago
  It's more "Less is Better"; today for a password login system you need to have and secure: 1. Password database 2. Password UX 3. Forgot Your Password UX 4. Forgot Your Password one-time-use token via email/SMS This drops 1 and 2, leaving 3 and 4 as the remaining security footprint. (I also think that Persona was heading in the right direction and wish it had received better traction.)
p3d4nt 11y ago
Someone could flood your inbox with these requests?
madbiz 11y ago
Any reasons why this cant be done using push messages? Another way could be to send an intent to the right app using some special email header (X-App-Scheme) by the mail app. The current email login flows force the user to open the mail app and to click the link inside the mail (which then normally opens the app using a registered scheme).
- mderazon 11y ago
  Paswordless login actually fits even nicer in mobile. You can make the email link open as a deep link in the app and continue right where you left. Context switching in the app is minimal and in mobile apps sessions are usually more persistent anyway See http://www.drzon.net/passwordless-login-in-mobile-apps/ http://www.drzon.net/passwordless-login-in-mobile-apps/ for what I mean
  - madbiz 11y ago
    I described the way it is currently done on mobile devices but i was thinking about a way to even cut that context switch by letting an app react to an email rather than handling the link scheme.
Zooper 11y ago
PGP Keyring as part of native Web Storage or bust.

44 points by atomical 11y ago

I wrote a Koa middleware that I've found handy for this: https://www.npmjs.com/package/koa-signed-url https://www.npmjs.com/package/koa-signed-url It introduces the idea of a "signed URL", which can be verified or rejected based on checking a signature query parameter. You can send such a signed URL via email, text message, etc.

d0lph 11y ago

This seems to make urls themselves passwords, and your email a password safe.

elcapitan 11y ago
True, but arguably whoever can access your email could just as well use password reset functionality for a given site you are using. The generated url-login-tokens on the other hand will be long random strings and harder to impossible to crack.
WorldMaker 11y ago
These are one-time use tokens, just like you should use for a "Forgot Your Password" email login. It's literally the same steps, just there's no new password to input, the website just gives you a login cookie and you can go about your day.
- mattashii 11y ago
  The point is that the most commonly used e-mail protocols do not have safety built in. The solutions for this problem (e.g. PGP signing) are not adapted widely enough to be considered adapted by the market. If you'd want to use two-factor authentication by verifying access to the mailbox, you have to make sure that that (the connection to) the mail box is safe as well, which can potentially be very hard. The mailbox still is a safe, but only from the moment that the mail has been sent to the moment the page has been requested. Mind that a safe connection to your mailbox does not also mean a safe connection to the server, but that is something that is covered by https+certificates (mostly).
  - WorldMaker 11y ago
    This is no worse a security footprint than the existing, requisite "Forgot Your Password" flow. It's the exact same security footprint. TLS is already an under-spoken requisite of SMTP communications from any webserver doing "Forgot Your Password" workflows. TLS between mail servers is also already a de facto SMTP requirement for most bare minimum spam fighting mechanisms.
    - mgreg 11y ago
      True that the password reset and the "login" using this proposal travel the same path and present the same attack vector but there is some disadvantage to the frequency in which the "login" system would travel down this less-than-secure path. The more times you use this the more likely that someone will just happen to be watching and waiting at the right time. Let's not forget that most of the email system is still not encrypted (last time I checked anyway) even though the last mile between your mail server and your client may be.
      - WorldMaker 11y ago
        Frequency is also essentially the same: you can request a new login token equally as often as you can request a new "Forgot Your Password" token in that they are both manually requested with only an email address. There are also already a growing number of users that use "Forgot Your Password"-only login (most accidentally; human memory is porous) day to day. Which is not to say that we shouldn't make email better and more secure, but that the security of our email infrastructure is a red herring of sorts in the larger security discussions of "passwordless" login, given that we are already equally insecure in every website that has a "Forgot Your Password" button that accepts anyone's email address.
      - jessaustin 11y ago
        An attacker who can "watch", can also click the "forgot my password" button whenever she happens to be watching.
  - mynameisvlad 11y ago

elbigbad 11y ago

So does this mean one has to go into their email everytime they need to log in, or just until the cookie expires? I assume it's the latter. It's a little more inconvenient in the second instance that traditional password entry (given that all my passwords are saved in Chrome), but sounds a lot more secure. Especially since I use a hard gmail password and two factor authentication to access email. Would be nice to add a 'log out on all machines' link to the email with the password button as well.

WorldMaker 11y ago
Just until a session cookie expires. Session management can/should be much the same as you would expect. The benefit here for you, though, is that you get "free two factor" on these sorts of sites, without those sites having to implement it, simply because you use a two factor email. It's a rising security tide, of a sort.

shanecleveland 11y ago

http://searchpath.io http://searchpath.io does this nicely.

paulcole 11y ago

I don't see any mention of how log out works. Is it as soon as the browser window is closed? I'd find that a little annoying on my own device, but it would be essential on a shared computer-- at the library for example. I'm thinking a checkbox saying "Shared Computer" and issues a link with a different session length (or logout on window close) if checked? Personally I love this idea as managing passwords has become really unwieldy and I don't trust any password manager service. Plus for a few sites that require really bizarre password length/character requirements/etc., I just reset them overtime I want to log in anyway.

josephorjoe 11y ago
I don't think this pattern requires a change to how log out works. It's just a change to creating a session and shouldn't impact ending one. I'm definitely in favor of making people create fewer passwords. It's a nuisance that probably has a net negative affect on security by encouraging people to re-use weak passwords.
- criddell 11y ago
  I wonder how many public computers are configured to end sessions when the browser is closed? Actually, can you even configure that anymore?
  - WorldMaker 11y ago
    Incognito Mode, In Private Mode, whatever you want to call it. Browsers now give you a spiffy, hard to miss logo when in such a mode these days now too.
    - criddell 11y ago
      Oh right. I wonder if libraries could configure their computers to always be in private or incognito mode?
      - 11y ago

digitalengineer 11y ago

WordPress has CLEF. Any thoughts? https://nl.wordpress.org/plugins/wpclef/ https://nl.wordpress.org/plugins/wpclef/

throwaway2016a 11y ago
Clef works for way more than just Wordpress.

fosco 11y ago

This is inherently a password in the form of a url similar to using REST which still requires a password to obtain the link in the first place (email) I only see this as a partial solution.

eximius 11y ago
All non-PK cryptography eventually boils down to a 'password' if you call it that. But this isn't a password, it's a shared secret. Which IS a good solution (not GREAT, but better), it just shifts the problem into communicating the shared secret. This is where TOTP comes in for most 2FA implementations. This particular scheme just uses email.

umut 11y ago

It would be cool if someone does an A/B testing over a significantly big population of users and show us the dropoffs on each version. I would love to have no password login (temp token), but if the users don't receive them on time (email deliverability might be laggy at times), or they don't get the idea, or they don't care/like the method.. Well, you got my point.

sareiodata 11y ago

For WordPress I developed this simple plugin based on the initial article https://wordpress.org/plugins/passwordless-login/ https://wordpress.org/plugins/passwordless-login/ http://www.cozmoslabs.com/31550-wordpress-passwordless-login/ http://www.cozmoslabs.com/31550-wordpress-passwordless-login...

d0lph 11y ago

Another concern, this is going to be saved to the browser's history, and thus to the HDD.

WorldMaker 11y ago
These tokens should not be able to be reused, even if found in browser history. Additionally, the HTTP flow is to 301 redirect to the user's homepage or dashboard and browsers tend not to bother storing URLs that result in 301 redirects.

bendykstra 11y ago

There is another passwordless system called SQRL which is automated and more secure. From the user's perspective, they scan a QR code or click a browser extension and are signed into the site. Behind the scenes, a cryptographic challenge (a response URL + nonce) is presented to the user's phone or browser extension. The client signs the challenge using a per-site private key and sends the result to the provided URL. https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm

Natanael_L 11y ago
Tiqr predates it and does the same thing. However, U2F and UAF from FIDO alliance are the new protocols that are being standardized, and they're looking good too. It is even designed to inherently resist tracking across services by using unique keypairs per service in a clever way. No device identifier is ever shared.
- ronancremin 11y ago
  According to Steve Gibson (SQRL's inventor) tiQr is quite different: "It superficially appears to offer a user experience similar to SQRL. However, as is every other such system, what's going on is actually far more complex and involves/requires establishing “shared secret” account credentials with the authenticating website. As they explain on their technical page, TiQr is based on the OATH (open authentication) OCRA protocol suite, which was standardized by RFC6287." https://www.grc.com/sqrl/other.htm https://www.grc.com/sqrl/other.htm

stanmancan 11y ago

I like the idea, but doesn't it come with a few security concerns? One blaring issue is that email is sent in plain text, so anyone can intercept it and log in as you. I was originally going to complain that anyone who has access to your email now has access to all of your accounts, but upon further thought I don't know how much of a concern this really. First, the vast majority of people use the same password everywhere anyways. Second, most services use your email to reset your password anyways. The only security difference I can think of is if someone uses your email for a password reset and changes your password, it becomes very obvious there might have been a security issue when you try to log in and your password doesn't work. If all someone has to do is follow the link, there's nothing to create that suspicion. A few other things to consider: - How long does the token emailed to you last for? - If I send a new token, do previous sessions expire? ---- If so, how can I be logged in via multiple browsers/computers? ---- If not, does an attacker have permanent access to my account if they got access to a single link?

WorldMaker 11y ago
Links would be one-time-use tokens, just as with existing password reset links. Security footprint is essentially the same as today.
joeyh 11y ago
When I implemented this, I made the following choices: 1 hour login email expire time by default, tunable. I'd make it shorter, but it has to get around greylisting. Sending a login mail and logging in does not affect existing browser sessions. Only allow a login email to be used one time. Only allow the last login email sent to be used, not old ones. This and the expiry keep email archives from becoming a problem. Another thing you could do is set a cookie and have the login link check for the cookie. That makes the link worthless even if the attacker intercepts it. But, it lets the attacker DOS a user and prevent them from logging in by continually requesting new login emails, so you'd probably want to allow previous login emails to be used. Of course, as a user, how do I know which of these security tradeoffs a site has chosen? It's as bad as using a password and hoping they don't store in clear text. It would be better to have a protocol for login that makes clear choices.
11y ago

vacri 11y ago

Great, so now instead of a password to remember, I have to remember a link? How is that substantially different from carrying around emails with passwords in them? Or with dynamic links, I now have to go through a separate application with an extra click-link-to-login-then-close-tab-and-find-original-tab motion? Instead of logging in by opening a password safe, I now have to log in by opening email... and have a new source of email clutter... and can't share an account with other people... and disposable emails for signing up to less reputable services becomes less of an option. And what happens when you move email addresses? Or there's a problem with email (delays are common)? A password safe that relies on an asynchronous messaging protocol? Yuck.

gknoy 11y ago
I like Steam's solution: Login on new machine (Email + password) They send me an email with a short code (~6 characters) I copy/paste those few characters They remember that machine for ${a-long-time}

joeyh 11y ago

This is clearly a Worse is Better solution. Where the "worse" is the complicated and often not user-visible process involved in getting the login email to them in a timely manner. That said, I implemented it a while ago, since there's no widely deployed distributed alternative, and as seen with OpenID, attempts to create one will be frustrated by entrenched interests and technical debt. I still think that Mozilla could have gotten around that problem with Persona if they had built it right into the browser. Pity.

WorldMaker 11y ago
It's more "Less is Better"; today for a password login system you need to have and secure: 1. Password database 2. Password UX 3. Forgot Your Password UX 4. Forgot Your Password one-time-use token via email/SMS This drops 1 and 2, leaving 3 and 4 as the remaining security footprint. (I also think that Persona was heading in the right direction and wish it had received better traction.)

p3d4nt 11y ago

Someone could flood your inbox with these requests?

madbiz 11y ago

Any reasons why this cant be done using push messages? Another way could be to send an intent to the right app using some special email header (X-App-Scheme) by the mail app. The current email login flows force the user to open the mail app and to click the link inside the mail (which then normally opens the app using a registered scheme).

mderazon 11y ago
Paswordless login actually fits even nicer in mobile. You can make the email link open as a deep link in the app and continue right where you left. Context switching in the app is minimal and in mobile apps sessions are usually more persistent anyway See http://www.drzon.net/passwordless-login-in-mobile-apps/ http://www.drzon.net/passwordless-login-in-mobile-apps/ for what I mean
- madbiz 11y ago
  I described the way it is currently done on mobile devices but i was thinking about a way to even cut that context switch by letting an app react to an email rather than handling the link scheme.

Zooper 11y ago

PGP Keyring as part of native Web Storage or bust.