10 ms·

Password-less login

70 points by im_dario 10y ago

jlebrech 10y ago
also https://passwordless.net/ https://passwordless.net/
herghost 10y ago
An interesting idea for a few reasons. Users don't have to remember passwords, which is a strong benefit, but the user's security is now dependent on the security of their mail provider, or their own security practices in relation to the use of that mail provider, and in all likeliness their smart device. With the ubiquity of smart devices, this works from a UX point of view and could be really streamlined, but I wonder how much the meme at the top of the article is actually betraying - this is the service provider not wanting to be responsible for your security in relation to their service. I'm not suggesting that this is unreasonable per se, but the ultimate evolution of this model looks like it could (potentially dangerously) increase the value of a smaller surface area (the smart device) and put a fairly huge onus on the end user understanding and being responsible for their security. And whilst that seems ostensibly ok, we already know that the weakest link in security is the end user...so this could be putting all your eggs in one basket.
- askafriend 10y ago
  > but the user's security is now dependent on the security of their mail provider Let me put it this way. In many (but not all) cases I would much rather Google be responsible for my security rather than some random startup whose primary objective is to stay alive, not take security seriously.
  - subkamran 10y ago
    It's funny you say that because I feel the same way as a developer. However, users of my site wanted password-based logins even though I support multiple social logins (Google, FB, Microsoft, etc.). Granted, I use PBKDF2 salting and hashing and I take security seriously, but it's interesting how average people sometimes don't trust social providers or think I'm storing their credentials to that provider.
- adrianN 10y ago
  Isn't user security already dependent or their mail provider? Password reset mails are pretty common.
grav 10y ago
Password-less login is a bit of a weird naming. I'd call it one-time passwords. And then I'd maybe not use email, since this clutters the inbox. Instead something like Google Authenticator or SMS passwords would be a good solution, the latter maybe being a bit expensive for the service provider.
- hawski 10y ago
  Password-less as in "one password less to remember/invent".
- Freak_NL 10y ago
  That would make having an SMS-capable phone nearby a hard requirement to simply login to some service. I am fine with offering additional authentication methods — if they are safe enough for that application — but dismissing passwords as a concept (unless you are scaling up to proper 2FA, e.g., Fido U2F) just means losing users for no good reason.
- gkya 10y ago
  > since this clutters the inbox Email can be deleted.
scbrg 10y ago
Con: Greylisting. My primary email uses greylisting to combat spam. This means that if we receive a mail from an unfamiliar mail server, it's getting an error message saying the mail can not be delivered at the moment, and to come back later. Properly configured servers try again several minutes later. Spam bots seldom try again, so it works well. I can see how greylisting and tokens that expire quickly can be a problem. Particularly if you have multiple servers for outgoing mails, so that the second mail attempt may come from another IP than the first.
- abricot 10y ago
  I'd say that this is a con for graylisting, and not for passwordless access.
  - 2T1Qka0rEiPr 10y ago
    Or at least, for both.
- wojt_eu 10y ago
  When email comes delayed (with invalid token) can you white-list that particular sender? You'd then request another sign-in email that comes promptly this time.
- aruggirello 10y ago
  Well this is certainly a problem, but it's mostly limited to the first login, as (IMHO) the mail server(s) should use DKIM so greylisting can safely assume it's receiving mail from the same (legitimate) domain (the actual IP used becomes irrelevant). The first password-less login email could allow for a longer expiration, and it wouldn't be worse than a password-ful first login with email verification anyway.
Sir_Substance 10y ago
I'm glad to see this idea gaining traction. Passwords are a lazy solution that is often not needed. This type of login is ideal for websites and services that I might use less than 4 times a year. I usually log into such services by doing a password reset every time I visit their service, and this technique at least removes the risk of password leaking.
zer0tonin 10y ago
>Con: If database is compromised and passwords are reused across sites, then attackers might be able to access more sites Never heard of hashing or TLS/SRP?
- manigandham 10y ago
  Those alone are not enough, a compromised database storing hashed passwords behind a service that uses TLS would still allow the attackers to try common passwords and hashing algorithms to see what passwords were used. Password simplicity and reuse (especially across lots of people) is a major problem with password security in data breaches.
