Magic/tragic email links: don't make them the only option

I arrived at the same conclusion after going through the steps and seeing that some corporate systems mark the login link as malicious, and there’s nothing I can do about it.

Sending a code goes around a lot of issues.

one times codes are very vulnerable to phishing. users are prone to entering codes on any resembling website

Why not just support a password?

I've had success with sending a code, and the link takes you to a page where the input is pre-filled with the code, and you just have to click "Login".

> I think that a link to a page where you enter a one time code gets around a lot of these issues.

I've done both in my SaaS product - link is GET with the OTP in the link, the target page checks if the link is in the URL, and if not, then the user can type it in.

Only for signup, though. For sign-in, the default is to always have the user type it in.

Come to think of it, magic links by definition violate the principle that GET requests should not change state. Defender & preview tools are actually following the established norms here - norms that were established decades ago precisely because we hit the more broad problem with C, U & D parts of CRUD, and collectively agreed that doing destructive operations on GET requests is stupid.

That seems like a really thoughtless idea.

What can you do to prevent automatic confirmation in that case?

I've had this problem as a user, accidentally previewing a link in iOS by tapping for too long.

> These days there's also to consider that some Mail Threat Protection Tools (at least Microsoft Defender in Exchange Online does this) click links in Mails to check them.

What an insane policy, why am I surprised Microsoft came up with it…

McD app is the absolute worst.

