Live data from Hacker News

Are Magic Links Outdated?

zitadel.com

101–110 of 230 posts

Re: Are Magic Links Outdated?

#101
A totally unbiased article for sure /s

These guys sell a auth/login system, it's no surprise they are anti-magic-links.

I understand the annoyances for the more tech-minded among us, myself included, but I've implemented this before and for your average user it's a pretty good system. With Universal Links/App Links you sidestep a number of the issue with email clients having their own in-app browser. Also this makes your signup/signin process the same flow (and only 1 step) which is easier for people who aren't as technically minded.

I used this method for a food festival (you buy the festival's currency to spend on food/drinks, it's just a digital version of the paper/ticket/token-systems a lot of a festivals use) and we only had 1-2 people who had issues (email took a few minutes to get to them for some reason) out of thousands.

It's all about knowing your customer base, in the future I might implement the ability to set a password but I'd be the number of people who use that option will be vanishingly small (again, based on the demographics of people using my platform).

Re: Are Magic Links Outdated?

#103
post #15

Earlier quoted context omitted.

Once I click the link, it takes me away from my email inbox. That means I have to go back and clean them up later. That's extra work for something that should be ephemeral. No thanks. I can't quite put my finger on why it's different from having SMS 2FA codes in my Signal inbox, but it feels like more clutter.

SMS clutter is worse for me. Harder to delete in bulk.

My SMS inbox is almost entirely login codes and other automated stuff so I'm quite happy just to leave it all there

Re: Are Magic Links Outdated?

#104
post #94

Magic links are half factor auth. They're probably good enough for apps that no one actually cares about though.

Does that make a password + email password reset a quarter factor?

Password plus email is one factor. So that would be 3/2 factor auth.

Re: Are Magic Links Outdated?

#105

I think a lot of the complaints here are "nerd problems". For customers they seem like a super convenient thing, I was just implementing them in my app. Yes magic links have problems and it's probably making me lean more towards the "emailing a code" option now, some of those problems outlined aren't easy to ignore. The app I'm working on, users would login probably once or twice a year. I just can't imagine they wan…

I'm in the same boat. People login 1 time a year (it's for an event) and using magic links means I don't have to deal with password management, forgot/reset password flows, and more. It also means signing up is as easy as entering your email (the web/app prompts you for the other required info on first login).

Out of thousands of people who used the system I only had 1-2 people who had issues. One was using their work email (why do people do this?) and I think it was being filtered and the other was using Yahoo but for some reason the emails were slow to deliver, 2-3 minutes (far from the only Yahoo user, only one that had issues).

Re: Are Magic Links Outdated?

#106

I wrote a Rails plugin for magic links at https://github.com/rocketshipio/nopassword that doesn’t suffer from many of the problems I’m seeing in the comments. The big thing is I only use a 6 digit numerical code that people have to copy and paste or type into the browser which they’re authenticating. I looked at stuffing a token into a URL, but it’s not a good idea because the email client may try opening the link to…

So if I have 700k usernames I can pwn one of them with 50% probability. Cool! With 3 attempts allowed I only need 230k usernames, even better! The "secret" stored in the browser doesn't protect you from this, since I'm not stealing someone's code; I'm logging in from my own browser. (Of course I'm doing this via a botnet, so you won't notice it by IP address)

I'm pretty sure you are missing how they implementing this. It sounds like at time of the request to send the code the browser either generates and sends to the server (or gets from the server) a longer/more-complicated secret. Both that secret (which is probably account-specific, the one you requested login to) and the 6 digit code are required. You can't just guess the code, the code has to be combined with another account-specific token.

By regenerating longer token each time a 6-digit token is required and only allowing something like 3 guesses per longer token (Before regenerating and sending a new 6-digit code) you have a secure system.

Re: Are Magic Links Outdated?

#107

I think a lot of the complaints here are "nerd problems". For customers they seem like a super convenient thing, I was just implementing them in my app. Yes magic links have problems and it's probably making me lean more towards the "emailing a code" option now, some of those problems outlined aren't easy to ignore. The app I'm working on, users would login probably once or twice a year. I just can't imagine they wan…

> I think a lot of the complaints here are "nerd problems".

Not really.

- Email deliverability is a serious issue - some well-known providers (Apple and Microsoft) can delay email up to five minutes because they're scanning it, and that's assuming that it didn't went to spam. Compared to 2FA login, that's an eternity.