- grenoire 10y ago
  Salting is more relevant in this case.
- grenoire 10y ago
  Salting is more relevant in this case.
danijelb 10y ago
This is similar to what Whatsapp (and some other apps) are doing. The only difference is that they are using phone numbers.
PuffinBlue 10y ago
This implementation is just skipping the charade that passwords are where the security happens. With almost all current systems the place security really needs to happen is at the email provider. If you can hijack/intercept a users email or hack their account then it's game over with a password anyway, thanks to password resets being (almost) universally done over that channel. There's an argument that this is no bad thing as security focused email providers could potentially provide very secure access as part of their core business (unlike a startup just trying to get going). But there's still something bugging me about this implementation I can't put my finger on.
- danijelb 10y ago
  The only thing that's bothering me is that it is done through e-mail. I would prefer the token to arrive as a text message to my phone number. I feel like it is safer and faster. However, I understand that it is more expensive option, especially for services where you need to log in multiple times, compared to mobile apps where you log in only once.
  - consp 10y ago
    SMS (in it's classical form) is highly spoofable as has been proven with TAN codes time-and-time again. It will work most of the time (sms has no guarantee of delivery as far as I know) and is somewhat secure but by no means good in any way. This relies on email, which is highly secure, smtp is not spoof-able, server and mail origins are traceable and verifiable and there is no way to intercept the message on a malicious router/switch whatever. Ow wait ...
- megous 10y ago
  E-mail is good enough for me as a channel. But the service should allow me to upload a PGP pub key and use it for all further communication, no exceptions (including password resets, etc.). That would secure the channel and the website would be able to trust that whoever is clicking the reset link is the owner of the key. It would also be a nice second factor. You have to have access to the email account and to the private PGP key. And it is a second factor I can fully control, unlike SMS. And it's simple and cheap for the service.
sareiodata 10y ago
For WordPress: https://wordpress.org/plugins/passwordless-login/ https://wordpress.org/plugins/passwordless-login/
- subkamran 10y ago
  Just what Wordpress needs.
susw 10y ago
Is it really necessary that the email link is clicked on the same device or to use a typeable token? Clicking the link on any device is enough to confirm to the server that the login attempt should be granted access. The server can then send and authentication token to the browser where the user is logging in. The downsides I can think of in that case are an attacker attempting to log in at the same time, or -- more generally -- a user thoughtlessly clicking the link when an attacker is trying to log in. The first problem can be addressed by displaying a second readable token on the login screen which the user should verify is present in the email before they click the link. That is how banks and other high security systems do it here in Norway now when you select authentication via mobile, except they use some sort of mobile communication tied to the sim card instead of email. You get a popup on your phone containing two random words from a dictionary. You confirm that the words match what the browser is currently displaying and then tap "OK". The second problem can probably be reduced by short token timeouts and using appropriate language in the email to emphasize the implication of clicking the link uncritically.
shimon_e 10y ago
This is commonly referred to as OTP and I have implemented it on a few recent projects. It is very common in Asian countries.
jpttsn 10y ago
I built (essentially) this a few weeks back, for an iOS app. Currently trying to get Apple's App Review team to agree it's a good idea. Apple has UI in App Store submission that lets you provide App Review with a demo account username/password combo, but only that. So to highlight another drawback: sometimes being able to share login credentials is a feature. Part of me thinks this ought not to be the case, and I hope I will be able to stick with password-less login.
- wingerlang 10y ago
  Can't you just whitelist some token for them? If the sharing is the issue you're having with them anyway.
  - jpttsn 10y ago
    I'm looking at that. I don't know what email they will use to test, and I don't know if they'll look kindly at a special case for reviewers. Do you have any experience with that?
_pmf_ 10y ago
So, nothing new since Kerberos?
mherrmann 10y ago
> You can't leak passwords if you don't store passwords. That's exactly why you only store password hashes in the DB. Come on, this is a solved problem! > Pro: less implementation effort Sure. But how much of your app's total dev effort is it? Nothing. I hate the UX of having to log in by email.
- gkya 10y ago
  >> You can't leak passwords if you don't store passwords. > That's exactly why you only store password hashes in the DB. Come on, this is a solved problem! Isn't leaking hashes dangerous for the users' privacy though (I'm not well-versed in security, so sorry if n00b question)?
  - jhasse 10y ago
    > Isn't leaking hashes dangerous for the users' privacy though (I'm not well-versed in security, so sorry if n00b question)? No, you can't compute the password from the hash.
    - MaulingMonkey 10y ago
      I'd call this dangerously un-caveated! https://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/ https://arstechnica.com/security/2012/12/25-gpu-cluster-crac... If your users passwords are sufficiently weak (and let's face it - they are) they can likely be brute forced and then matched against leaked hashes, no matter how strong your salt and hash. If you've got good users who only give you "typically" weak passwords, weak unsalted hashes will still expose said passwords. Use a strong hash. Perhaps run multiple times, bcrypt style. Salt correctly, and per-user. Somehow convince your users to actually use strong, non-reused passwords. Perhaps then there's no danger to leaking the hashes - but I'd perhaps err on the side of caution and not make the password database publicly readable nonetheless.
  - dsr_ 10y ago
    Depends. If you use a nice fast hash like SHA256, yes. If you use a KDF optimized for nonoptimizability like PBKDF2 or scrypt, no.
