Ask HN: Why aren't one-time sign in links more popular for authentication?
Tying a OTP to an email appears to be more secure than the cluster that is remembering and managing passwords.
197 comments
We have tried this for a while and the following reasons made us kill it:
1. Email delivery latency: depending on the service you use, the time it takes to deliver emails to the user can vary. Worst case I encountered was up to 20 minutes delay when there were issues with Mailgun.
2. Usability: you have to leave your current app and switch to your mail client. You may be on a device where you don't have a mail client installed at all, so you have to provide a password login option as well.
3. The sign in dialog gets more complicated and it's hard to explain to users how it works as it is not all that common. This also had effects on sign up/sign in dialog design which we found to have a negative impact on conversion rates.
1. Email delivery latency: depending on the service you use, the time it takes to deliver emails to the user can vary. Worst case I encountered was up to 20 minutes delay when there were issues with Mailgun.
2. Usability: you have to leave your current app and switch to your mail client. You may be on a device where you don't have a mail client installed at all, so you have to provide a password login option as well.
3. The sign in dialog gets more complicated and it's hard to explain to users how it works as it is not all that common. This also had effects on sign up/sign in dialog design which we found to have a negative impact on conversion rates.
From a user standpoint the delivery latency is really what kills it for me. I use one or two websites that still have one-time sign in links and it's always a tossup whether or not I can actually get in within a few minutes. If the email arrives an hour later I've moved on with my life and I can't imagine it is any different for other people.
I've experienced that too.
The issue isn't with the user's email. The issue is with the site's email provider. If the email server sending out the one time links is under heavy load or for some reason has a backlog, it may take a while for the links to actually get to the user.
This usually happens because whatever service the site is using to handle sending out emails is under heavy load, having issues, or is rate limiting the site due to a sudden spike in logins.
If this happens for any reason, it failure cascades because the more people try to log in, the longer it will take for everyone to get a valid link.
At least with a standard TOTP token or the like, if the service is under load it will eventually work if you keep trying (versus not working for longer the more people try).
Hell this method also runs into the issue of getting flagged as spam or getting blacklisted due to ~~the algorithm~~ for one reason or another. This is doubly likely if a sudden burst of traffic to a site results in them sending out a mass wave of near identical emails.
Now non-tech users can't log in at all since they "never get the email at all".
Email is a wonderful thing but it is painfully fragile and doesn't handle time sensitive stuff well at scale (due to queuing, routing issues, and spam filters).
This usually happens because whatever service the site is using to handle sending out emails is under heavy load, having issues, or is rate limiting the site due to a sudden spike in logins.
If this happens for any reason, it failure cascades because the more people try to log in, the longer it will take for everyone to get a valid link.
At least with a standard TOTP token or the like, if the service is under load it will eventually work if you keep trying (versus not working for longer the more people try).
Hell this method also runs into the issue of getting flagged as spam or getting blacklisted due to ~~the algorithm~~ for one reason or another. This is doubly likely if a sudden burst of traffic to a site results in them sending out a mass wave of near identical emails.
Now non-tech users can't log in at all since they "never get the email at all".
Email is a wonderful thing but it is painfully fragile and doesn't handle time sensitive stuff well at scale (due to queuing, routing issues, and spam filters).
> The issue isn't with the user's email. The issue is with the site's email provider. If the email server sending out the one time links is under heavy load or for some reason has a backlog, it may take a while for the links to actually get to the user
That is not completely true. I've been operating my own mail server for almost a decade, since I am the only person using it the volume of email I send out is almost none.
I've observed on more then one occasion that sending an email to my gmail or my fathers gmail account can sometimes take 20 minutes or more to show up in gmail inbox although I know that google accepted the email as soon as it was sent.
That is not completely true. I've been operating my own mail server for almost a decade, since I am the only person using it the volume of email I send out is almost none.
I've observed on more then one occasion that sending an email to my gmail or my fathers gmail account can sometimes take 20 minutes or more to show up in gmail inbox although I know that google accepted the email as soon as it was sent.
You'd have to look at your logs when it happens but google has a habit of tarpitting(i.e. repeatedly delaying email receipt) emails from servers they don't necessarily "trust". For large providers (i.e. those that would be used for handling one-time link emails), this normally isn't a problem however for small or self hosted email servers it can be from time to time.
I'm not sure what all goes into ~~the algorithm~~ that google uses to decide to tarpit emails from a server but I'd make sure that you have your SPF, DKIM, and DMARC all set up properly to give google as little of an excuse to dislike your server as possible.
It's not a great solution but I've long since given up on any attempt at self-hosting email and just use my own domain with protonmail at this point since the industry seems to be so hostile to self-hosting.
I'm not sure what all goes into ~~the algorithm~~ that google uses to decide to tarpit emails from a server but I'd make sure that you have your SPF, DKIM, and DMARC all set up properly to give google as little of an excuse to dislike your server as possible.
It's not a great solution but I've long since given up on any attempt at self-hosting email and just use my own domain with protonmail at this point since the industry seems to be so hostile to self-hosting.
Thank you. I've checked my logs and everything looks normal on my end and I do suppose it is some kind of tarpitting, but it doesn't show in the logs.
I do have DKIM, strict SPF and DMARC policies, MTA-STS, SMTP TLS Reporting, latest TLS support and valid certificates, there is nothing else I can do on my end.
I do have DKIM, strict SPF and DMARC policies, MTA-STS, SMTP TLS Reporting, latest TLS support and valid certificates, there is nothing else I can do on my end.
One other thing you might be able to try is to try reaching out to Google about it if it's a consistent issue. There is a contact form floating around somewhere for mail server operators to reach out to the GMail infra team about this kind of thing but IDK where it is or if they even still check it. I wouldn't put to much faith in it though, particularly considering Google's reputation wrt support.
It’s true, we send millions of mails per month and Google doesn’t give 2 shits about anyone’s email deliverability issue. All avenues of contact are black holes on that front regardless of how much you pay them.
lol "try reaching out to google" that was my good laugh for the day.
> The issue isn't with the user's email. The issue is with the site's email provider.
Actually, it could be either. Postmark (the email provider for a bunch of sites) monitors "time to inbox" for several user email services: https://status.postmarkapp.com/. Apple, in particular, seems to frequently add 2+ minute delays on the receiving end. (The "source" link above the charts describes how Postmark collects the data.)
Actually, it could be either. Postmark (the email provider for a bunch of sites) monitors "time to inbox" for several user email services: https://status.postmarkapp.com/. Apple, in particular, seems to frequently add 2+ minute delays on the receiving end. (The "source" link above the charts describes how Postmark collects the data.)
> The issue isn't with the user's email
As an email layman, I don’t fully buy this, can you explain? I’ve sent emails with multiple CC’s and most get it quick while one or two people have to wait for it to hit their inbox for multiple minutes. I assume they all leave my service at same time and the delay is caused by the receiving mail server.
As an email layman, I don’t fully buy this, can you explain? I’ve sent emails with multiple CC’s and most get it quick while one or two people have to wait for it to hit their inbox for multiple minutes. I assume they all leave my service at same time and the delay is caused by the receiving mail server.
So I'll preface that I'm by no means an expert.
The issue can occasionally be the user's email provider but for the most part issues with implementing one-time links will be the site's responsibility/a problem on their end.
As for email occasionally being super slow, Google and Microsoft (to a lesser extent) will tarpit(repeatedly delay the acceptance of emails from a specific address or entire domain) emails arbitrarily. This normally isn't anything meaningfully repeatable and is essentially ~~the algorithm~~ arbitrarily deciding it dislikes some certain email, email address, or server. Those emails will eventually get to their recipient but effectively get frozen in time for a bit before getting delivered.
For normal person to person emails, this boils down to bad luck and occasional inconvenience however for any heavily templated email (like say an email containing one-time links), this means something on the site's side is causing the emails to appear as spam or spam-like to the recipient server. So technically it is the user's email server causing the delay but it's usually due to something in particular on the site's side be it a domain or server configuration or something about the email contents.
The issue can occasionally be the user's email provider but for the most part issues with implementing one-time links will be the site's responsibility/a problem on their end.
As for email occasionally being super slow, Google and Microsoft (to a lesser extent) will tarpit(repeatedly delay the acceptance of emails from a specific address or entire domain) emails arbitrarily. This normally isn't anything meaningfully repeatable and is essentially ~~the algorithm~~ arbitrarily deciding it dislikes some certain email, email address, or server. Those emails will eventually get to their recipient but effectively get frozen in time for a bit before getting delivered.
For normal person to person emails, this boils down to bad luck and occasional inconvenience however for any heavily templated email (like say an email containing one-time links), this means something on the site's side is causing the emails to appear as spam or spam-like to the recipient server. So technically it is the user's email server causing the delay but it's usually due to something in particular on the site's side be it a domain or server configuration or something about the email contents.
In addition to tarpitting, a variety of transient issues can impact mail delivery. Email is all about queues and you can run into issues where servers crash or get bogged down by large email traffic.
On business systems, sometimes DLP rules impact delivery times.
On business systems, sometimes DLP rules impact delivery times.
[deleted]
Gmail does it to external mail servers as one of many mitigation strategies.
I mean, when you send batches of mails to gmail, it lets them through first, then depending on its whim it starts throttling or outright blocking them.
Once in a while, it changes its handling of DKIM or SPF or god knows what and the only thing you can expect from them is an SMTP error message.
I mean, when you send batches of mails to gmail, it lets them through first, then depending on its whim it starts throttling or outright blocking them.
Once in a while, it changes its handling of DKIM or SPF or god knows what and the only thing you can expect from them is an SMTP error message.
[deleted]
Then you haven't used it for very long. Besides that, more exists than some tech giant's gambit to gather and exploit as much user information as they can. Nobody should use gmail, unless they are forced to by their job (in which case they should try to change it if they are in a position to).
What email service do you recommend?
Any one in a privacy-friendly location. There's a ton of German providers (posteo, tutanota, mailbox.org, etc) which are always safe choices. Emphatically not Protonmail, as it makes promises it doesn't deliver on and has a very strange architecture for it's security besides.
[deleted]
I resonate deeply with this comment.
As an extension to your second point, sometimes I want to login to a service on a shared/public computer out of necessity. I'd really not want to login into my email on said computer too.
As an extension to your second point, sometimes I want to login to a service on a shared/public computer out of necessity. I'd really not want to login into my email on said computer too.
A good one-time-sign-in-link implementation will send a link to authenticate a session elsewhere, so you can click the link on your phone to complete login on the computer.
That assumes the user can click the link on the phone. The reason a user might be "using a shared/public computer out of necessity" might be because the user does not at that moment have working Internet on the phone. For instance, the user might be outside the home area without a roaming agreement, or the user might be out of prepaid credits on the phone.
That's kind off what Microsoft does in Microsoft Authenticator. It doesn't ask for password, it sends notification to you phone app and asks you to tap "65". The app then shows 3 numbers, one is 65. You log in on the other device after tapping. No passwords entered at all.
They did a nice job on that one.
They did a nice job on that one.
We did this for Mozilla Hubs (hubs.mozilla.com) specifically so people can easily sign in from within a VR headset which doesn't have a password manager and which is hard to type in.
However, the problem is that this goes so much against user expectations it just confuses people and they end up going through the grueling version of typing the long link in by hand in VR since they can't imagine it could be as easy as opening it on their phone. (We of course, call this out in the prompt, but nobody reads that.)
However, the problem is that this goes so much against user expectations it just confuses people and they end up going through the grueling version of typing the long link in by hand in VR since they can't imagine it could be as easy as opening it on their phone. (We of course, call this out in the prompt, but nobody reads that.)
What if we just allowed sending one-time links not only via mail, but via Telegram, Whatsapp, Messenger, Signal and a bunch of other options?
As a counterpoint to this, I quite dislike this approach, especially when the auth is a link instead of a OT2P, because now whatever I am accessing has metadata and can cross-correlate data from other providers about my phone. Amazon is one in particular that I experience, and I never click the link, and rather just type it out by hand on the system I am already trying to log in via.
I just assume my every keypress on a public/shared PC gets keylogged, so a password is not a great option either.
>sign up/sign in
Why were clear terms like login/register/logout replaced with a “sign ...”? I get confused twice a week by these, especially because the difference between “in” and “up” is so subtle (and overloaded, like “sign up for a meeting at friday”, unrelated to registration routine). Sorry for offtopic, but it is really annoying. Is it more linguistically correct or just a hipster thing?
Why were clear terms like login/register/logout replaced with a “sign ...”? I get confused twice a week by these, especially because the difference between “in” and “up” is so subtle (and overloaded, like “sign up for a meeting at friday”, unrelated to registration routine). Sorry for offtopic, but it is really annoying. Is it more linguistically correct or just a hipster thing?
I'm not sure they were ever replaced; the terms co-exist. I believe the terms all stem from the general concept of writing a name on a piece of paper.
To "register" your interest in an something, you might sign a piece of paper, or instruct a person to "sign [you] up".
To show that you entered a physical event, you would sign an entry log on a piece of paper, then having "logged in" or "signed in", and then do the opposite on your way out.
Similarly you might refer to reproducing your physical signature as having "authenticated" yourself, if there's something to compare it to.
What makes one particular set of terms the right set given the apparent origins?
To "register" your interest in an something, you might sign a piece of paper, or instruct a person to "sign [you] up".
To show that you entered a physical event, you would sign an entry log on a piece of paper, then having "logged in" or "signed in", and then do the opposite on your way out.
Similarly you might refer to reproducing your physical signature as having "authenticated" yourself, if there's something to compare it to.
What makes one particular set of terms the right set given the apparent origins?
I researched this several years ago and for various reasons it's best to use: sign up, log in, and log out.
can you elaborate on the basis for this? it sounds interesting, but the rationale isn't obvious.
Interesting. I've always liked "sign up", "sign in", and "sign out", because they were older and more widely used before computing. "Sign up" was used to refer to subscribing, for example, to a magazine. "Sign in" and "sign out" were what they said for the guestbook at a hotel.
> "sign ..."
Sometimes literally that, with an ellipsis hiding the part that would otherwise distinguish between alternatives, so you just have to click and guess.
Sometimes literally that, with an ellipsis hiding the part that would otherwise distinguish between alternatives, so you just have to click and guess.
> like “sign up for a meeting at friday”, unrelated to registration routine
Are you not registering yourself for the single meeting? Adding yourself to the list?
Are you not registering yourself for the single meeting? Adding yourself to the list?
I usually prefer the terms "sign up" and "log in" as they are different enough to avoid confusion.
> 1. Email delivery latency
This is particularly true when the recipient has enabled Greylisting[0] and delivery has to be attempted multiple times (which is perfectly fine from the point of view of the RFC standards). In view of this, email delivery rather resembles real-world postal package delivery (and not so much the instantaneous delivery of, say, phone calls).
[0] https://en.wikipedia.org/wiki/Greylisting_(email)
This is particularly true when the recipient has enabled Greylisting[0] and delivery has to be attempted multiple times (which is perfectly fine from the point of view of the RFC standards). In view of this, email delivery rather resembles real-world postal package delivery (and not so much the instantaneous delivery of, say, phone calls).
[0] https://en.wikipedia.org/wiki/Greylisting_(email)
This can be particularly fun if the sender uses Amazon SES for example, because Amazon randomly rotates through its mail servers on each retry attempt, so a simple greylisting implementation (based on exactly matching the full IP) delays the mail by not just one, but possibly multiple retry intervals until by chance Amazon happens to use to original server again.
So you either need to whitelist Amazon SES (and possibly a few other providers behaving similarly), or use a greylisting implementation which doesn't match the full IP (I think Mailcow by default e.g. uses /19 for matching IPv4 addresses).
A previous mail hoster of mine did the former, i.e. Greylisting based on the full IP, and what was even worse, their support staff totally denied any knowledge of it and tried to claim it wasn't their fault that any e-mails from Amazon (Amazon itself and anything using SES) would arrive with random amounts of large delay.
So you either need to whitelist Amazon SES (and possibly a few other providers behaving similarly), or use a greylisting implementation which doesn't match the full IP (I think Mailcow by default e.g. uses /19 for matching IPv4 addresses).
A previous mail hoster of mine did the former, i.e. Greylisting based on the full IP, and what was even worse, their support staff totally denied any knowledge of it and tried to claim it wasn't their fault that any e-mails from Amazon (Amazon itself and anything using SES) would arrive with random amounts of large delay.
Is it possible to solve by some kinds of warming up? AFAIK greylist is IP-based. We can send email at regular time so all the sender IP can keep in list.
But email does has many uncertainty like spam detection and others to slow the process after SMTP server receive it.
But email does has many uncertainty like spam detection and others to slow the process after SMTP server receive it.
How would that work? Send an email to every customer (domain, so pick a single customer at every domain) and send them an email with a fake login, or a note that says please disregard?
Aside from that being spam, it's also likely to get legit emails stuck in spam filters as people start marking them as spam.
Secondly, I think most of the largest providers don't really grey list any longer. They seem to have moved to inbound throttling. So your first email goes through but then if you send a rash of mail, you end up seeing the throttle on the back side.
Aside from that being spam, it's also likely to get legit emails stuck in spam filters as people start marking them as spam.
Secondly, I think most of the largest providers don't really grey list any longer. They seem to have moved to inbound throttling. So your first email goes through but then if you send a rash of mail, you end up seeing the throttle on the back side.
> Send an email to every customer (domain, so pick a single customer at every domain)
Greylist is allow/block based on sender IP, not receiving metadata, so I guess pre-send mail from the IP might help, but yes, other rules might slow down.
Greylist is allow/block based on sender IP, not receiving metadata, so I guess pre-send mail from the IP might help, but yes, other rules might slow down.
It's not just connect based, you have to connect and send an email. Which would be spam. Most systems I've worked on score based on how much your server looks like it's doing its job and moving on.
Long connection with inactivity get tagged, scored and disconnected.
Connecting without sending an email leaves you in the grey list queue.
There is to my knowledge not a great way to pre-warm for grey-listing
Long connection with inactivity get tagged, scored and disconnected.
Connecting without sending an email leaves you in the grey list queue.
There is to my knowledge not a great way to pre-warm for grey-listing
One more issue is if you're using eg microsofts webmail (office? hotmail? I'm not sure what it's called but my university had it) the links will get queried automatically to "scan them for viruses" which tends to expire them.
We ran into this, where the Outlook client would scan one-time login links from SalesForce (iirc). Huge pain to work around.
It's bad but I also argue that generally GET should not change state. It seems that weirdly email is the only place that allowed GET URL to change state (like unsubscribe link).
I ran exactly into this problem with linear.app (which uses passwordless login with "magic" links) and Outlook / Office 365. Only solution has been to ask linear.app to disable the links for our account and keep only the one-time code that we manually copy-paste.
4. Email delivery period. Using AWS Simple Email Service, you're actually sharing an email server IP address with other accounts. At times those accounts can get the IP address added to spam lists. All the sudden your emails stop getting received on some clients.*
* Solution to this is to pay $$ / month to get a dedicated IP address, then never let it get added to a spam list.
* Solution to this is to pay $$ / month to get a dedicated IP address, then never let it get added to a spam list.
> 4. Email delivery period. Using AWS Simple Email Service, you're actually sharing an email server IP address with other accounts.
They also randomly rotate through their mail servers on each retry attempt, so a simple Greylisting implementation based on matching the full IP address can delay your emails for not just one retry interval, but several (until by chance Amazon happens to reuse the IP of the original delivery attempt).
They also randomly rotate through their mail servers on each retry attempt, so a simple Greylisting implementation based on matching the full IP address can delay your emails for not just one retry interval, but several (until by chance Amazon happens to reuse the IP of the original delivery attempt).
Dedicated IPs aren’t great because they’re completely untrusted. Better to sign up with a smaller email provider than mailgun/ses
SES warms up dedicated IPs for several weeks by using them for regular SES traffic during the warmup phase: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/dedica...
I work with Twilio SendGrid. What do you mean? IPs are the de facto way that reputation is tracked and a dedicated IP’s trust is based on your sending habits. How would a smaller provider be better? The only thing that I can think is similar IP ranges can also influence delivery, so you may want a dedicated range for transactional email. I don’t see smaller providers as able to do that.
A new dedicated IP is unknown and some providers will automatically treat it as untrusted and give it a lower score.
A smaller email provider can give you a shared IP that has other users and is therefore already whitelisted. Provided the email provider has good anti-spam approaches (e.g. enforced DKIM verification), you should have better luck with that shared IP over a dedicated one if you only send a few thousand emails a month.
A smaller email provider can give you a shared IP that has other users and is therefore already whitelisted. Provided the email provider has good anti-spam approaches (e.g. enforced DKIM verification), you should have better luck with that shared IP over a dedicated one if you only send a few thousand emails a month.
ah, I see what you are saying. Better shared pool management by the larger senders would help, but a smaller sender should be able to more aggressively protect their shared IPs; I agree in principle. This is extra important for infrequent sending.
I still contend that a dedicated IP is superior for deliverability reputation as long as you are sending enough email. For a brand new (to you) dedicated IP, it will need to be warmed up (gradually increase the amount of traffic it sends). There are automated and manual processes to accomplish that, including "pre-warmed" dedicated IPs that were previously in a "good enough" shared pool.
I still contend that a dedicated IP is superior for deliverability reputation as long as you are sending enough email. For a brand new (to you) dedicated IP, it will need to be warmed up (gradually increase the amount of traffic it sends). There are automated and manual processes to accomplish that, including "pre-warmed" dedicated IPs that were previously in a "good enough" shared pool.
We ended up purchasing a dedicated IP from Mailgun. This solves the spam/latency problem mostly, but brings about new problems.
What other problems do you face with a dedicated IP?
You have more management work for your team. If something's wrong with it, it's mostly your problem.
I initially thought it was a "problem solved" thing by paying the money. Ended up causing us regular work (not much, but still).
I initially thought it was a "problem solved" thing by paying the money. Ended up causing us regular work (not much, but still).
Not MailGun, but we have 3 dedicated IPs with SendGrid and one problem is that there are spamlists and ISPs that block or mark down IP blocks owned by SendGrid so you get no real advantage from the dedicated IP. I wish you could "bring your own IP" to these services.
Heh, it would get tagged as a sendgrid ip after a few transactions.
If I may add:
4. Some email clients still break links in emails
5. Proper links require HTML; otherwise you rely on the email client recognizing a URL as such (which brings us back to 4).
6. The email might mistakenly get recognized as spam.
4. Some email clients still break links in emails
5. Proper links require HTML; otherwise you rely on the email client recognizing a URL as such (which brings us back to 4).
6. The email might mistakenly get recognized as spam.
4. Gmail (atleast on Android) will try to open the link in a sort of Webview, which is never ideal. All the browser options are gone, plus I don't need to trust Gmail with the ability to read screen contents.
This is exactly the reason why I hate sites that use one-time email sign-in links. The link opens in Webview, then you have to click a separate button to reopen the page in Safari, but by that time the token is marked as used, so you can't login except in this temporary window that is going to immediately disappear the second you perform any other action.
regarding point 3, I feel like familiarity bias is such a difficult thing to overcome sometimes with UX. However poor the experience of the standard signup/auth process is, users have already learned the complexity, and the risk is super high when you're showing people a totally new type of hurdle they have to jump to access your product. Even if it's less complex objectively, if they fail the first time there's a high chance that user is never coming back.
But I think authentication in general is a problem which really needs to be solved, and in a standards-based way. For instance, with connecting to public wifi networks (i.e. at an airport), it's absurd to have to go through a web page every time to log in. Also with the proliferation of IoT devices, it's always painful to go through the process of connecting it to my bluetooth and/or wifi. There should be some kind way to handle trust systematically through my smartphone without having to manually type a bunch of passwords.
But I think authentication in general is a problem which really needs to be solved, and in a standards-based way. For instance, with connecting to public wifi networks (i.e. at an airport), it's absurd to have to go through a web page every time to log in. Also with the proliferation of IoT devices, it's always painful to go through the process of connecting it to my bluetooth and/or wifi. There should be some kind way to handle trust systematically through my smartphone without having to manually type a bunch of passwords.
I like the implementation of https://www.fast.co/.
1. There is a dependency on speed of email delivery. May be use SMS as well?
2. Personally, I didn't find it too difficult. We run into same issue if we have MFA
3. fast.co experience is pretty clean. Give it a try
Disclaimer: I am not affiliated with fast.co
1. There is a dependency on speed of email delivery. May be use SMS as well?
2. Personally, I didn't find it too difficult. We run into same issue if we have MFA
3. fast.co experience is pretty clean. Give it a try
Disclaimer: I am not affiliated with fast.co
One more: Gmail app on iPhone forces you to open links within the app, meaning you can’t actually login with Safari proper (the session/cookies aren’t shared).
Super frustrating, and something Apple should clamp down on (any app that opens web links needs to provide a full “open in Safari” option that isn’t an in-app browser).
Super frustrating, and something Apple should clamp down on (any app that opens web links needs to provide a full “open in Safari” option that isn’t an in-app browser).
And don't forget the security implication that someone with access to your email can log in to your account undetected.
With traditional password reset by email, at least when I try to login next, my password won't work and I'll know something might be up and can change my email password.
With traditional password reset by email, at least when I try to login next, my password won't work and I'll know something might be up and can change my email password.
My main problem with it they seem to assume that you have an email client on the device you want to access the site. I don't have mail account setup on my iPad so I need to mess around with AirDrop or iCloud to share the code.
(1) is tractable. A number of email sending providers offer SLAs around delivery latency. Some also provide significant deliverability resources to help senders mitigate the risk of spam foldering.
Source: I work for SparkPost and we do all of the above.
Source: I work for SparkPost and we do all of the above.
Yeah. In theory it’s a neat idea—in practice I hate it.
There’s one service that I literally can’t log in to because the link has always expired by the time I receive it.
There’s one service that I literally can’t log in to because the link has always expired by the time I receive it.
Oh, this is so terrible. I hate this approach with a passion.
E-mail is NOT INSTANTANEOUS. It was never meant to be. It happens to arrive quickly for most people most of the time, but you should never, ever, base a service on that.
Many systems have greylisting in place: a new sender gets a 4xx reply, and is allowed through only on subsequent retries after a pre-set time period. This is often as much as 30-60 minutes. It's a good approach to reduce spam, it turns out a lot of spamming software does not bother to retry, or doesn't want to incur the cost.
So, if you try this OTP-over-Email approach, you end up with frustrated customers, who 1) have to wait up to 60 minutes, 2) their OTP doesn't work, because you expired it after 5 minutes.
It's terrible. Don't do it.
E-mail is NOT INSTANTANEOUS. It was never meant to be. It happens to arrive quickly for most people most of the time, but you should never, ever, base a service on that.
Many systems have greylisting in place: a new sender gets a 4xx reply, and is allowed through only on subsequent retries after a pre-set time period. This is often as much as 30-60 minutes. It's a good approach to reduce spam, it turns out a lot of spamming software does not bother to retry, or doesn't want to incur the cost.
So, if you try this OTP-over-Email approach, you end up with frustrated customers, who 1) have to wait up to 60 minutes, 2) their OTP doesn't work, because you expired it after 5 minutes.
It's terrible. Don't do it.
As a user, I have the same issue but in the opposite direction. My greylisting config requires only 1 minute wait, but many providers only retry after 5-10 minutes.
Usually I can request a new login (or email verification) link and it will go through immediately. It does not work with Sendgrid-based services though, as Sendgrid rotates the IP used by the service for every mail.
Usually I can request a new login (or email verification) link and it will go through immediately. It does not work with Sendgrid-based services though, as Sendgrid rotates the IP used by the service for every mail.
Funny that SMS second factor auth took off. I remember that the sometimes hour long delays in SMS
.
I actual was astonished by the simplicity of sign in links when for the first time using gather.town . I have seen then also in banking (revolute) with IP address pinning which proved to be annoying because this randomly switched depending on network availability.
I actual was astonished by the simplicity of sign in links when for the first time using gather.town . I have seen then also in banking (revolute) with IP address pinning which proved to be annoying because this randomly switched depending on network availability.
Email has been nearly instantaneous for me for the past decade or so. Either it arrives in a 30 second window, or never. Usually 2-5 seconds.
I run an MTA sending billions of emails daily. Most mail is delivered in seconds, but there is a long tail that can take days (myriad of reasons involving recipient mail servers, dns, sending behavior , etc). It would not be fun to have your log in attempt come in a couple days later. 99.9%+ you will be just fine, but how do you handle those people who fall through into long-delay land?
email is supposed to be dependable - as a protocol - it should always arrive. This dependability comes at the price that in some edge cases it must arrive slowly. There should be no 'never' arrive, although I realize that many services now effectively keep email from actually being seen by the user in the name of combating the various problems a free, anonymous, dependable message delivery protocol inevitably give rise to.
I have both a personal G Suite domain (formerly "Google Apps For Your Domain") and my employer's G Suite account where in both cases I've experienced 5+ minute delays on a semi-frequent basis.
Thirty seconds is not instantaneous and is much slower than typing a password. The only server that shows mail the instant it's sent is the one I run for my personal use, which is a bad solution for most.
"never" doesn't feel instantaneous though.
Joking aside, email never coming is a pretty common occurence for me on new services, especially small orgs (local clubs, small merchants)
Joking aside, email never coming is a pretty common occurence for me on new services, especially small orgs (local clubs, small merchants)
That's great, good for you! But E-mail is not guaranteed (nor designed) to be instantaneous.
Right, it isn't authentication, it is only account control. If you have to login to your email anyway. We just need simpler 2FA options. FIDO is moving the ball forward in the right direction but they don't seem willing to push the final steps.
Why can all instant messengers do this “instant” part and email cannot? I’m aware of mta chains, decentralization, etc, but heck.
Because, as jwr says, it was never meant to be. The mental model is that of regular mail that gets collected at post offices, then split by major destination, sent on, and finally ends up in a mailbox.
Mail servers do not even have to be on the internet (https://en.wikipedia.org/wiki/Non-Internet_email_address), or on a network at all. It was fairly normal to have a time sharing system dial in to a mail server every day for a few minutes to exchange mail messages (https://en.wikipedia.org/wiki/UUCP#Mail_routing))
Also, of course, it is harder to accomplish in a decentralized system that isn’t controlled by a single party.
Mail servers do not even have to be on the internet (https://en.wikipedia.org/wiki/Non-Internet_email_address), or on a network at all. It was fairly normal to have a time sharing system dial in to a mail server every day for a few minutes to exchange mail messages (https://en.wikipedia.org/wiki/UUCP#Mail_routing))
Also, of course, it is harder to accomplish in a decentralized system that isn’t controlled by a single party.
Excellent points. As someone who has carried UUCP mail on floppies to computers not connected to the network at all, I can relate :-)
> ...because you expired it after 5 minutes.
Just increase the time? 30 mins will do. Especially if it's only one time use.
Just increase the time? 30 mins will do. Especially if it's only one time use.
There is a service that I use that uses these. About 90% of the time what happens is I go there to use it, get the thing that says "check your email!", and then get distracted on my way to my email.
By the time I finally get to my email, the link is expired and I just give up.
Consequently, I almost never use that service.
By the time I finally get to my email, the link is expired and I just give up.
Consequently, I almost never use that service.
It's inconvenient. That's the primary reason why it won't gain mass adoption since any obstacle to your service will lower the registration / engagement metrics.
With password managers built into all modern browsers, casual users (which, lets be honest here, are by far the most of the web users) do not have to worry about typing passwords. Security be damned. If it is not invisible to the user, they will reject it.
With password managers built into all modern browsers, casual users (which, lets be honest here, are by far the most of the web users) do not have to worry about typing passwords. Security be damned. If it is not invisible to the user, they will reject it.
Password management is better, not worse, for security.
What is your argument for that? That people will choose better passwords (unique and long) since they don't need to remember them?
The Achille's heel of password managers is if someone accesses your computer (physically or remotely) they can probably access all your accounts. <-- and I've seen this happen (not to me)
The Achille's heel of password managers is if someone accesses your computer (physically or remotely) they can probably access all your accounts. <-- and I've seen this happen (not to me)
Yes. The huge huge huge majority of credential attacks are stuffing and phishing. Unique passwords prevent stuffing. We observe that everybody reuses passwords unless they use a password manager. Password managers with auto fill can also provide some defense against phishing since they won’t auto fill.
The Achilles heel you mention matters very little since it is a very rare threat model and it would be unreliable to assume that access ends at some point rather than that the adversary simply installed some persistent malware to read all future passwords.
The Achilles heel you mention matters very little since it is a very rare threat model and it would be unreliable to assume that access ends at some point rather than that the adversary simply installed some persistent malware to read all future passwords.
> it is a very rare threat model
I agree, but perhaps password managers aren't a one-size-fits-all solution. People in high risk situations (e.g., admin @ crypto companies) that are likely to be specifically targeted, might be better served without a password manager. But yes, if RDP, e.g., is left on and open then a keylogger could be installed anyways...
I agree, but perhaps password managers aren't a one-size-fits-all solution. People in high risk situations (e.g., admin @ crypto companies) that are likely to be specifically targeted, might be better served without a password manager. But yes, if RDP, e.g., is left on and open then a keylogger could be installed anyways...
Admins at crypto companies should be getting security advice from their security gurus rather than from the web. It is reasonable to suggest that most people use a password manager. For the few people where this isn't good enough, they likely know who they are.
It's much more difficult to compromise someone's computer than it is to obtain/get one of their passwords thru phishing/guessing and then try the combination on a bunch of sites.
It's -vastly- better for casual users to have secure, single-use passwords instead of what most casual people do: have 1-2 insecure passwords with variations. Thus allowing any phisher to get access to everything anyways.
Just because something isn't perfect doesn't mean it is not an improvement.
It's -vastly- better for casual users to have secure, single-use passwords instead of what most casual people do: have 1-2 insecure passwords with variations. Thus allowing any phisher to get access to everything anyways.
Just because something isn't perfect doesn't mean it is not an improvement.
If they can access you computer they can probably also access your email and get the sign-in links.
This is not possible if your password manager itself requires a password. Unless you mean "password managers don't work because someone might know the master password" which is true, but realistically the alternative is just using the same weak password all over the web, which is way worse.
Fedex have a login with an OTP via email. The OTP expires in 15min, while the email came 30+ minutes later. I exhausted the 5 tries because I keep hitting the button. I had to wait another days for an International delivery!
Imagine that.
Imagine that.
I know a guy who as a matter of course sets his passwords to long random strings. When he wants to log into something, he then uses the sites’ “forgot password” as his “OTP” to assign a new one, log in with it. He does not store the random string, so his password is random, he doesn’t know it. Sounds like a lot of trouble, but my point is “forgot password” can kinda be otp for those paranoid enough.
This is fine until a platform or service decides to lock his account or permanently disable it because of frequent password reset attempts. If he’s lucky, he may be able to use a phone number connected to the account to get in. If not, then that’s the end of it. Seeing the kind of login patterns that many sites track for security reasons and how bad their judgments can be, I personally wouldn’t take such a risk.
Given a scheme is only ever as secure as its recovery process, he's not wrong.
I do that for some services I rarely use. That works actually fairly well.
OTP, with extra steps :D
Because when I want to login I WANT to login - It's amazing how much it's spend on shaving milliseconds yet having such an indirection doesn't ring a bell as a problem.
Also, having such a critical part of your system depend on email delivery and access? Looking at most frontend development practices I understand the blindside/YOLO attitude these days but it's still a bad idea anytime of the day.
Also, having such a critical part of your system depend on email delivery and access? Looking at most frontend development practices I understand the blindside/YOLO attitude these days but it's still a bad idea anytime of the day.
From a cryptographic perspective, when dealing with authentication the different methods fall in one of the different categories:
1) Something you know (e.g. a password)
2) Something you have (e.g. a token)
3) Something you are (usually biometric authrentication, like your fingerprint, a retina scan...)
Real OTPs fall in the second category, because you have some device/application that is able to generate the same OTP code as the server handling authentication without communicating with the server. Now there are some popular solutions that are still being called OTPs that instead of something you have is something that is sent to you, like SMS OTP. This isn't just quibbling, because sending something each time authentication is needed, opens up the possibility for some attacks that wouldn't be possible with proper OTPs, e.g. SIM swapping. So to answer you question:
- Just having to click on a link sent via email has the problems outlined in other comments
- having to both enter a password and having a link sent to your email address is safer than just enter a password, but
- having a true OTP, like the TOTP standard, is what provides the best security (in the category of OTPs, I'm not talking about protocols like FIDO2 and similar, because I don't know them).
EDIT: formatting
1) Something you know (e.g. a password)
2) Something you have (e.g. a token)
3) Something you are (usually biometric authrentication, like your fingerprint, a retina scan...)
Real OTPs fall in the second category, because you have some device/application that is able to generate the same OTP code as the server handling authentication without communicating with the server. Now there are some popular solutions that are still being called OTPs that instead of something you have is something that is sent to you, like SMS OTP. This isn't just quibbling, because sending something each time authentication is needed, opens up the possibility for some attacks that wouldn't be possible with proper OTPs, e.g. SIM swapping. So to answer you question:
- Just having to click on a link sent via email has the problems outlined in other comments
- having to both enter a password and having a link sent to your email address is safer than just enter a password, but
- having a true OTP, like the TOTP standard, is what provides the best security (in the category of OTPs, I'm not talking about protocols like FIDO2 and similar, because I don't know them).
EDIT: formatting
Every system that relies on passwords also provides a password reset facility. The facility typically sends a token to your email address and allows you to set your password that way.
Doesn't this mean that a system which relies on an token sent to you is no worse that a system with a password? With a password, you can guess that GTP used the same password on Hacker News and BigBank, and if that fails, you can try and have their token redirected to you. Without a password, you have to rely on getting that token. So if your argument is that email and SMS are insecure channels, I mean yeah okay; but it doesn't make a system more secure if you can get in with a password _or_ an email/SMS vs the only option is an email/SMS.
I hate passwords; my password manager (the one built into Firefox) will generate passwords on my desktop, but most of the time I need to generate a password it's on my phone (where, oddly, they have not included the capacity to generate a password). So my password is crap, perhaps not stored, and I forget it. I rely entirely on the password reset facility. But most of the time if you tell me "please just sign up, think of a unique username and a secure password" I'm just not going to bother.
Doesn't this mean that a system which relies on an token sent to you is no worse that a system with a password? With a password, you can guess that GTP used the same password on Hacker News and BigBank, and if that fails, you can try and have their token redirected to you. Without a password, you have to rely on getting that token. So if your argument is that email and SMS are insecure channels, I mean yeah okay; but it doesn't make a system more secure if you can get in with a password _or_ an email/SMS vs the only option is an email/SMS.
I hate passwords; my password manager (the one built into Firefox) will generate passwords on my desktop, but most of the time I need to generate a password it's on my phone (where, oddly, they have not included the capacity to generate a password). So my password is crap, perhaps not stored, and I forget it. I rely entirely on the password reset facility. But most of the time if you tell me "please just sign up, think of a unique username and a secure password" I'm just not going to bother.
The difference is that the password works as a shortcut for situations where the email approach adds lots of friction (working on a "guest" device, latency, the entire world spam countermeasures). Friction is very much acceptable for password recovery (arguably even desirable), but not so much for conventional login.
A nice middle ground would be allowing to opt out of passwords, for people who are happy with the combination of device token plus email OTP. This would work even better if device tokens were not binned with all those junk cookies: I think it could be valuable to have a class of "qualified cookies" that can only be written on user prompt and have reads optionally protected by additional local authentication requirements (configured on the user prompt), basically something that sits right in the middle between the streaming heap of cookies a browser stores and the browser's password store that allegedly nobody uses. I believe that this could be a major win for web privacy, "delete all cookies except for those which the store considered important enough to depend on a user prompt" (obviously, the client needs to include a "pretend to store, but actually keep only for the session" option to prevent abuse)
You could almost implement this for a site already using the web storage API, except for the unclear client prompts and lack of fine-grained tying into additional client side authentication measures (e.g. like how you might want a password manager to maintain very different master key freshness requirements for different entries)
A nice middle ground would be allowing to opt out of passwords, for people who are happy with the combination of device token plus email OTP. This would work even better if device tokens were not binned with all those junk cookies: I think it could be valuable to have a class of "qualified cookies" that can only be written on user prompt and have reads optionally protected by additional local authentication requirements (configured on the user prompt), basically something that sits right in the middle between the streaming heap of cookies a browser stores and the browser's password store that allegedly nobody uses. I believe that this could be a major win for web privacy, "delete all cookies except for those which the store considered important enough to depend on a user prompt" (obviously, the client needs to include a "pretend to store, but actually keep only for the session" option to prevent abuse)
You could almost implement this for a site already using the web storage API, except for the unclear client prompts and lack of fine-grained tying into additional client side authentication measures (e.g. like how you might want a password manager to maintain very different master key freshness requirements for different entries)
> The difference is that the password works as a shortcut for situations where the email approach adds lots of friction (working on a "guest" device, latency, the entire world spam countermeasures). Friction is very much acceptable for password recovery (arguably even desirable), but not so much for conventional login.
That's a general response to the question of why passwords might be nicer than email OTP.
But it doesn't answer my question - namely, any security problems that might be attributed to email/SMS OTP also exist almost invariably with almost all in-the-wild password implementations, and therefore, isn't email OTP only more secure than password plus an email OTP called "password reset". This question is purely a rebuttal of the claim that passwords are more secure than email/SMS OTP.
In the wild, there are a few sites where an email account, and therefore password reset, is optional. Hacker News and Reddit are examples. But these are in the extreme minority, and almost never secure anything worth securing. Bank accounts are another class of exceptions, where they secure something so valuable it is worthwhile going through a human verification process before you can do a password reset. But almost everything else - online stores, newspaper comment columns, much social media, web apps used for work, phone apps that let you monitor your robot vacuum cleaner, email accounts - almost all of them expect you to have an email address and use it for a password reset
That's a general response to the question of why passwords might be nicer than email OTP.
But it doesn't answer my question - namely, any security problems that might be attributed to email/SMS OTP also exist almost invariably with almost all in-the-wild password implementations, and therefore, isn't email OTP only more secure than password plus an email OTP called "password reset". This question is purely a rebuttal of the claim that passwords are more secure than email/SMS OTP.
In the wild, there are a few sites where an email account, and therefore password reset, is optional. Hacker News and Reddit are examples. But these are in the extreme minority, and almost never secure anything worth securing. Bank accounts are another class of exceptions, where they secure something so valuable it is worthwhile going through a human verification process before you can do a password reset. But almost everything else - online stores, newspaper comment columns, much social media, web apps used for work, phone apps that let you monitor your robot vacuum cleaner, email accounts - almost all of them expect you to have an email address and use it for a password reset
I'm not going to defend passwords, they are a usability nightmare. But I'm yet to see a solution that consistently works better.
Regarding your problems, it sounds like you're in need of a better password manager. I personally use LastPass. I'm not saying it's the best out there but I've been using it for a few years and haven't felt the need to jump ship yet. The advantage of having a 3rd party password manage is that it can run on your phone, tablet, laptop and any browsers you want.
Regarding your problems, it sounds like you're in need of a better password manager. I personally use LastPass. I'm not saying it's the best out there but I've been using it for a few years and haven't felt the need to jump ship yet. The advantage of having a 3rd party password manage is that it can run on your phone, tablet, laptop and any browsers you want.
I can run the builtin Firefox password manager on my phone, tablet, laptop and any browsers I want :p It would just be nice if it supported password generation where I need it most.
Which just emphasises my point that you need a better password manager which does support password generation on every device. LastPass being one such example.
I meant my first comment in jest. I will consider your advice, but I imagine switching from one password manager to another will only certify me as a genuine and eternal password hater. (Also, a password stored in a password manager is something you have, not something you know, so it's completely inconsistent with the principle of MFA. I mean, the reasons to hate passwords just increase as long as I think about it. That probably only hurts the theory of passwords though, not the practice of them.)
There is another option if you wish to adhere to the principle of "something I know" and that's to generate a base64 key. eg
This will generate a non-reversible password with an entropy of 25^64 but it is re-creatable on any system that can display a web page and the password is not stored anywhere (so it's firmly "something you know"). If the password becomes compromised then you change your salt and a new unique password will be generated. Thus you only need to memorise a small subset of salts rather than a password per site.
This was how I used to do passwords several years ago before I gave into the convenience of password managers.
SITE="www.example.com"
SALT="passphrase"
printf "${SALT}${SITE}" | shasum -a 512 | base64 | cut -c -25
This will generate a non-reversible password with an entropy of 25^64 but it is re-creatable on any system that can display a web page and the password is not stored anywhere (so it's firmly "something you know"). If the password becomes compromised then you change your salt and a new unique password will be generated. Thus you only need to memorise a small subset of salts rather than a password per site.
This was how I used to do passwords several years ago before I gave into the convenience of password managers.
Yes, I guess that theoretically works. As you say, it's much less convenient than abandoning "something I know" and just going for a password manager. Which I do.
> 3) Something you are (usually biometric authrentication, like your fingerprint, a retina scan...)
I've always considered them to be more like user names, albeit with a larger entropy than your average user string.
Completely agree with your points though. Particularly with regards to OTP. I'd further expand on that and say hosting your TOTP codes in the same password management tool as your passwords themselves (as some tools are now offering) is also really bad idea.
I've always considered them to be more like user names, albeit with a larger entropy than your average user string.
Completely agree with your points though. Particularly with regards to OTP. I'd further expand on that and say hosting your TOTP codes in the same password management tool as your passwords themselves (as some tools are now offering) is also really bad idea.
People love to complain about sim swapping but in reality phishing is far more common. TOTP that you type in loses to phishing. Having a complex and unique password for each service largely defeats sim swapping.
Tried this recently on a small SaaS app; users complained nonstop about the inconvenience of having to switch to their email client. One key thing I overlooked is that the service is often used in academic presentation situations, where you're trying to log into the service on a 10-year-old lectern computer where you aren't logged into your email account. I reverted to the generic UN/PW approach and the complaints disappeared; passwords aren't perfect, but at least they're compatible with sticky notes. Plus, users prefer the familiar.
I won't try the one-time-link approach again unless the app's specific use case makes passwords extra painful.
I won't try the one-time-link approach again unless the app's specific use case makes passwords extra painful.
Some people use mail clients that either preview or spam-check links. Every OTP you send them shows up as "already used." Then they blame you and not their mail client.
Related, I've consulted for a company that downloads and caches every link in every email passing through their corporate server.
Related, I've consulted for a company that downloads and caches every link in every email passing through their corporate server.
Since HTTP GET requests are specified as not having any significant side-effects, I'd blame your app as well.
I wonder why SSL Client Certificate Authentication hasn't become popularized for the web.
1. Browser visits a site that needs authentication. 2. Browser checks if there's already an existing client cert. 3. If not, browser generates one. 4. Browser uses it in the SSL handshake, resulting in the user being signed in without passwords, cookies, email links, etc.
1. Browser visits a site that needs authentication. 2. Browser checks if there's already an existing client cert. 3. If not, browser generates one. 4. Browser uses it in the SSL handshake, resulting in the user being signed in without passwords, cookies, email links, etc.
Perhaps one the main reasons is that a large number of people use multiple devices or even multiple browsers on the same device. Not sure how SSL client certificate authentication accommodates that.
Because the UI for managing client certificates is terrible, with no real support for distributing a cert to multiple endpoints unless you're in an enterprise environment with device management, or issuing smart cards and readers. I do think there's legs in client certs for enterprise authentication, but for consumer products it's a non-starter.
I wonder if this is something that cloud password managers like 1Password could tackle.
It's the way Spanish government webapps work with the citizens but it's a bit confusing to be honest. When it works it's perfect but the setup is complicated, so they're introducing an optional user/password login also.
Isn't the problem with this that it means your account is tied to your browser install? Eg, you'd need to copy the cert to another machine to sign in, would need to ensure it's backed up, etc.
Password management already is to basically that extent and the tools to copy that information around, backup, etc. also have come into existence to support usage beyond a single browser install.
That's half true, password management piggybacks on top of a system which doesn't have these characteristics, so it means no special work needs to be done on the development side to support them, and it's activation function is only determined on one side of each edge (the user side.) For this cert system to work, you have a bit of a chicken-and-egg problem since it requires both sides of the user-service graph to have done work pre-emptively to support it.
It would be really, drastically lovely if that were to happen. For bonus points, encrypt the client certs with a master password and sync between a user's devices.
UIs to use client certificates are terrible, and key and certificate storage almost always involves a password anyway.
My day job occasionally involves a WebDAV server protected with a normal login plus a client certificate. Sometimes I need to explain the process to less technically literate people who use different client software than I do, and the certificate part is a total pain.
My day job occasionally involves a WebDAV server protected with a normal login plus a client certificate. Sometimes I need to explain the process to less technically literate people who use different client software than I do, and the certificate part is a total pain.
As a user, I hate it, it's a PITA, why be different, 'everyone' 'understands' passwords, we expect them.
> why be different
Because, although everyone understands passwords, they have security and customer experience issues:
- Users choose easily guessed passwords and get hacked.
- They use the same passwords on multiple services and get hacked.
- They forget passwords, requiring an email reset, so they need to access their email anyway.
- The service doesn't need to store and manage passwords.
Every authentication method involves tradeoffs, and the service has to decide which set of tradeoffs they prefer. Personally, I prefer passwordless logins, but I understand why they're annoying for some.
Because, although everyone understands passwords, they have security and customer experience issues:
- Users choose easily guessed passwords and get hacked.
- They use the same passwords on multiple services and get hacked.
- They forget passwords, requiring an email reset, so they need to access their email anyway.
- The service doesn't need to store and manage passwords.
Every authentication method involves tradeoffs, and the service has to decide which set of tradeoffs they prefer. Personally, I prefer passwordless logins, but I understand why they're annoying for some.
Compared to saved passwords in terms of usability: it adds extra steps, potentially several, which is annoying.
Compared to passwords in terms of security: you have to consider that the client visiting the link might not be the client with the session being authenticated, at which point there might be confusion over multiple authentication requests of mixed legitimacy around the same time. I don’t know how this is typically solved.
I think better than either for security and usability is passwordless WebAuthn with a local factor (e.g. Touch ID for Apple devices, or even a master password for a simple improvement over existing password-unlockable saved passwords), if implementing something outside the status quo.
(edit: starbugs’s point about latency is also very important.)
Compared to passwords in terms of security: you have to consider that the client visiting the link might not be the client with the session being authenticated, at which point there might be confusion over multiple authentication requests of mixed legitimacy around the same time. I don’t know how this is typically solved.
I think better than either for security and usability is passwordless WebAuthn with a local factor (e.g. Touch ID for Apple devices, or even a master password for a simple improvement over existing password-unlockable saved passwords), if implementing something outside the status quo.
(edit: starbugs’s point about latency is also very important.)
Besides what many others have said, I'll add that many low-end Android phones are likely to kill your app when the user leaves it to go check their email. Which is fine, you can handle it, but many apps add a flow like this and aren't ready to be killed in the middle of their sign-in flow because this never happens on an emulator or a high-end test device.
This.
Same happens with the sms verifcation in microsoft teams.
On older devices switching to the sms app will restart the teams authentication process. So you have no chance in every typing the correct 2 factor sms key.
Another name of OTP in E-Mails are capability URLs and they are used quite frequently.
https://www.w3.org/TR/capability-urls/
There are some problems though and the authentication could be called weak.
Problems is that URLs aren't regarded as secret and the irrational tendency to log everything doesn't help, as these OTP will be visible after a while.
So these OTP have to be invalidated at some point as they tend to become revealed. If expiration is necessary, you still need some form of auth to regain access.
https://www.w3.org/TR/capability-urls/
There are some problems though and the authentication could be called weak.
Problems is that URLs aren't regarded as secret and the irrational tendency to log everything doesn't help, as these OTP will be visible after a while.
So these OTP have to be invalidated at some point as they tend to become revealed. If expiration is necessary, you still need some form of auth to regain access.
Because it's awful. A normal flow for me is credentials stored in browser/password manager. Login is more or less seamless, and typically takes under a second.
OTP login is multiple steps, involves me doing a copy/paste (or remembering the code), and requires a mandatory delay while I wait on the email. If I wanted to login incognito, or in a different browser, I may have to copy/paste the URL etc.
A better question is why anyone uses them at all given how bad they are. I've stopped using at least one site because it exclusively uses OTP links.
OTP login is multiple steps, involves me doing a copy/paste (or remembering the code), and requires a mandatory delay while I wait on the email. If I wanted to login incognito, or in a different browser, I may have to copy/paste the URL etc.
A better question is why anyone uses them at all given how bad they are. I've stopped using at least one site because it exclusively uses OTP links.
To truly advocate a position here, first the LCD must be reasoned for, which is, "my grandmother", or "cool and always drunk uncle", or "xyz frat bro/sorority sis"
Take all the time and energy you will put into this and instead invest in making sure your sign-up and authentication flows work with popular password managers.
The biggest downside is email isn't reliable - it's slow, it gets filtered, and sometimes it doesn't get delivered at all.
For example, I've been locked out of my Patreon account for the last couple of weeks since Gmail decided to return 550 errors (address doesn't exist) [1] and they require an email to log in when the IP address changes. Most likely my email address has been added to the suppression/bounce list of Mailgun.
* https://news.ycombinator.com/item?id=25435916
For example, I've been locked out of my Patreon account for the last couple of weeks since Gmail decided to return 550 errors (address doesn't exist) [1] and they require an email to log in when the IP address changes. Most likely my email address has been added to the suppression/bounce list of Mailgun.
* https://news.ycombinator.com/item?id=25435916
A lot of OTPs are implemented in insecure ways - e.g. using the "recover password" functionalities you can often figure out patterns the websites are using to create these OTPs. Some websites / apps do not implement account lockout and OTP expiration mechanisms and have 3-digit codes, which allows for brute-force attacks. Others with these mechanisms can lead to DDoS. Also, some web apps log these OTPs directly in the URLs. In general, I agree with minitech in that WebAuthn with a physical factor would be better, both in terms of usability and security.
If a customer loses access to their email (because they left the job or graduated, say), in the email/password world they can log in and update the email. In the OTP world the user is screwed.
I personally think nearly everyone here is wrong.
Working in IT with a direct day-to-day relationship with end users, passwords are the bane of all existence.
You say email delivery or sms is slow, but how often is it slow for users? Data on this? I personally have never seen a significant delay for an OTP code to either my inbox or my email (Google & Verizon). I have seen users that have an old email configured that is no longer active, but, oh, 80% of the time their cell number is a backup, so resolution is easy enough for them.
You say it’s insecure? Really? So the more than 30% of your users that have their password written either on paper on their desk (most commonly a sticky note or in a small notebook just hanging out on the paper pile) or in an unencrypted note taking app is somehow more secure?
You say it’s inconvenient? What? It can’t be more inconvenient than having to go through a password reset process once a week (which believe it or not, a TON of end users do).
Is any one actually measuring this or is this as an complete echo chamber of nerds that are good with password managers? Because I can tell you with certainty there’s a whole demographic, generation of humans out there where single token logins (backed up by multiple OTP at certain time or event trigger intervals) is BY FAR AND AWAY A BETTER WAY!
You want an example of who I think has this perfected: Affirm.com
Working in IT with a direct day-to-day relationship with end users, passwords are the bane of all existence.
You say email delivery or sms is slow, but how often is it slow for users? Data on this? I personally have never seen a significant delay for an OTP code to either my inbox or my email (Google & Verizon). I have seen users that have an old email configured that is no longer active, but, oh, 80% of the time their cell number is a backup, so resolution is easy enough for them.
You say it’s insecure? Really? So the more than 30% of your users that have their password written either on paper on their desk (most commonly a sticky note or in a small notebook just hanging out on the paper pile) or in an unencrypted note taking app is somehow more secure?
You say it’s inconvenient? What? It can’t be more inconvenient than having to go through a password reset process once a week (which believe it or not, a TON of end users do).
Is any one actually measuring this or is this as an complete echo chamber of nerds that are good with password managers? Because I can tell you with certainty there’s a whole demographic, generation of humans out there where single token logins (backed up by multiple OTP at certain time or event trigger intervals) is BY FAR AND AWAY A BETTER WAY!
You want an example of who I think has this perfected: Affirm.com
> It can’t be more inconvenient than having to go through a password reset process once a week (which believe it or not, a TON of end users do).
That is what I do with many services I use. I ask a reset password link every time I use them. I then just copy paste a random passphrase as new password and forget about it.
That is what I do with many services I use. I ask a reset password link every time I use them. I then just copy paste a random passphrase as new password and forget about it.
Wow. All the hate about email OTP. It’s an amazing feature that I use all the time. I believe slack popularized it.
Security and comfort are sometimes at opposing ends.
1) it’s unreasonable to expect people to remember so many passwords. I forget passwords all the time. Password manager isn’t that great since it doesn’t work cross device. 2) even with OTP, email is slow. Also email can distract and adds friction 3) federated auth such as google/GitHub auth is great. I usually get in in a single click.
I’d say if you want to prioritize you prolly get the best bang for buck in following order
1) federated auth - no need to store passwords, no forgot password flows. It assumes your audience is okay with google/GitHub/Twitter etc auth and has an account in one of the services.
2) email/pwd. More complications but benefit is it depends on no 3rd party.
3) one time link in email. The benefit is user doesn’t need to remember password. It does depend on email which adds some friction.
Note: you can have all 3 options and let user choose for maximum conversation. The tradeoff is more work on your side.
Life is all about tradeoffs. No one right or wrong solution.
Security and comfort are sometimes at opposing ends.
1) it’s unreasonable to expect people to remember so many passwords. I forget passwords all the time. Password manager isn’t that great since it doesn’t work cross device. 2) even with OTP, email is slow. Also email can distract and adds friction 3) federated auth such as google/GitHub auth is great. I usually get in in a single click.
I’d say if you want to prioritize you prolly get the best bang for buck in following order
1) federated auth - no need to store passwords, no forgot password flows. It assumes your audience is okay with google/GitHub/Twitter etc auth and has an account in one of the services.
2) email/pwd. More complications but benefit is it depends on no 3rd party.
3) one time link in email. The benefit is user doesn’t need to remember password. It does depend on email which adds some friction.
Note: you can have all 3 options and let user choose for maximum conversation. The tradeoff is more work on your side.
Life is all about tradeoffs. No one right or wrong solution.
Context switching really is a huge hassle which is why I absolutely abhor email logins. We as user have become privileged with high speed interactions on the web and any hit to it will definitely have an effect on user retention. Also keep in mind that most internet services are bottlenecked by network latency. When asking a user to login with email it adds in the time the user takes to physically navigate through the pages of the email client and the 'n' network requests needed to open an email and follow a link.
See https://www2.deloitte.com/content/dam/Deloitte/ie/Documents/... for more information on how cutting hairs on latency can dramatically affect an application's adoption rate
See https://www2.deloitte.com/content/dam/Deloitte/ie/Documents/... for more information on how cutting hairs on latency can dramatically affect an application's adoption rate
Honestly, having a password manager makes this so much easier.
I still like the OTP process, but it is more hassle than using the password manager.
I still like the OTP process, but it is more hassle than using the password manager.
I think it depends on what the sits is for and how cookies are handled.
If your login mechanism sets a cookie after they verify the link then they can continue to be logged in for 3 months or however long you want. This is similar to what you would do with a password.
Also the site type and your audience makes a big difference. I wouldn't do it on a site where folks aren't technical.
But for example what about an ecommerce site where customers need to register an account + put in credit card details to place an order and then they get access to digital goods?
In the above case the lack of password is a benefit because it simplifies the payment form. Now they only need to put in an email address + card details.
And for getting access to what they purchased a slight delay isn't the end of the world. You could even give them access to it immediately in some type of unverified way (limited features until they verify). Also it's a slight deterrent for account sharing.
If your login mechanism sets a cookie after they verify the link then they can continue to be logged in for 3 months or however long you want. This is similar to what you would do with a password.
Also the site type and your audience makes a big difference. I wouldn't do it on a site where folks aren't technical.
But for example what about an ecommerce site where customers need to register an account + put in credit card details to place an order and then they get access to digital goods?
In the above case the lack of password is a benefit because it simplifies the payment form. Now they only need to put in an email address + card details.
And for getting access to what they purchased a slight delay isn't the end of the world. You could even give them access to it immediately in some type of unverified way (limited features until they verify). Also it's a slight deterrent for account sharing.
I'm assuming you intend those links to be single-use only and expire automatically, in which case what I'm writing below doesn't apply. Nevertheless, the problem is big enough to be worth repeating and re-repeating:
Any link that ends up in a browser address bar should be treated as public.
And no, it doesn't matter if you use HTTPS. Ways to leak it are many, but the gist is that it's treated as "meta-data" and, rightly or wrongly, subject to much lower expectations of privacy. A recent scandal was that several common browser extensions collect this meta-data and sell it to marketing companies.
Which marketing companies offer searchable subscriptions (for hefty prices, true, this isn't a $9.99 service), where somebody could for example search for "yourcompany.com", or even worse, "yourcompany.com/authernticate?token=". Yeah, meta-data.
Any link that ends up in a browser address bar should be treated as public.
And no, it doesn't matter if you use HTTPS. Ways to leak it are many, but the gist is that it's treated as "meta-data" and, rightly or wrongly, subject to much lower expectations of privacy. A recent scandal was that several common browser extensions collect this meta-data and sell it to marketing companies.
Which marketing companies offer searchable subscriptions (for hefty prices, true, this isn't a $9.99 service), where somebody could for example search for "yourcompany.com", or even worse, "yourcompany.com/authernticate?token=". Yeah, meta-data.
I was working on an ecommerce site once and we got emails when customers left reviews/feedback. I forwarded them to customers because it was a convenient way to show their comments then follow up.
Then I noticed that some of the text was wrapped in a tokenised link to the platform managing our reviews, bypassing the login screen. Support said they could not revoke these tokens. We had to close the entire account and migrate everything.
Then I noticed that some of the text was wrapped in a tokenised link to the platform managing our reviews, bypassing the login screen. Support said they could not revoke these tokens. We had to close the entire account and migrate everything.
How do you advise we handle email address confirmation and password resets?
Automatically expire the links
Yeah but you can do that with login token URLs as well. The person I replied to said "you can never do that", not "you can do that only if you exercise suitable caution". I am asking for an alternative that fits with the "you can never do that" perspective, not a way to backpedal.
Apparently I completely ignored the first comment in the original post. Apologies.
Really fascinating subject that I've been thinking about a lot lately. At $FewCosAgo, I inherited a codebase which used passwordless login via SMS. SMS has a ton of intrinsic security flaws because of SS7 so there are obviously risks with this method. But with that said, it worked very well for the exact same reasons email doesn't here: SMS delivers nearly synchronously, and it was rare to end up in a situation where the login text didn't send to a user. After going through the flow a couple of times myself, I was shocked at how much more I felt inclined to test my own software just because logging in was so much lower friction.
Regrettably, the issues with passwordless email/SMS login mean that for now, if there's no OAuth provider you can/want to use, the ol' password is probably still the best way to go.
Regrettably, the issues with passwordless email/SMS login mean that for now, if there's no OAuth provider you can/want to use, the ol' password is probably still the best way to go.
Wow... amazing response to this questions. We have been researching this as well for a product.
I am surprised to see that so many people have issues with email delivery. Though email delivery can be delayed and in theory there are no guarantees.
Have you considered using SMS or a 2FA App like Duo? They should be near instantaneous.
The idea of sending this over telegram or signal is a good approach though the costs of Whatsapp messaging would be prohibitive. Even SMS will not work at scale. So really boils down to 2 things
(1) Speed - can you service live with delays or provide an alternate? (2) Cost - this cannot be tied to the per message cost like transactional or promotional email/SMS. A different pricing model help.
I am surprised to see that so many people have issues with email delivery. Though email delivery can be delayed and in theory there are no guarantees.
Have you considered using SMS or a 2FA App like Duo? They should be near instantaneous.
The idea of sending this over telegram or signal is a good approach though the costs of Whatsapp messaging would be prohibitive. Even SMS will not work at scale. So really boils down to 2 things
(1) Speed - can you service live with delays or provide an alternate? (2) Cost - this cannot be tied to the per message cost like transactional or promotional email/SMS. A different pricing model help.
Notion [1] used to do this. It is pretty bad for signing in. You have to be logged into your email, wait for a six digit OTP and then use that for logging in.
[1] - https://notion.so
[1] - https://notion.so
We implemented a passwordless, OTP-to-email login system, and doing user research, people just complain it's too complicated. They don't like logging in to their Gmail and (as others have mentioned) waiting a few moments. It's especially bad on something like mobile. People like to use passwords, apparently.
I see passwords as reducing security (we have a low-security product so people can reset with an email, so security-wise, the upper bound is your email security), hence we used it. But people prefer the "remember the secret" shortcut!
I see passwords as reducing security (we have a low-security product so people can reset with an email, so security-wise, the upper bound is your email security), hence we used it. But people prefer the "remember the secret" shortcut!
The California DMV does this as part of their “upload documents ahead of time” system, and it is a terrible experience, because they often tell you to wait for an email and then no email arrives. What happened - is there a problem with my spam filter? Is there a backed-up queue in the DMV software? Do they simply consider it acceptable if the email takes an hour to be delivered? If you use this method then you really need to care about your email deliverability and that is harder than just maintaining a regular login process.
One-time links are invalidated by various automated scanners that "check" emails upon arrival, including visiting all contained links. This is very common in enterprise setups.
We tried this on a b2b SaaS product I worked on where we had a lot of "third party" users (volunteers for a customer) who were only going to use the application once a year at most. One of the biggest hurdles we had was explaining it to enterprise customers - when they were doing their due diligence, it didn't "check the box" and we had to change it pretty early on in order to accommodate this.
Friction I guess. Having to open a new tab...wait seconds(!) for the email to appear...click a link which opens another tab.
Nah, just let a password manager handle it.
Nah, just let a password manager handle it.
Scryfall.com (a Magic the Gathering search engine and deck building site) does this and the experience is very nice. I'd have to check, but the session Scryfall uses feels pretty long. I rarely, if ever have to authenticate again on the same browser/machine. This would likely be more annoying if I had to do it every day.
i'm using this approach for a project (for a customer) where they don't want their users sharing their login details (username/password) with others. so it's a way to keep some control over who is accessing the system. the assumption is that people won't share credentials for their mailbox with others.
email is still mostly sent as plain text over the internet, that's certainly a downside.
email delays haven't been a problem in practice for us.
we also send users notification emails with links going directly to the right page, automatically logging the user in. i would like that from other services as well, as i'm browsing with ephemeral browser containers. having a clean browser environment triggers some website (eg github) to verify my login with a unique code sent by email. that indicates email delays aren't a showstopper in practice at big scale either.
email is still mostly sent as plain text over the internet, that's certainly a downside.
email delays haven't been a problem in practice for us.
we also send users notification emails with links going directly to the right page, automatically logging the user in. i would like that from other services as well, as i'm browsing with ephemeral browser containers. having a clean browser environment triggers some website (eg github) to verify my login with a unique code sent by email. that indicates email delays aren't a showstopper in practice at big scale either.
> email is still mostly sent as plain text over the internet, that's certainly a downside.
Opportunistic TLS for SMTP seems to have been dominant on the US portion of the internet for nearly a decade. Especially as email is concentrated in a few huge providers who have been using STARTTLS for many years.
I say this based on the systems and logs I have monitored in that same timeframe. In fact, many email systems (mostly corporate MS Exchange) appear to be configured to reject or spam-bucket email connections that don’t support STARTTLS with a public CA certificate. (This observation may be biased by covering the financial services industry more than others.)
Opportunistic TLS for SMTP seems to have been dominant on the US portion of the internet for nearly a decade. Especially as email is concentrated in a few huge providers who have been using STARTTLS for many years.
I say this based on the systems and logs I have monitored in that same timeframe. In fact, many email systems (mostly corporate MS Exchange) appear to be configured to reject or spam-bucket email connections that don’t support STARTTLS with a public CA certificate. (This observation may be biased by covering the financial services industry more than others.)
Email sometimes takes too much to be received by the user, but the approach could be handy in other contexts.
For example, some time ago made a Slack bot with a web dashboard. The authentication method was based on introducing your Slack username and the bot would send you an OTP. The latency problem didn’t exist here.
For example, some time ago made a Slack bot with a web dashboard. The authentication method was based on introducing your Slack username and the bot would send you an OTP. The latency problem didn’t exist here.
Substack and scaleway use email link as their primary authentication system.
Wonder what the impact of that has on both of them?
Wonder what the impact of that has on both of them?
The problem there is that if your email password is found (cracked, leaked, etc.) your account is pwned.
However, due to the "recover password" options, your other accounts are pwned too.
Finally, if you ever loose your email password, you won't be able to access any of your accounts anymore...
Finally, if you ever loose your email password, you won't be able to access any of your accounts anymore...
It’s irritating and would clog my inbox.
It's unpopular because it doesn't solve user issues. It solves vendor or engineering issues.
In Israel a lot of services are tied to an SMS based OTP (including government services), so one doesn't even leave the app. the app reads the token out of the SMS and fills itself in (of course if that fails, you can still enter it manually).
On the Mac, Safari has that built in, if you get an SMS (delivered to the same Messages app as iMessage), the browser knows about it and you just select "Use 1234 from Messages".
Described my (negative) experience with magic links in my SaaS in another thread recently: https://news.ycombinator.com/item?id=25465021
I used to add this functionality to all my projects, as it’s much better not to have a password. Now I don’t like it at all. It’s very inconvenient to have to switch to your email when you could just auto-fill with your password manager.
A consideration I see is the tradeoff between security and convenience.
Where email appears as a push notification on an imap idle configured email account, email can be far more unreliable, even with the best transactional email services.
Where email appears as a push notification on an imap idle configured email account, email can be far more unreliable, even with the best transactional email services.
If you make a new account on Yahoo Japan these days (not really related to original Yahoo and extremely successful in Japan), they don’t even let you set a password; you get an email link every time.
Email and sms are prone to delays that make the experience bad for users.
There is basically not much difference than sending "reset your password" email like all the time you want to log in. Keeping this in mind it seems ridiculous using SSO via email.
So many nice insight. Thanks.
What about a use case when it is inconvenient to create another password for a new user base at a company and this way you have users without calling support all the time.
What about a use case when it is inconvenient to create another password for a new user base at a company and this way you have users without calling support all the time.
How about scan QR code on login screen by authenticated APP on phone.
Many companies in China use this way. does there have any possible exploit/disadvantage of this method?
Many companies in China use this way. does there have any possible exploit/disadvantage of this method?
Disadvantages I can think of:
* requires app: This is the main killer. I'm not going to install some random SaaS vendor's app on my phone just so I can log in
* requires internet access on phone: sucks if your phone doesn't data, cell reception is spotty, or wifi isn't set up
* less phishing resistance: one time sign in links are impossible to phish, and passwords have mitigations that protect against phishing (eg. password managers that only auto-fill on the correct domain) and users are generally aware to "check the address bar before entering password". scanning a QR code has neither of these.
* requires app: This is the main killer. I'm not going to install some random SaaS vendor's app on my phone just so I can log in
* requires internet access on phone: sucks if your phone doesn't data, cell reception is spotty, or wifi isn't set up
* less phishing resistance: one time sign in links are impossible to phish, and passwords have mitigations that protect against phishing (eg. password managers that only auto-fill on the correct domain) and users are generally aware to "check the address bar before entering password". scanning a QR code has neither of these.
1. I don't want to install you app.
2. I don't want to find and pick up my phone.
3. How do you log in to the app? This has a bootstrapping problem.
Authenticators are much better options then email links if service wants to go for password-less login.
P.S. authenticators have their own problems too just like E-mail. :D
P.S. authenticators have their own problems too just like E-mail. :D
[deleted]
It means I have to go sign into my email account just to retrieve the OTP to sign into this other account.
Why not use some federated log in like Okta? Not as many issues as email on the delivery side.
Passwords are free, Okta is not. Also creates a ton of friction for users, most of whom will not have any federated login installed.
I'd rather that auth apps with a push notification prompt became more popular instead.
Monzo do this as their primary authentication mechanism.
No complaints with it.
No complaints with it.
Losing your email or domain would also be a problem.
I recently used Vercel’s awesome magic link login. The feature was so awesome that I just needed to open the link in whatever browser.
Unfortunately that also means that if I click the link by mistake the bad actor now has full access to my account. All just a misclick away.
Unfortunately that also means that if I click the link by mistake the bad actor now has full access to my account. All just a misclick away.
> Unfortunately that also means that if I click the link by mistake the bad actor now has full access to my account. All just a misclick away
Doesn’t clicking the link set cookies in your browser that then authenticate your session? How would you clicking the link somewhere give access to an attacker?
Doesn’t clicking the link set cookies in your browser that then authenticate your session? How would you clicking the link somewhere give access to an attacker?
The link in the email may or may not work that way - that would be down to how the authentication system has been designed.
Some of them recognise that users aren't always signing in on the same device that their email account is set up on, so the link in the email just confirms that the login attempt is genuine.
This is similar to how Google/Apple/Microsoft/Blizzard/Steam handle login requests with their respective authenticator apps. You attempt to log in on device X (which can be anything), then confirm that the login request is genuine on device Y (your personal device).
Some of them recognise that users aren't always signing in on the same device that their email account is set up on, so the link in the email just confirms that the login attempt is genuine.
This is similar to how Google/Apple/Microsoft/Blizzard/Steam handle login requests with their respective authenticator apps. You attempt to log in on device X (which can be anything), then confirm that the login request is genuine on device Y (your personal device).