Live data from Hacker News

Are Magic Links Outdated?

zitadel.com

71–80 of 230 posts

Re: Are Magic Links Outdated?

#71
post #31
post #28

Earlier quoted context omitted.

> Also the page that initiated it should periodically refresh itself to see if the session was validated somewhere else. I guess the link must be disabled / invalidated after first use and your auth server and client obviously must verify if a given link is still valid.

Of course the link should be invalidated, but that doesn't protect from a situation where an attacker initiates a login, then the user receives an email and clicks. The chances are slim but some people might get confused and click without much thinking - and voila, the attacker has a valid session.

Simply opening a Magic Link doesn't have to authenticate the initiating login. The user can be asked to interact with the page, being shown the source of the link (time, browser, device, IP/Region, etc.), to authenticate the login. This adds a little bit of friction to legitimate cases, but then again having to open your email and find a link and click it is already plenty of friction that this additional step can be considered a negligible addition to that.

Re: Are Magic Links Outdated?

#72
If you’re concerned about the security aspect of this, keep in mind that most web applications have this feature, but instead of calling it a magic link and for signing in, it’s called “forgot password.” It generates a short-lived code and emails the user a link that lets them access their account.

There are, of course, challenges with this being the only (or default) way to sign in, but the security concerns with it (e.g. weak email password) probably aren’t new!

Re: Are Magic Links Outdated?

#73

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…

It’s just like anti-CSRF tokens, lots of edge cases and it’s hard to get right. I don’t have a pw manager on my mobile device nor do I want one, getting a 35+ char into an input field on my phone is a PITA.

Does a password manager and browser extension not fix this? I use 1password on iOS and almost never have to copy and paste or (worse) type a password in. I just FaceID then pick the credentials I want to use to log in and the extension fills in the relevant form fields.

Re: Are Magic Links Outdated?

#75
The magic link is basically using "forgot my password" e-mail recovery flow to just friggin' log in.

If you've served the user a link which takes them to a session where they can change their password, that session must be authenticated, by definition; you would not allow an unauthenticated visitor to change an account password!

And so, if that password change session is authenticated, then just treat that as fully fledged session. Don't force the user to go back to the login screen and use their new password.

The next logical step after not forcing the user use their newly minted password is to just remind the user their forgotten password is still in effect, and that they can change it in their account profile settings.

From there to "magic link" authentication is just some minor UI tweaking.

I've always thought that asking the user to log in with a newly set password was an incredibly poor and unnecessary user experience, which just amounted to punishing the user for having forgotten their password and to train the user to believe that password recovery is inconvenient and should be avoided.

Re: Are Magic Links Outdated?

#76

Earlier quoted context omitted.

Are you serious? I'm signing into a website, I get an email when I'm about to sign-in from said domain, I click the link in the email, I'm signed in. What is this training me to do exactly?

Some third party detects you're trying to sign into a website. The third party sends you an email, that email happens to arrive first. You click the link in the email. Now you're on a website that looks like the one you expected (if the third party has done its homework) but is completely in control by the third party. Apparently things like this do happen, for example when people are buying or selling things on the…

> Now you're on a website that looks like the one you expected (if the third party has done its homework) but is completely in control by the third party.

A simpler attack would be to for the third-party attempt a login on their end into your account, and if you happen to click on the Magic Link generated by their login attempt, you wouldn't be signing yourself in, but them.

Re: Are Magic Links Outdated?

#77

Earlier quoted context omitted.

Some third party detects you're trying to sign into a website. The third party sends you an email, that email happens to arrive first. You click the link in the email. Now you're on a website that looks like the one you expected (if the third party has done its homework) but is completely in control by the third party. Apparently things like this do happen, for example when people are buying or selling things on the…

I'm not sure what actual security risk you're talking about here. I click the magic link, expecting it to sign me in, but instead it takes me to a fake copy of the website which then asks (again) for login details?

> but instead it takes me to a fake copy of the website ...

This is fine, but ...

> ... which then asks (again) for login details?

This is where the trick lies. The third-party copy doesn't have to ask you for login details. As your parent states: They get redirected to a pay processing site that looks just like the one from their bank, but steals their money and/or identity instead.

The fake site doesn't have to show you details of your account. It has to look just similar enough that enough people will think it's a legit payment site and submit their payment details.

----

There's also a simpler, alternative attack I mention in a sibling comment: https://news.ycombinator.com/item?id=32081724

Re: Are Magic Links Outdated?

#78
post #69

Earlier quoted context omitted.

If it's magic link or multi-factor authentication, I know which one I prefer. Try explaining to an MFA-loving service that your phone is out of action while it's being repaired.

Microsoft Authenticator - syncs your codes to the Cloud so you can pull them elsewhere (which your phone is out of action.)

Doesn't that defeat the purpose to a degree?

Re: Are Magic Links Outdated?

#79

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…

> 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. The earliest Magic Links I remember using didn't have this problem, and this was before smartphones. The Link, back then at least, was only to authenticate that you can receive emails at a certain mailb…

I just recently implemented a magic link flow for a project I’m working on, and “authenticated in the originating browser” was a high priority item for me.

I think it’s just so much nicer of an experience to not have to worry where you go check the email or which browser opens when you click the link there.

The site you used to login was clearly where you intended to be, so that should definitely be one of the authenticated sessions when you click the link.

Re: Are Magic Links Outdated?

#80
post #41

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…

Lots of issues with magic links. And yet, and yet. For a certain class of accounts, I'm okay deferring to my email inbox. From a security perspective as a user, it's no different than deferring to a social provider like Google, but has the benefit in that it gives a user more control over the third party they choose to delegate control to. You allow username/password access and that's great too. I'm a fan of giving u…

>I guess the hard part there is that no one building software thinks their app is 'low-value'.

I know the things I'm working on are low-value and appreciate it. In fact, I genuinely dread ever working on something high-value.

Post reply on HN