ss64 10y ago
cons: If the customers email service goes down, then their access goes down. If your email service goes down, then the service goes down for everyone. If a major email provider is compromised, then a bunch of your accounts can be compromised. All public server-to-server email communication takes place over port 25, unsecurred clear text. That seems like a poor choice for anything security related in 2017. If anything we should be removing insecure protocols like email, telephone and SMS from the authentication chain rather than relying on them even more heavily than we already do. I hate to suggest it but authentication via something like WhatsApp might be more secure.
- NoGravitas 10y ago
  Server-to-server email is mostly STARTTLS (but without certificate validation) these days, I believe. Not great, but better than you think.
zbuf 10y ago
You can easily leak whether someone has an account on your website -- if I know their email address and input it, does it basically tell me? This limits your ability to reasonably error if the email address inputted is wrong. Still, a lot of "forgot password" forms seem to be subject to this, too. Also, you can only have one account per-email -- a disadvantage for some types of service, but admittedly probably a good thing for most.
jlgaddis 10y ago
> Claim: If someone has access to email account, then they can login. > Rebuttal: This is possible in a password-ful login setup via the forgot password flow. Sometimes there are additional “security questions” but this is typically easily found information. The difference here is that if/when someone uses their (unauthorized) access to my e-mail account to reset the password for this service, I will notice the next time I attempt to log in. In an ideal world, one could prevent another from gaining access to an account, service, etc. When you can't prevent something, the next best thing is detection. Here, you've just removed the ability for a user to detect that their account is compromised -- and worse, you're trying to spin it like it's a good thing. Also, greylisting. Also, what if I wanted to log in to my account from my phone or a mobile device? I choose not to receive e-mail on my phone (only alerts/notifications) and I'm certainly not the only one. It sounds like someone pitched this idea at a meeting ("Hey, I know! No passwords!") and the next 10 minutes was spent rationalizing all its problems away before declaring it as the one true solution.
- demonshreder 10y ago
  >The difference here is that if/when someone uses their (unauthorized) access to my e-mail account to reset the password for this service, I will notice the next time I attempt to log in. I am assuming the indicator would be an email from a service stating password reset but if the person has access to your email account, the obvious thing to do would be delete such an email. There is no difference. Passwordless login is basically piggy backing on the security of the email account. You'd have to login to a site anyway but you are just logging in to your email which is assumed to be protected better.
  - jswny 10y ago
    I think OP meant that he will clearly realize if someone used his email account to reset his password because next time he tries to log in his old password will no longer work. However with passwordless authentication, someone with access to your email account could issue your account for potentially a long period of time without you noticing. You would still be under the impression that your account is secure.