1) rooted or bootloader-unlocked Android devices are not allowed (granted it's easy enough to get past it for now but the checks are still there). 2) 2FA requirements as if anyone would bother to steal coupons from others

It appears that they want ordering burgers to have the same level of enhanced security as banking apps. Not even crypto or trading apps bother to block unlocked devices in such a way. Blocking rooted devices doesn't even make banking apps more secure but for them I can at least understand the reasoning.

I have heard that you are basically paying double what you normally would if you aren’t hunting for deals in mcd’s app these days. How much truth is there to that?

That would require I have my email on every device I might want to log in with.

I don't like that for a number of reasons.

When using magic links, you can still support the common UX polish of letting a user log in on a different browser/device.

If the user opens the magic link in the same browser that initiated the email, then just log them in. Otherwise, present them with the Apple-style "Do you want to authorize a login from 1.2.3.4 using Firefox on iOS possibly located in Portland, Maine? [Authorize] or [Reject]".

Would it have worked to forward the mail from your work email system to your personal email?

The link is a "safe" GET request. The page loaded via the link should do an "unsafe" POST for the login, via javascript with a form button for fallback.

https://www.rfc-editor.org/rfc/rfc7231#section-4.2.1

>The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content.

Exactly the same for email unsubscribe links, or a one click "buy now" link.

In my app, I just added an “Almost there!” Page with a button that the user needs to click. I still need to add a fallback option that uses a one time code for the other reasons mentioned above.

Save a browser cookie when the login is initiated. When the link is clicked check if the same cookie is present. If not, ignore it. Expire the link and the cookie after n minutes.

Using a time-based expiration rather than a usage-based expiration should help

E.g. require to click a button to actually sign in, don't consume the token and establish the session on mere URL access.

> but I added Google Sign in to my SaaS several month ago, and since then, it accounts for more than 90% of new sign-ups (users are devs, so rather tech savvy

I do it for services I don't care about. In my mind it is more privacy for me. Keeps you out of my real inbox and my password out of your system and I believe that I can - to some extend - remove myself without having to go through whatever crap account deletion process that services has tried to cobble together.

Worst offenders let me login with google and then immediately asks for name and phone number or email and asks me to verify it.

I have my HN username at a venerable webmail service. I check it about once a year, tops. My name isn't unimaginably rare, but neither is it "Smith".

I am shocked, shocked, by the number of different K. Strauser people who have typed that email address into some random website or another. I've gotten bank notifications, loan documents, Facebook signup info, meeting minutes from some random volunteer work, and all kinds of other things. When I can figure out from context who the intended recipient is, I try to let them know so they can fix it. On one occasion, the person sent me back a swear-laden diatribe for "hacking their email". Sigh.

I think this has made me a better engineer, though. When someone says something in a meeting like "...as long as they type their email correctly", I can jump in and address that myth head-on. No, people will not type it correctly. If it's a minor pain in the neck for me, with an uncommon name, I can only imagine the traffic that the world's John Smith's get.

Wouldn't privacy aware users prefer passkeys or passwords, instead of any kind of SSO?

In general, I do understand that use of SSO is due to convenience. Especially since in many cases websites provide less friction when signing up via SSO instead of using username+password.

The number of support requests I got last year because of [hotmail|gmail|msn|yahoo].con > 30

Absolutely. Users have to wait for the email before signing in, it does not work on devices without email without copying the link, etc.

With password reset, you are also trusting email.

If you are storing sensitive information in the system, by all means, you should act accordingly and require higher-security login than magic links. But if you do, you really should not be accepting username+password either. You need to at least put some 2FA on there to step up one level of security. And not SMS- or email-based 2FA either.

90% of web apps don't handle that kind of information, and for them a magic link is at least as good as passwords (as this article explains). Those that do handle things like personally identifiable information (beyond an email address) really should be enforcing 2FA or proper electronic IDs.

There is a whole profession writing recommendations about information security, and every web developer needs to be able to do this kind of analysis at a rudimentary level. We don't need to wing it, we can analyze security requirements in a systematic way.

No, kudos to them for looking at a piece of data and asking themselves if it's worth storing—more companies should do that with more data. It's not that the rest of the data isn't valuable to some extent, it's that every piece you have makes the blast radius of a leak that much bigger, so why hold stuff you don't need?

Planning for a breach doesn't make you more likely to have one—if anything it makes you less likely!

To be fair to 404, they're trying to limit the amount of data they hold which IS good, but in the end they need to have the email address of subscribers.

In my country even the social security number of people is public information.

The UX debate is valid, but magic links (and emailed one-time codes) are clearly more secure than password + password reset. Control of the email account gets you in either way. Passwords are an additional attack vector.

Yes, I clear cookies every time I close my browser, as a layered approach to privacy on top of uBlock Origin and NoScript. There isn't a great way to exclude certain sites from this, other than setting up a dedicated web browser in a container just for Mercury.

I wasn't aware that WebAuthn didn't have this requirement. I prefer TOTP because I actually like having a second factor in addition to a credential stored on my computer's hard drive (whether a password or a private key in my password manager), but I might be willing to reduce my security posture to get rid of this annoyance.

One suggestion: the link would be half as annoying if it was easily cut-and-pasteable rather than a long email-open-tracking link spanning multiple lines. This is what it looks like when I copy it out of my email:

  https://email.mg.mercury.com/c/eJxMzs1u4jAUBeCncXZB9vVfvPACZshoWIwYoiasdgkra2KV_JCGqPTpK-imq7xxx40vlO9IKia6ggL6zUlQHObdF6\
  JI0alRHBWQvWKRuD4loLZxsJSRXZAwfNBQeQWozasdgeWsMyFZozE4RKZ4d151NOFtuq9w6IqLb-d5fGdyzaBmUIdx_NkzqBeacrqXkZaMxGSNQyQmf7_9GW7\
  Hf1cJ8zW9TshAwwba3ccLuN3u_r_PR9j_GkxxxmadDu32c59jMfkYFmKKP0baIT0vzP4ynHN_-yyhZOTy9jmPPQn6gL-VLMfvvIA_XxbywRYhUbZUp0RpVCUC\
  qDsbasJHeObFMZ4YrFw1cAAAD__4XPZXw

Edit to add: looks like email.mg.mercury.com is hosted by Mailgun. Are you intentionally sharing these authentication tokens with a third party by serving them through this redirect? Do your security auditors know about this?

> IPv6 gets more traction IPs will rotate much more regularly

unfortunately, only few ISPs do IPv6 correctly by assigning a fixed prefix to customers. most of the ISPs apply the ipv4 logic when adding ipv6 planning hence this situation.

hopefully this will improve in the future and more stable prefixes will be given to users.

I like the schemes that send a numeric verification code that you manually type in without an email link. can also use a text message. Maybe allow this to be configured.

security = 1/convenience

but also vice versa

I'm confused, what's going on here? Is there a reason you wouldn't have bothered reading a post from that specific person?

thanks for writing what you wrote -- I think it's important that we have this conversation as broadly as we can

Thank you for the link! I saw your other comment and actually edited mine to point to that, because it's definitely the answer to my question!

> though I don't know if making your email an even stronger attack vector is necessarily one of them

I'm unconvinced that magic links do make your email an even stronger attack vector. Essentially every service that would be inclined to use magic links would already have a way to reset your password entirely once the email is compromised. All magic links do is make this the primary way to interact with the auth flow.

The bad guys already know that your email is the best target. Magic links just make that very explicit.

> There are some positives about Magic Links for sure

Like what? I'm failing to come up with a single benefit (for the user).

What does the final end state of passkeys look like? What happens if I lose the device I created the passkey on, if it gets bricked, or if I get banned by the platform that was supposed to be syncing my passkeys?

> hopefully Gnome/KDE implement passkey support

sigh TBH, I hope not. Maybe optionally, but for now the friction might keep companies from going passkey only, which (I think) would be a total nightmare from a security and usability perspective.

> how much easier/better/same is it to try and have your work computer work with your personal passkey from a laptop or something?

Passkeys support authentication via a secondary device over Bluetooth (and this is supported in every major browser on every major platform). So you can login to a site on a machine that’s completely disconnected from your personal passkey store by scanning a QR code with your personal phone.

The login flow basically goes “request login with passkey” -> “browser recognises it doesn’t have the needed passkey, and offers a QR code to scan” -> “scan QR code with phone” -> “phone and browser handshake via Bluetooth” -> “passkey handshake happens between website and phone” -> “login completes”.

I’ve personally used this flow with my work laptop and my personal iPhone many times. iOS has built in support for the Passkey QR codes, so you can scan the code with the standard camera app. Additionally iOS supports allowing 3rd party passwords managers to take over the Passkey flow once you’ve scanned the QR code. So in my case I complete the flow with 1Password.

End-to-end the flow is pretty damn seamless, I’ve never personally had it fail, and take 30seconds to complete. The most annoying part is trying to remember where my phone is.

It is certainly not all, and most security conscious sites offer other recovery options like one time use codes. Many also allow for time delayed account recovery, which aren’t a usable option for magic links.

In any case the correct approach here is to fix password reset/account recovery (e.g. with social key recovery) rather than reduce everything to the lowest common denominator.

It also can be said to lower security because it instills the behavior of clicking on links in incoming emails as a standard practice.

60% of Internet users rely on a password manager, and that number is still growing by a significant amount each year.

As someone in the security industry, I find it amazing how much we've told people (in awareness training) to "not click things on the thing-clicking machine™" while simultaneously having processes like password resets that require doing it.

™Kelly Shortridge 2021 (https://x.com/swagitda_/status/1503751776134180873)

I don't like password reset links either. Send me a code I can type in, but only to the original browser session.

Be careful of those as well, but in this case it's quite simple: password reset links should only be sent when the user explicitly requests them; of you receive an unexpected email asking you to reset your password, don't click the link.

Fake password reset links are also a common attack vector, so yes people are told to be also cautious of those.

Otherwise it's been a while I haven't seen an reset link instead of a reset code. Copy/pasting is not much of a hassle, and it works even if the mail is checked on a different device.

The only real link I had to deal with were app callbacks that were explicitly labeled as such (with instructions from the app to explain what to expect)

Nobody is actually confused, it's just performative whining.

Ok. So now my users get random login links for sites we may or may not use… sure, you Silicon Valley Cool Guy aren’t going to fall for it, but my blue collar Detroit UAW guys might.

Click that stupid magic link for a service we use, and they’re asked for their Office 365 credentials… all the while I’m telling them not to click links in emails.

How is that secure against the same phishing attacks that a clickable link is vulnerable to (basically the idea that someone can socially engineer you into a situation where you think you are supposed to complete the auth flow with them, enabling them to sign in as you?)

Or in the Gmail client on iOS which opens links in an embedded browser.

OTP is the only sane option - there are too many edge cases for magic links to make them a good user experience

This is a fair point to bring up.

Most sites will have a confirmation once you click the link that includes the browser version and IP address. I have seen that info only in the email itself too with no confirmation afterwords, but not for some time. Have never seen one that is just a link with nothing else that once clicked allows the other device in but supposes could be implemented that way.

The article itself is about not making them the only option (which is fair), and the OP says if they do it should login the device which originally made the request (which I agree). If the implementation is just an email with only a link, no other information with no confirmation (yes, it's fine to let this device in), then I would have to agree with you it's very risky and could allow anyone to login as you (hopefully no sites are doing this, but...)

Or if your mail client, spam filter or anything else tries to prefetch the link...

If you really want to allow for another browser to authenticate a login request, you can at least limit it to sessions coming from the same IP.

That would let you authenticate your desktop browser from an email you opened on your phone if you're on your home network, but without becoming widely exploitable by phishers.

To be safe the link can load a page with a form / button that says confirm the login.

Almost no one has a competent security team and if they do they don’t listen to them. Security is just compliance checkboxes and lists nowadays

A fully competent security team will, on the other hand, carry out a more comprehensive threat modelling exercise and make a pragmatic choice about whether this kind of auth flow is appropriate for your usecase.

The phishing risks for a bank account login are very different than those for a ‘returning player’ login to a casual gaming site for example.

BankID scams in Sweden worked because it did not require there to be authentication between the device that logged in and the device that authorised the login.

The victim got a phone call in which the she got manipulated into authorising something in the BankID smartphone app. But what she was actually doing was authorising the attacker to log into her online bank account.

First after several years (of blaming the thousands of victims for their millions lost) did the system start using QR codes on the screen scanned by the smartphone.

All the email scanners likely trigger the process anyway.

Solvable with the right information in the authorizing email.

Remember that the flow the magic link is part of is one you initiate, that causes you to get an email you are expecting.

That email, and the landing and confirmation page it links you to, can explain very clearly that you are only supposed to authorize this if you are trying to log in on known device in known location that is displaying recognizable number on the screen right now.

Yeah exactly. Plus, sometimes SOMETHING will click the link before it even gets to the person's inbox (some enterprise spam filter with a sandboxed browser for example).

edit: saw that nicce basically said that a second before I hit post.

Yes but clicking the link itself shouldn't log you in. Any implementation of magic links that does this is broken because of link previews.

You click the button on the page which knows the session you're logging in from and link code and does a POST which completes the login. This is how all the "login by scanning QR code" flows work.

An RSS reader is the client software for reading RSS feeds. Here's a description of RSS feeds [1]. Here is a list of some readers [2].

[1] https://en.wikipedia.org/wiki/RSS

[2] https://en.wikipedia.org/wiki/Comparison_of_feed_aggregators

True, but pushing passkeys as the primary auth method reduces the risk to a great extent. It's a huge difference. As long as the user keeps using a relatively stable set of devices, they will 'approximately never' be exposed to MITM.

Also, when logging in from a new device, many accounts which use password-based auth today send a confirmation email and ask users to either enter the emailed code or click on the link. This is part of their existing security protocol. So we are not introducing a new unique thing here.

There are many options where such links are a reasonable option. I'm okay to receive such a link to validate my e-mail for an account creation, or to unsubscribe from a mailing list at a place I don't have an account at, or to display an order status page at a shop where I ordered as a guest without creating an accoung.

But using them as the only option to login is really, really annoying. Mails can get trapped in spam filters, delayed by intermediate server overload or spam filters that sometimes take 10 minutes, servers doing graylisting... Plus all the other annoyances listed in the article (e.g. multi-device users, in-app browsers). At the very least, support passkeys if you really don't want to store (hashed) passwords. And no, SMS is not an alternative: I was several times barred from logging in to a service because SMS wasn't properly working (can happen easily while roaming abroad).