Magic link rather than passwords, pros/cons

@vincent15000 I think you’re referring to social logins? A magic link is where a email is sent to the user containing a link that if followed will log the user in.

@robj Sorry effectively I'm referring to social logins.

I don't know magic links, but I'm interested in discovering this concept.

Can you explain quickly what it is ?

@vincent15000 if you Google “Laravel magic link” you’ll find several packages with better explanations than I could provide.

@robj Ok thank you, magic links seem to be like signed URLs.

https://laravel.com/docs/9.x/urls#signed-urls

@vincent15000 yes, you could use signed URLs as part of an implementation. I’d probably lean on one of the packages rather than rolling my own.

I’m more concerned with why than how at this point.

@martinbean regarding unauthorised access to an inbox; firstly the user’s probably got bigger issues than my app, an intruder could reset passwords on many sites and obtain those emails so not inherently worse than any site with a forgot password feature without MFA. Magic links are typically time limited too, so leaky emails reduce risk over time. But I agree, you are moving responsibility for securing passwords from your app to the user’s email provider … that could be seen as a pro.

Regarding man in the middle attacks, I would suggest that a cookie on the browser that requested the magic link must be matched before the magic link url logged a user in. That way if you tried to use a magic link on a browser that didn’t request it it wouldn’t work.

Do those stand up to reason?

@webrobert thanks 🙏 yes, I’m looking at an app for, let’s say, an older generation. My parents struggle with passwords terribly and, let’s be honest, many users reuse the same passwords on lots of sites.

I’m struggling to find a good reason not to use magic links other than the risk of emails going in to spam and therefore losing engagement. You run the same risk with requiring email validation though.

One concern is it’s pretty uncommon, users might get confused about what they’re being asked to do the first time.

@robj,

I generally agree on the email. If you're email is compromised it doesn't much matter, mostly. They just do a password reset and go get the reset link.

And a word of general caution...

most 2 factor auth is crap! its lame marketing to make people feel safe.

A friend of mine works for a major firm, top 10 tech kind of thing. When a user can't login. They spoof the users mobile phone to capture the sms. to get them back in. He tells me, never trust 2 factor that uses your mobile via sms.

Think about that for a sec. ITS so ^(&^&^ed

@webrobert that is mad… I often wonder about SMS, why it’s still around and used for 2FA, I guess it’s ubiquitous and reasonably cheap.

Auth0 have made a business out of outsourcing authentication, I “kind of” view magic links as outsourcing authentication to a users email provider.

@webrobert

A friend of mine works for a major firm, top 10 tech kind of thing. When a user can't login. They spoof the users mobile phone to capture the sms. to get them back in. He tells me, never trust 2 factor that uses your mobile via sms.

wow!

@Yorki can you be explicit about what the vulnerability is you see?

@robj eg. pretending support guy it's easier to get someone to send you link than their real password. I mean people are aware of keeping password safe, but in most cases as non-technical person they don't understand how links works and that you could login just using link. It still up to you to calculate the risk based on your audience and traffic.

@Yorki so the old “the website has sent you a link, can you read it/forward it…” hack. I agree, it’s an uncommon method so has unusual challenges. If you placed a cookie on the user’s browser which requested the magic link had to be matched to the url before it could be used to log in, would that mitigate that risk? I’m not convinced this is specific risk to magic links either, there’s social engineering techniques that regularly use the very common forgotten password links as an attack vector so it’s a problem that exists in password environments too.

@robj sure you can narrow the risk by adding the cookies, but me personally I'd rather just not make another space for attackers instead of trying to find solution for not being attacked by just introduced functionality. But as I said above and I will repeat one more time it's up to you to take the risk. I try to think about the future and complexity of solutions, more complex solution more vulnerability points can arise in future, especially if you are not the only person coding the project and some of them are not aware of "how it works" can write potential holes ;)

@robj but isn't the cookie option just another passphrase? 🤔 The passphrase or code is stored as a session and passed along the email and when the user clicks the magic link that is then compared. Given someone is intercepting the email wouldn't they also need to have the session for the passphrase to even make the comparison? The passphrases wouldn't be stored in a DB and linked to an ID, they'd be ephemeral right? And given the email is sent via a service they wouldn't have access to the session? Or is something going over my head here?