kodfodrasz 10y ago
> Strawperson argument Will this newspeak fury ever stop?
mike-cardwell 10y ago
Loosely related. Why doesn't my web browser speak IMAP? If I could just enter my IMAP details into my browser settings, then it could silently IDLE on my Inbox, and inform my currently open http://example.com/ http://example.com/ tabs when it receives email from an @example.com address. You'd need to stick it behind a "This website wishes to be notified about email you receive from it" prompt. But then you'd be able to do all sorts of clever stuff, including streamlining email validation checks and password resets. Everybody has email. You could create a "Login with Email" function really easily on your website, and it would work for even more users than the "Login with Facebook" option.
- kodfodrasz 10y ago
  why should the browsers speak every protocol? Why should everything be done through the browsers, instead of better specialized programs? Why should protocols designed for one problem be abused to solve other problems? Why not use client certs instead?
  - mike-cardwell 10y ago
    "Why should the browsers speak every protocol?" Why should browsers only speak HTTP? Who made that rule? "Why should everything be done through the browsers, instead of better specialized programs?" I never said "everything". "Better specialised programs"? What are you talking about? I'm talking about essentially being able to access email from a webpage. There is no "better specialised program" for doing that. I'm not talking about webmail. I'm talking about automated emails. "Why should protocols designed for one problem be abused to solve other problems?" What you call "abuse", I call "use". "Why not use client certs instead?" This has nothing to do with anything I've mentioned.
    - kodfodrasz 10y ago
      No better program to access email from anywhere than a browser. Have you heard about MUA-s? Special mails should be used for authentication which would specially handled by the browser accessing your mailbox. This is abusing the mail protocols in my opinion. Certificate based auth does have something to with this: an existing, partially supported solution for auth with no magic needed and no need to reinvent the wheel, with hacks and extra complications.
anoctopus 10y ago
>Claim: With this setup, I can’t login easily with my LastPass, 1Password, etc browser extension. >Rebuttal: This is a legitimate claim but it’s equally plausible to use an email integrated browser extension. You could do that, but since this isn't a very common login scheme, these might not exist/be popular yet. Also, some of us use password managers that aren't browser integrated, and that further reduces the chance of me having a decent workflow for logging in to the site.

70 points by im_dario 10y ago

also https://passwordless.net/ https://passwordless.net/

An interesting idea for a few reasons. Users don't have to remember passwords, which is a strong benefit, but the user's security is now dependent on the security of their mail provider, or their own security practices in relation to the use of that mail provider, and in all likeliness their smart device. With the ubiquity of smart devices, this works from a UX point of view and could be really streamlined, but I wonder how much the meme at the top of the article is actually betraying - this is the service provider not wanting to be responsible for your security in relation to their service. I'm not suggesting that this is unreasonable per se, but the ultimate evolution of this model looks like it could (potentially dangerously) increase the value of a smaller surface area (the smart device) and put a fairly huge onus on the end user understanding and being responsible for their security. And whilst that seems ostensibly ok, we already know that the weakest link in security is the end user...so this could be putting all your eggs in one basket.

askafriend 10y ago
> but the user's security is now dependent on the security of their mail provider Let me put it this way. In many (but not all) cases I would much rather Google be responsible for my security rather than some random startup whose primary objective is to stay alive, not take security seriously.
- subkamran 10y ago
  It's funny you say that because I feel the same way as a developer. However, users of my site wanted password-based logins even though I support multiple social logins (Google, FB, Microsoft, etc.). Granted, I use PBKDF2 salting and hashing and I take security seriously, but it's interesting how average people sometimes don't trust social providers or think I'm storing their credentials to that provider.
adrianN 10y ago
Isn't user security already dependent or their mail provider? Password reset mails are pretty common.

grav 10y ago

Password-less login is a bit of a weird naming. I'd call it one-time passwords. And then I'd maybe not use email, since this clutters the inbox. Instead something like Google Authenticator or SMS passwords would be a good solution, the latter maybe being a bit expensive for the service provider.