- Also, speaking of scanning emails, some do "click" them to check that it's not a harmful page (Microsoft, Google Workspace if admin enabled it, Barracuda which is common on enterprise), rendering the link invalid.

- Not everyone keeps their email logged in (or uses a different app/client to keep them logged in), which results in worse experience.

- Most mobile email clients (Mail on Apple, Gmail, Outlook) by default launch a different window, meaning you're logging into the mail client and not the browser.

Re: Are Magic Links Outdated?

#108

Earlier quoted context omitted.

This may be a good future. But it seems like this isn't available to most people on most browsers yes. Especially if you want to sync across ecosystems. I like how tangible passwords are. Even with a password manager I can write them on a piece of paper, store then in a vault and enter them into a new computer. My grandmother understands this process. The key-based systems are basically magic. Magic that works great…

Chrome supports a webauthn solution built-in if you don't have windows/platform authentication support. I think Firefox does too, and probably even Safari on really old machines. If you are targeting semi-modern browsers and devices made in the last 5-10 years, you should be fine.

Yes. To my knowledge WebAuthN works great on Chrome, Safari, Firefox (most times) on MacOS/iOS and Windows devices. Linux is still an issue unfortunately as it seems.

Re: Are Magic Links Outdated?

#109
post #97
post #82

Earlier quoted context omitted.

> MagicLinks are a mobile nightmare. Mobile email clients use their own browser and cookie jar which consume the session cookie you're trying to put into the user's main browser. It might be howling into the void but the conclusion I reach from this is that "Mobile email clients are a nightmare". Generally speaking, embedded browsers in mobile apps are a terrible idea and break user expectations in multiple ways.

On the flip side, I find that opening links in isolated sessions very valuable, if not just because I don't want links sent by others to affect the Algorithm's perception of me. 80% of the time, I want to be a blank slate when interacting with in-app browsers.

I really want the choice. I hate that most iOS apps want to open links in their own webview instead of my default browser. Of course, when they DO use the default browser, I would like to have control over what context that browser uses to handle the link. Default? Private? Task-specific tab/container group? Ask me, please.

Re: Are Magic Links Outdated?

#110

MagicLinks are a mobile nightmare. Mobile email clients use their own browser and cookie jar which consume the session cookie you're trying to put into the user's main browser. This results in users 'never staying signed in' and a lot of frustration. Sending a one-time code via email fixes this, and is in practice about as easy to use as a link on desktop. In our app (Loomio) we default to magic/codes, but let users…

How I handle this is as follows, within a B2B context. The email sent to the user contains both a magic link and a code.

If the user clicks the magic link from the same device that they initiated the login from, it just opens straight into the app.

If the user clicks the magic link from a different device, it confirms the token and then the browser waiting on the original device logs in. It uses a generic browser/server messaging library to achieve this, based on whichever of HTTP SSE, WebSockets and polling is available.

If the user can't do either of these for whatever reason, such as email virus scanning or whatever, the bottom of the email also contains a code which can be entered onto the waiting login form, along with some information about never giving that code out to anyone else on the phone and checking the URL.

The magic link also has an interstitial page with an automatic POST form to deal with browsers and other things pre-opening links. There are also various points along the way that it attempts to check for phishing and perform additional interventions, such as if the magic link is clicked from a different country to the login request, or if the request is coming from a suspicious location, etc.

After all this is complete, it then does 2FA using SMS. The magic link login is only needed the first time you log in on a given browser as it saves a persistent cookie, but the SMS 2FA is needed every time. We don't support persistent sessions due to legal requirements.

We are also working on adding webauthn authentication, but early testing suggests most users find it very confusing. Mobile devices tend to handle it acceptably, but Windows' implementation in particular is currently very user hostile and often users worry they are being hacked. It also doesn't replace the email/SMS-OTP flow, because if the user is logging in from a new device, we still need a way to validate that it's them before they can subsequently authenticate with webauthn. We also support SAML SSO.

Most users are not interested whatsoever in carrying around a Yubikey. Even just using SMS-OTP got a lot of push back for being inconvenient. I think FIDO2 will work better for users when there's a good way of automatically synchronising their keys across all of their devices in a vendor-neutral.

Post reply on HN