4 ms·

I really like the idea behind passwordless [1], where users never use a password but just confirm they are who they say they are. I always remember Tom Scott s

I really like the idea behind passwordless [1], where users never use a password but just confirm they are who they say they are. I always remember Tom Scott saying "Don't store passwords yourself if you can all avoid it" [2] and how you should leverage google, facebook and other 3rd party authentication methods as a way to add a layer of security and remove one way to compromise your user data. [1] https://passwordless.net/about https://passwordless.net/about [2] https://www.youtube.com/watch?v=8ZtInClXe1Q https://www.youtube.com/watch?v=8ZtInClXe1Q

jand 11y ago
A disadvantage is the media break while using passwordless. Some folks i met strongly believe that using a different medium while interacting with a site distracts new users, by this lowering the sign-up rate. I have no data on that but it sounded at least plausible. If you believe in this, it would depend on your target group how you should handle passwords (or the lack of).
- miseg 11y ago
  If you can catch a person's email address upon their registration, it's the re-logging-in that would require them to switch to a different medium.
- felipesabino 11y ago
  I think your argument would also valid for 2FA approach, which is is widely encouraged regardless. Sign-up rate would drop drastically for a majority of common users if a good UX is not into play while developing the system workflow. But I want also say that for a great variety of solutions having 2FA or passwordless as default is valid, Slack for example has an option of demanding 2FA for all team members, which a lot of people would agree is a good thing. The "Password Security Guide" section at the article is a good example of educating people how insecure storing password, and you could do the same thing showing/enabling passwordless as a clear and easy alternative to migrate to.
  - jand 11y ago
    You are right. Here comes the "target group" aspect (and some others) into play. Oversimplification: Are you targeting techies or eldery? Some will endure security-related hardships, others won't. As said, there is the need to watch who you design for.
  - cvburgess 11y ago
    But most sites let you "trust this device" once you've done 2FA - passwordless doesn't have that option from what I can tell. Also, 2FA is an extra, optional layer for most users. They can choose if they want the extra hassle in exchange for security. Passwordless gives you no such option, you have to switch apps, period.
pavel_lishin 11y ago
What if I don't want to confirm that I'm Pavel Lishin to a given website? Do I have to create a new Facebook, etc., account? One per website I don't want to identify myself to?
- felipesabino 11y ago
  You can always use browser identification [1] for that (Yes, that's a joke :p) [1] http://kluge.in-chemnitz.de/tools/browser.php http://kluge.in-chemnitz.de/tools/browser.php
bluegate010 11y ago
An issue with passwordless is its vulnerability to passive attack. From perusing the source code, it looks like they authenticate users based on a token and uid embedded in a link sent to the user's email address. If that link is intercepted, an attacker can impersonate the user. A system that addresses this drawback is SAW [1, 2]; it splits a token in half (via XOR) and sends part of it to the user as a cookie, and part to the user's email address. Clicking the link combines the two and submits them both to the server for validation. [1] http://isrl.byu.edu/pubs/pp1001.pdf http://isrl.byu.edu/pubs/pp1001.pdf (short) [2] http://isrl.byu.edu/pubs/saw.pdf http://isrl.byu.edu/pubs/saw.pdf (long)

jand 11y ago

A disadvantage is the media break while using passwordless. Some folks i met strongly believe that using a different medium while interacting with a site distracts new users, by this lowering the sign-up rate. I have no data on that but it sounded at least plausible. If you believe in this, it would depend on your target group how you should handle passwords (or the lack of).

miseg 11y ago
If you can catch a person's email address upon their registration, it's the re-logging-in that would require them to switch to a different medium.
felipesabino 11y ago
I think your argument would also valid for 2FA approach, which is is widely encouraged regardless. Sign-up rate would drop drastically for a majority of common users if a good UX is not into play while developing the system workflow. But I want also say that for a great variety of solutions having 2FA or passwordless as default is valid, Slack for example has an option of demanding 2FA for all team members, which a lot of people would agree is a good thing. The "Password Security Guide" section at the article is a good example of educating people how insecure storing password, and you could do the same thing showing/enabling passwordless as a clear and easy alternative to migrate to.
- jand 11y ago
  You are right. Here comes the "target group" aspect (and some others) into play. Oversimplification: Are you targeting techies or eldery? Some will endure security-related hardships, others won't. As said, there is the need to watch who you design for.
- cvburgess 11y ago
  But most sites let you "trust this device" once you've done 2FA - passwordless doesn't have that option from what I can tell. Also, 2FA is an extra, optional layer for most users. They can choose if they want the extra hassle in exchange for security. Passwordless gives you no such option, you have to switch apps, period.

pavel_lishin 11y ago

What if I don't want to confirm that I'm Pavel Lishin to a given website? Do I have to create a new Facebook, etc., account? One per website I don't want to identify myself to?

felipesabino 11y ago
You can always use browser identification [1] for that (Yes, that's a joke :p) [1] http://kluge.in-chemnitz.de/tools/browser.php http://kluge.in-chemnitz.de/tools/browser.php

bluegate010 11y ago

An issue with passwordless is its vulnerability to passive attack. From perusing the source code, it looks like they authenticate users based on a token and uid embedded in a link sent to the user's email address. If that link is intercepted, an attacker can impersonate the user. A system that addresses this drawback is SAW [1, 2]; it splits a token in half (via XOR) and sends part of it to the user as a cookie, and part to the user's email address. Clicking the link combines the two and submits them both to the server for validation. [1] http://isrl.byu.edu/pubs/pp1001.pdf http://isrl.byu.edu/pubs/pp1001.pdf (short) [2] http://isrl.byu.edu/pubs/saw.pdf http://isrl.byu.edu/pubs/saw.pdf (long)