hawski 10y ago
Password-less as in "one password less to remember/invent".
Freak_NL 10y ago
That would make having an SMS-capable phone nearby a hard requirement to simply login to some service. I am fine with offering additional authentication methods — if they are safe enough for that application — but dismissing passwords as a concept (unless you are scaling up to proper 2FA, e.g., Fido U2F) just means losing users for no good reason.
gkya 10y ago
> since this clutters the inbox Email can be deleted.

scbrg 10y ago

Con: Greylisting. My primary email uses greylisting to combat spam. This means that if we receive a mail from an unfamiliar mail server, it's getting an error message saying the mail can not be delivered at the moment, and to come back later. Properly configured servers try again several minutes later. Spam bots seldom try again, so it works well. I can see how greylisting and tokens that expire quickly can be a problem. Particularly if you have multiple servers for outgoing mails, so that the second mail attempt may come from another IP than the first.

abricot 10y ago
I'd say that this is a con for graylisting, and not for passwordless access.
- 2T1Qka0rEiPr 10y ago
  Or at least, for both.
wojt_eu 10y ago
When email comes delayed (with invalid token) can you white-list that particular sender? You'd then request another sign-in email that comes promptly this time.
aruggirello 10y ago
Well this is certainly a problem, but it's mostly limited to the first login, as (IMHO) the mail server(s) should use DKIM so greylisting can safely assume it's receiving mail from the same (legitimate) domain (the actual IP used becomes irrelevant). The first password-less login email could allow for a longer expiration, and it wouldn't be worse than a password-ful first login with email verification anyway.

Sir_Substance 10y ago

I'm glad to see this idea gaining traction. Passwords are a lazy solution that is often not needed. This type of login is ideal for websites and services that I might use less than 4 times a year. I usually log into such services by doing a password reset every time I visit their service, and this technique at least removes the risk of password leaking.

zer0tonin 10y ago

>Con: If database is compromised and passwords are reused across sites, then attackers might be able to access more sites Never heard of hashing or TLS/SRP?

manigandham 10y ago
Those alone are not enough, a compromised database storing hashed passwords behind a service that uses TLS would still allow the attackers to try common passwords and hashing algorithms to see what passwords were used. Password simplicity and reuse (especially across lots of people) is a major problem with password security in data breaches.
grenoire 10y ago
Salting is more relevant in this case.
grenoire 10y ago
Salting is more relevant in this case.

danijelb 10y ago

This is similar to what Whatsapp (and some other apps) are doing. The only difference is that they are using phone numbers.

PuffinBlue 10y ago

This implementation is just skipping the charade that passwords are where the security happens. With almost all current systems the place security really needs to happen is at the email provider. If you can hijack/intercept a users email or hack their account then it's game over with a password anyway, thanks to password resets being (almost) universally done over that channel. There's an argument that this is no bad thing as security focused email providers could potentially provide very secure access as part of their core business (unlike a startup just trying to get going). But there's still something bugging me about this implementation I can't put my finger on.