Edit: If they're listening to the email they can request a magic link themselves and just click the incoming email, I didn't think of that. 🤷‍♂️ That defeats the cookie as well since the attackers' machine will have it as well.

@Yorki I understand what you’re saying, what I don’t understand is where the added risk comes in. As I said, removing reset password links would be a positive trade off here. More broadly, holding passwords is a vulnerability and a feature that’s unnecessary (See my previous comment about Auth0) so why would you burden yourself with it.

The point about the this post is trying to asses the risks and benefits objectively, so I’m interested in understanding where those are with some specificity.

I get your point about complex code, but (if secure) should that stand in the way of UX?

@robj as @thinkverse pointed out also think about what if someone who was emailed the magic link opens it in another device or browser. Your whole cookie security will still force user to login. They are what they supposed to be (user you mailed), but they don't have cookies to prove their self which makes this useless.

@Yorki we’re going down a rabbit hole here, if someone is sniffing email then forgotten password links and a host of other stuff is vulnerable too, it’s not specific to magic links.

@thinkverse, so a user wishing to log in would request a link, a cookie would be stored in the browser. When the URL is visited the app checks for the presence of the correct cookie.

@yorki yes, if you changed computer you’d have to login again, as you do with passwords. I think it’s in these cases it’s clunky. But no different from a range of other sites you need to go through a number of steps with to login on a different computer.

user wishing to log in would would request a link, a cookie would be stored in the browser. When the URL is visited the app checks for the presence of the correct cookie.

@robj yeah, I get that, but if an attacker had access to the email or could read the email in a MITM attack. The attackers themselves could request a link and their browser would have the cookie, and would just have to click the link to get logged in just as the user.

@thinkverse agreed, and in this case “forgot password” links would be vulnerable in the same way. My point being, a compromised email account doesn’t lead to a different vulnerability for magic links.

Cookies would avoid the risk of emails being forwarded to users who hadn’t requested the link using it.

@kokoshneta thanks for your reply…. I’m going to sound pedantic, but if you’re going to say “security risks” then can you expand on that?

Yes, I’m not talking about tokens here, it’s a clickable link.

So, I get what you’re saying about the back and forth, it’s a good challenge and I wonder if it’s the real reason magic links aren’t more common. It’s how you position it with the user, not having to remember another password is pretty sweet. In addition, users are often asked to get tokens from SMS, Authenticator, etc nowadays.

Bear in mind that you don’t need to do it at registration, only when you are logging in after logging out.

I can already hear “that’s awful that you stay logged in” but it’s no different from offering a “stay logged in” or “remember me” option at login, so if you offer those then is that the equivalent of using magic links?

@robj By ‘security risks’, I was just talking about the potential pitfalls that others have already mentioned, nothing additional.

You’re right about 2FA codes from texts or authenticators – they’re bad UX as well, even though they are of course a good thing from a security point of view. Device producers try to close the UX gap there by adding features that automatically detect and allow you to fill in codes received in texts, but it’s still more cumbersome than a simple username/password combo, and it’s a tradeoff: is the content you can access after logging in important/potentially destructive enough that you’re willing to put the user through the extra UX hassle to log in? In cases like online banking, Stripe, school/university intranets, etc., definitely yes, because unauthorised access would be catastrophic.

But the strength of 2FA is precisely that it requires two separate factors: you need to both have access to the password and the registered e-mail or phone number. Using magic links instead of passwords means you’re giving the user extra UX hassle without the added security of having two unrelated factors, so there’s no real tradeoff between UX hassle and extra security anymore.

Don’t forget that the ‘not having to remember another password’ is not that much of a problem these days when virtually every system allows you to save passwords in keychains on your device and sync them automatically. You rarely need to actually know your password now, just a fingerprint or face recognition to enter your saved password on the website.

