Why aren't one-time sign in links more popular for authentication?

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

As a user, I hate it, it's a PITA, why be different, 'everyone' 'understands' passwords, we expect them.

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.)

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.

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.

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.

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

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

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.

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

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 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.

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.

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.

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.

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

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!

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.

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 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.

Substack and scaleway use email link as their primary authentication system.

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...

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).

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.

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.

https://twitter.com/samuelgoto/status/1346145032663756805

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.

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?

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

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.

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.

Losing your email or domain would also be a problem.

Email is not a secure delivery mechanism.

Everyone has an HSM in their pocket these days. The fact that we are having these discussions at all is ridiculous.

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.