danijelb 10y ago
The only thing that's bothering me is that it is done through e-mail. I would prefer the token to arrive as a text message to my phone number. I feel like it is safer and faster. However, I understand that it is more expensive option, especially for services where you need to log in multiple times, compared to mobile apps where you log in only once.
- consp 10y ago
  SMS (in it's classical form) is highly spoofable as has been proven with TAN codes time-and-time again. It will work most of the time (sms has no guarantee of delivery as far as I know) and is somewhat secure but by no means good in any way. This relies on email, which is highly secure, smtp is not spoof-able, server and mail origins are traceable and verifiable and there is no way to intercept the message on a malicious router/switch whatever. Ow wait ...
megous 10y ago
E-mail is good enough for me as a channel. But the service should allow me to upload a PGP pub key and use it for all further communication, no exceptions (including password resets, etc.). That would secure the channel and the website would be able to trust that whoever is clicking the reset link is the owner of the key. It would also be a nice second factor. You have to have access to the email account and to the private PGP key. And it is a second factor I can fully control, unlike SMS. And it's simple and cheap for the service.

sareiodata 10y ago

For WordPress: https://wordpress.org/plugins/passwordless-login/ https://wordpress.org/plugins/passwordless-login/

subkamran 10y ago
Just what Wordpress needs.

susw 10y ago

Is it really necessary that the email link is clicked on the same device or to use a typeable token? Clicking the link on any device is enough to confirm to the server that the login attempt should be granted access. The server can then send and authentication token to the browser where the user is logging in. The downsides I can think of in that case are an attacker attempting to log in at the same time, or -- more generally -- a user thoughtlessly clicking the link when an attacker is trying to log in. The first problem can be addressed by displaying a second readable token on the login screen which the user should verify is present in the email before they click the link. That is how banks and other high security systems do it here in Norway now when you select authentication via mobile, except they use some sort of mobile communication tied to the sim card instead of email. You get a popup on your phone containing two random words from a dictionary. You confirm that the words match what the browser is currently displaying and then tap "OK". The second problem can probably be reduced by short token timeouts and using appropriate language in the email to emphasize the implication of clicking the link uncritically.

shimon_e 10y ago

This is commonly referred to as OTP and I have implemented it on a few recent projects. It is very common in Asian countries.

jpttsn 10y ago

I built (essentially) this a few weeks back, for an iOS app. Currently trying to get Apple's App Review team to agree it's a good idea. Apple has UI in App Store submission that lets you provide App Review with a demo account username/password combo, but only that. So to highlight another drawback: sometimes being able to share login credentials is a feature. Part of me thinks this ought not to be the case, and I hope I will be able to stick with password-less login.

wingerlang 10y ago
Can't you just whitelist some token for them? If the sharing is the issue you're having with them anyway.
- jpttsn 10y ago
  I'm looking at that. I don't know what email they will use to test, and I don't know if they'll look kindly at a special case for reviewers. Do you have any experience with that?

_pmf_ 10y ago

So, nothing new since Kerberos?

mherrmann 10y ago

> You can't leak passwords if you don't store passwords. That's exactly why you only store password hashes in the DB. Come on, this is a solved problem! > Pro: less implementation effort Sure. But how much of your app's total dev effort is it? Nothing. I hate the UX of having to log in by email.

gkya 10y ago
>> You can't leak passwords if you don't store passwords. > That's exactly why you only store password hashes in the DB. Come on, this is a solved problem! Isn't leaking hashes dangerous for the users' privacy though (I'm not well-versed in security, so sorry if n00b question)?
- jhasse 10y ago
  > Isn't leaking hashes dangerous for the users' privacy though (I'm not well-versed in security, so sorry if n00b question)? No, you can't compute the password from the hash.
  - MaulingMonkey 10y ago
    I'd call this dangerously un-caveated! https://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/ https://arstechnica.com/security/2012/12/25-gpu-cluster-crac... If your users passwords are sufficiently weak (and let's face it - they are) they can likely be brute forced and then matched against leaked hashes, no matter how strong your salt and hash. If you've got good users who only give you "typically" weak passwords, weak unsalted hashes will still expose said passwords. Use a strong hash. Perhaps run multiple times, bcrypt style. Salt correctly, and per-user. Somehow convince your users to actually use strong, non-reused passwords. Perhaps then there's no danger to leaking the hashes - but I'd perhaps err on the side of caution and not make the password database publicly readable nonetheless.
- dsr_ 10y ago
  Depends. If you use a nice fast hash like SHA256, yes. If you use a KDF optimized for nonoptimizability like PBKDF2 or scrypt, no.

ss64 10y ago

cons: If the customers email service goes down, then their access goes down. If your email service goes down, then the service goes down for everyone. If a major email provider is compromised, then a bunch of your accounts can be compromised. All public server-to-server email communication takes place over port 25, unsecurred clear text. That seems like a poor choice for anything security related in 2017. If anything we should be removing insecure protocols like email, telephone and SMS from the authentication chain rather than relying on them even more heavily than we already do. I hate to suggest it but authentication via something like WhatsApp might be more secure.

NoGravitas 10y ago
Server-to-server email is mostly STARTTLS (but without certificate validation) these days, I believe. Not great, but better than you think.

zbuf 10y ago