Allowing the user to stay signed in is not an issue in my book. It’s limited to a particular device, and it’s not generally considered a security flaw, as far as I know. But it does need to be the communicated to the user. If someone uses the service on a public computer, they need to know that they have to manually log out to not stay logged in (this is true for username/password logins as well, of course), otherwise the next user of the machine may just be able to access their account.

(Of course, if a malicious user has physical access to your phone, including your texts, e-mails and browser, then all bets are off. Short of futuristic features like DNA recognition, there’s nothing you can do about that. But that is luckily an extremely rare situation.)

@kokoshneta Thanks for your thoughtful reply.

I understand 2FA/MFA and what I'm suggesting here isn't that. It's a swap out for the pssword paradigm, I only mentioned it because it means we're all used to jumping through hoops when logging it.

Good point on the password managers, I'm not sure they're as ubiquitous as you might have hoped, according to this (agended) https://www.security.org/digital-safety/password-manager-annual-report/ study last year only 21% of people use them. A quick voxpop of my friends and famility only had 2 people use them and mostly they didn't sync across devices. The survey above does segment password managers and browsers seperartely, however as much as we'd like to think people use both to effectivly manage passwords - I think the average use case is going to be "I set a password the first time I log in and then request a new password when I inevitably forget it/change computer/can't find it ...."

A thought experiment I had was: what would be the reponse if we had grown up with a magic link paradigm and asked users to move to a username/password paradigm... it occurs to me that a response might be "I used to click on a link I got in my email which logged me in, and, now you're asking me to remember a password? Oh, and it needs to be complex? And, different for every website? There's a thing called phishing? What a nightmare, I'll stick to my magic links thank you".

Some fairly significant players are using magic links, ie slack. They have pretty a large dev and intellect budget so it can't be that crazy.

The discourse on Google is owned by poorly written blog posts like this https://www.okta.com/uk/blog/2020/09/magic-links/ which are agended and list cons that are vulnerbilities in password paradigms so are irrelevant.

Summarised, I wonder if it is a question of "we've always done it this way".

@robj I’m surprised so few of your people use devices to remember passwords. I haven’t done an actual survey, but I know from seeing auto-fills on friends’ phones that at least many of my friends use them. Even my parents use them (mainly because I set up iCloud keychains for them).

Incidentally, I happened to be presented with the password vs magic link quandary just now, while trying to log into UserVoice. Now, UserVoice has many other failings (for one thing, they actively do something to prevent your browser from saving your password, which should be against the law), but relevant here is that they still use magic links for e-mail verification.

They used to use them for all authentication, but changed it back after a shitstorm of backlash from users (they mention this quite diplomatically on their e-mail authentication help page).

This Twitter thread details the many issues with UserVoice’s implementation quite eloquently. Granted, some of the issues are due to really poor implementation, but others are inherent to magic links. One inherent pitfall in the magic link system is that if you lose access to your e-mail, you can’t log in.

When trying to log in just now, I had to click ‘Forgot password’ (because I created my account when they used magic links for everything – I don’t think I even had a password), and of course it didn’t work very well:

• The e-mail took half an hour to arrive, by which time it had expired; I had to request a magic link three times before one arrived that I could actually use
• When I could finally click on a non-expired link in the e-mail, it sent me to a page that told me I was now logged in and could close this tab (there was no navigation or anything, so you literally can’t do anything but close the tab) – but when I went to UserVoice after that, I wasn’t logged in and had to request yet another magic link
• This time I noticed that the popover on the original page where I’d requested the link had to remain open, because that was apparently polling for various events, and the popover is the only place where you’re actually logged in

All in all, it took me more than an hour and a half to get to a point where I had a password and was logged in. If everything had worked smoothly and the implementation been more sensible, it could have been done in a minute, but it didn’t and wasn’t.

The main point to all this is that as soon as you need multiple systems and applications to interact over the Internet, you immediately increase the likelihood of things going wrong. If it all just works, fine – it’s not excellent UX since you still have to go back and forth between apps, but it’s not a big deal. But when it doesn’t work, it very quickly becomes exceedingly frustrating to the user.

@tets I don’t have a link but I saw Jeff posted how to do passwordless logins here https://laracasts.com/series/jeffreys-larabits/episodes/32