You can easily leak whether someone has an account on your website -- if I know their email address and input it, does it basically tell me? This limits your ability to reasonably error if the email address inputted is wrong. Still, a lot of "forgot password" forms seem to be subject to this, too. Also, you can only have one account per-email -- a disadvantage for some types of service, but admittedly probably a good thing for most.

jlgaddis 10y ago

> Claim: If someone has access to email account, then they can login. > Rebuttal: This is possible in a password-ful login setup via the forgot password flow. Sometimes there are additional “security questions” but this is typically easily found information. The difference here is that if/when someone uses their (unauthorized) access to my e-mail account to reset the password for this service, I will notice the next time I attempt to log in. In an ideal world, one could prevent another from gaining access to an account, service, etc. When you can't prevent something, the next best thing is detection. Here, you've just removed the ability for a user to detect that their account is compromised -- and worse, you're trying to spin it like it's a good thing. Also, greylisting. Also, what if I wanted to log in to my account from my phone or a mobile device? I choose not to receive e-mail on my phone (only alerts/notifications) and I'm certainly not the only one. It sounds like someone pitched this idea at a meeting ("Hey, I know! No passwords!") and the next 10 minutes was spent rationalizing all its problems away before declaring it as the one true solution.

demonshreder 10y ago
>The difference here is that if/when someone uses their (unauthorized) access to my e-mail account to reset the password for this service, I will notice the next time I attempt to log in. I am assuming the indicator would be an email from a service stating password reset but if the person has access to your email account, the obvious thing to do would be delete such an email. There is no difference. Passwordless login is basically piggy backing on the security of the email account. You'd have to login to a site anyway but you are just logging in to your email which is assumed to be protected better.
- jswny 10y ago
  I think OP meant that he will clearly realize if someone used his email account to reset his password because next time he tries to log in his old password will no longer work. However with passwordless authentication, someone with access to your email account could issue your account for potentially a long period of time without you noticing. You would still be under the impression that your account is secure.

kodfodrasz 10y ago

> Strawperson argument Will this newspeak fury ever stop?

mike-cardwell 10y ago

Loosely related. Why doesn't my web browser speak IMAP? If I could just enter my IMAP details into my browser settings, then it could silently IDLE on my Inbox, and inform my currently open http://example.com/ http://example.com/ tabs when it receives email from an @example.com address. You'd need to stick it behind a "This website wishes to be notified about email you receive from it" prompt. But then you'd be able to do all sorts of clever stuff, including streamlining email validation checks and password resets. Everybody has email. You could create a "Login with Email" function really easily on your website, and it would work for even more users than the "Login with Facebook" option.

kodfodrasz 10y ago
why should the browsers speak every protocol? Why should everything be done through the browsers, instead of better specialized programs? Why should protocols designed for one problem be abused to solve other problems? Why not use client certs instead?
- mike-cardwell 10y ago
  "Why should the browsers speak every protocol?" Why should browsers only speak HTTP? Who made that rule? "Why should everything be done through the browsers, instead of better specialized programs?" I never said "everything". "Better specialised programs"? What are you talking about? I'm talking about essentially being able to access email from a webpage. There is no "better specialised program" for doing that. I'm not talking about webmail. I'm talking about automated emails. "Why should protocols designed for one problem be abused to solve other problems?" What you call "abuse", I call "use". "Why not use client certs instead?" This has nothing to do with anything I've mentioned.
  - kodfodrasz 10y ago
    No better program to access email from anywhere than a browser. Have you heard about MUA-s? Special mails should be used for authentication which would specially handled by the browser accessing your mailbox. This is abusing the mail protocols in my opinion. Certificate based auth does have something to with this: an existing, partially supported solution for auth with no magic needed and no need to reinvent the wheel, with hacks and extra complications.

anoctopus 10y ago

>Claim: With this setup, I can’t login easily with my LastPass, 1Password, etc browser extension. >Rebuttal: This is a legitimate claim but it’s equally plausible to use an email integrated browser extension. You could do that, but since this isn't a very common login scheme, these might not exist/be popular yet. Also, some of us use password managers that aren't browser integrated, and that further reduces the chance of me having a decent workflow for logging in to the site.