I've never liked magic links. I've found multiple sites that will just clobber the existing login session when you access the magic link, meaning someone could trick you into logging into another account.
I like magic links (as long as they self-renew the cookie so I never have to log in again) but you do highlight the critical need for a good landing page if you use them, like "are you sure you want to log in as SomeUserNameGuy? You're currently logged in as SomeOtherUserNameGuy."
Yeah. To be honest, I kind of setup this blog as a joke when the dot zip gTLD came up, as an inside joke with a few fellow security people who (rightfully) are against the ever expanding list of TLDs we have to deal with.
Because of the risk of auto-linkification, I'm of the opinion that browsers should put the entire dot-zip domain into the this-is-dangerous realm with big scary warnings if anyone follows a link. (Or at least any file downloads.)
Because I'm an idiot who likes hosting stuff on bad gTLDs, here's the markdown content of the actual post for you and everyone behind some corporate firewall that blocks dot zip:
Of course, as stated in the article, such email links are harder to phish than passwords, can't lead to a breach of passwords, and protect the site itself against users who might reuse passwords previously compromised.
The article even covers some of my annoyances with this system, but throws out this sentence:
Easier than what? Easier than a long password, without a password manager? Easier than a passkey? Easier than an OTP sent to the same email address?
This sentence reads to me as one written by someone mostly working and _living_ from a single laptop and mobile device. The second part of the sentence, calling for more sites to do this is why I am writing this.
For any scenario with a minimal amount of complexity, like users with multiple computers, and you're looking at a scenario where the site's unwillingness to deal with other login methods shoves friction on the end-user.
### What makes them tragic:
1. Multiple devices. Who doesn't use at least a few computers weekly? I don't have my email on my gaming PC, nor do I have it on my work laptops.
1. Slower. From 2 seconds slower to minutes slower, depending on SMTP delays as well as how awkward it is to get the link to the right browser.
1. Anti-mobile. As mentioned by 404 in their own article, this breaks the ability to use in-app browsers, which is quite annoying especially for RSS reader type apps. It makes interacting with any local link in the RSS feed extremely annoying.
1. Indirect security downsides. Pushing people to access personal email on work devices (or vice-versa) isn't exactly a win for security.
Another annoying _passwordless_ system is to email or SMS an OTP the end user can type in.
While this sucks, it at least allows you to easily log in in situations where you don't have a clear and easy copy/paste path from the email client to the browser you want to log in to.
[Stratechery](https://stratechery.com/), powered by [Passport](https://passport.online), uses this type of scheme (click link OR type in OTP), which is still shifting annoyances onto end-users to free developers from implementing passkeys, but at least has a bit more of an appreciation for end-users.
If you insist on using magic/tragic links by default, at least consider offering a robust alternative...
Best implementation I see of this requires you to click the link on whatever device you receive the email on, but it doesn’t transfer the session there - it just triggers completion of the login process on whatever device you initiated the process on.
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.
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.
Rather than a recognizable number, users should be prompted to select a matching non-pronounceable glyph. Something like the keypads from KTANE [1].
That makes it impossible to text or speak it to a phisher.
Bonus points if you show the symbol as a noisy animated glyph, something like [2], or a link to a DRM'd video showing a symbol. That would make it very difficult to view even with screen recording or remote desktop software.
The thought of using unpronounceable text to deter phishing attempts reminds me of putting illegible Unicode as challenge question answers to prevent the CSR from giving an account away to convincing social engineers.
There is a substantial class of users this would be too much to ask of, i.e. they wouldn’t understand it or would assume that they are being scammed somehow.
> the flow the magic link is part of is one you initiate
There's nothing stopping anyone else from initiating the flow assuming the common implementation where only an email is required to initiate sending the link.
Here is the link you requested from ‘Android Device’ in ‘Belarus’ - click here to sign in and allow that device to access your account - only click this if you requested this email
You don’t click the link if you didn’t request it.
The phisher will be on the phone with their victim, pretending to be a support agent for the business. They will say, "Yes click the link, that's how you verify with us."
So many people on this thread leaping in with the phishing threat model.
This is a simple quick login process, you wouldn’t use it in a place where 2FA is required. It is a mistake to think of this as a substitute for 2FA just because it has some of the same elements as a secondary device authentication. It’s not intended to be a 2 FA flow though! It’s a single factor - ‘does the user have access to a device that can read emails sent to this associated email address’. We aren’t combining it with a password or anything else.
That is the same level of auth used for things on many services like ‘registering for a free account’, and frequently for ‘resetting the password on an account’.
It’s not a complete security solution and you wouldn’t use it everywhere. It would be a bad fit for a banking app or access to a publishing interface. It’s not a bad interface for things like ‘logging in to my subscription on the TV’ or ‘returning as a customer to a website I shopped with once before’.
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.
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.
Some people will still click the button because they expect it will give them more information about why they received the link. You can add text along the lines of “authorize login on $other_device”, but it’s still risky.
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...)
Agreed! If they all worked like this would be a happy camper. Nothing worse than being in one browser, opening the email, then it opens and authenticates you on the default browser or even better on a different device and needing to forward the link to the other device so you can open it there (yes odd scenario but try not to access certain emails from certain devices).
Sites that send an OTP (crazy-pink-horse-3837) that you can copy, and paste is a good middle ground if implementing the link that just Auths the original request is too difficult.
where? i just went through Settings > Apps > Gmail on my iphone and found nothing about this. Likewise the in-app Settings in the GMail app lets you choose which browser is the "default app" but it's already set to Safari (the other options are Chrome, by Google, and ... Google, by Google). But that uses an embedded
Safari instance inside gmail, not the phone's Safari app.
To get what you want (links open in Safari.app, not the safari webview inside Gmail): configure your default browser in Settings (your iphone settings, not gmail's settings) to be Safari, and then in Gmail choose "Default browser app" instead of Safari.
It's super vague and unclear why things should work this way, and I don't know if this is forced on them by iOS or what. I'm trying to think of why choosing "Safari" in the gmail settings would use the webview instead of the app, and the most-charitable reason I can think of is that they don't want to contribute to the person having hundreds of Safari tabs open...?
Less-charitable reasons might include wanting to keep users in the gmail app for driving "engagement". I read somewhere that when apps use the in-app webview, the app dev can inject arbitrary javascript and thus has full control and can see keystrokes, what the webview's viewport is looking at, etc. I really don't think that's what google is trying to do here, though.
Wow - i even saw the words "default browser app" and did not even realize it was a setting choice. That works - thank you!
wrt reason : I think that the webview has cookie isolation from the actual app, so using the webview is a bit more privacy-protective. Google being Google that seems unlikely to be the motivating reason, but who knows what good may lurk in the heart of men...
This is bad (phishing). The better solution is have the login only work on the device where the link is opened, and for cross-device use to also provide an OTP code the user can read on the receiving device and easily type in on the initial device. (Or only provide the OTP code and no link.)
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?)
Well, it doesn't solve the issue of someone sending you a fake login e-mail that you then mistakenly click on, that's true, but the whole point of magic links is that there isn't an auth flow; there's no password for them to steal from you.
In other words:
1. A malicious individual sends them a fake login link
2. The link can't ask them for a username and password because the site doesn't have passwords, just magic links
3. The site could ask them for your OTP code if they have one, but the bad actor doesn't have their magic link and the OTP code expires in a few seconds anyway
4. Without the bad actor actually getting access to a legitimate magic link nothing happens
It does solve the issue of:
1. You visit the site on your device at the same time as they visit on their device
2. They get two e-mails and maybe click on the one that approves your session instead
3. Your session on your device logs in; theirs doesn't so they figure it's a bug and go click the other one. Now you're both logged in.
If you require the session to be logged in by the link directly, it ensures that only the device you're viewing the e-mail on gets signed in; in the above scenario, your malicious session is never logged in, but their legitimate one is.
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.
AFAIK, McDonald’s does this with their mobile app (they weren’t letting me log in with my password) But the problem with their implementation was that the magic link that they send you is wrapped in a click tracker whose domain is blocked by pihole (and the likes), and I could not reach the actual auth URL to complete the login process.
Many email clients will click the link and invalidate it - for example outlook is a classic here - so the best implementation does not use redirects/links at all.
OTP is far better than an actual magic link - you can still include a link that pre-fills the code.
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.
I’ve been stung by this before, where I’d already closed the original browser tab since I assumed the magic link would open a new tab (as they usually do)
Like there's no other way to verify an email address. From a developer perspective, I hate it, because it's yet another functionality that I need to add and support in my app.
I also find their magic link annoying, but since claude.com doesn't log me out all of the god damn time like chatgpt.com does, Claude is winning this round too...even though this is not a factor in why I prefer one vs the other.
I just signed up for Claude yesterday and I didn't even realize that I didn't enter a password. It was when I wanted to use it on my phone (with Firefox, not the app) that I realized that there was no Claude entry in my password manager. It made me irrationally angry for about 5 minutes, and had I known it in advance, I would probably not have bothered.
I like the Kagi qrcode login option. You scan the QR code with any device you are already logged in and boom, you can login with a button. Its like steam guard but with no app. It’s in fact so simple that I don’t understand why it’s not universal.
You still need another method for the first login.
The biggest disadvantage of this scheme is that if a malicious actor can trick you into scanning an arbitrary QR code, they can get access to your account (by visiting the login page themselves to generate a QR code, and then sending you the code).
Discord implements this feature, and this phishing scheme is extremely common: bots/scammers will message you saying "to access <some desirable content>, please scan this QR code" -- and if you scan the code, the scammers have just taken over your account. It's not much harder than rickrolling someone unless they're savvy enough to be aware of the scam.
Of course this can be mitigated somewhat by putting a big scary confirmation screen that says "don't click continue unless you're trying to log into your account from another device", but 1) users don't read, they just click "continue"; and 2) the attacker controls the narrative before the user clicks the QR code; they can craft the language to make the scary warning screen make sense to the user ("yes, I am trying to log into this discord server that this person sent me an QR code to").
I feel like there should be a way to implement this in a phishing-resistant way. Maybe instead of a QR code some sort of video stream that updates dynamically? That would at least be much more difficult for attackers to pass through to the victim.
> 1. Multiple devices. Who doesn’t use at least a few computers weekly? I don’t have my email on my gaming PC, nor do I have it on my work laptops.
"Who doesn’t use at least a few computers weekly?"
I don't. And many, many other people.
See what I did there? I assumed that everyone's like me, just like you did in your blog post. Without data, both of us are wrong.
----
I'd add that magic links also act as a distraction: you open your email client, and it by default opens your inbox, and you start going through all of those unread emails that you just found in your inbox...
Shopify is a big proponent for magic links because they went all-in on their new "Shop" customer accounts. What a disaster.
Branding something with such a generic word as "shop" is terrible and average customer doesn't understand that it's supposed to be a brand name.
> "Who doesn’t use at least a few computers weekly?"
> I don't. And many, many other people.
When you consider that a smartphone is "another" computer (or for many users, the computer that is not the smartphone is the "other" computer), I imagine that number goes way up. Someone using a computer at work and a personal phone, for example.
You're welcome. Been thinking about it for a few days, and I had to do it. I don't disagree there's some benefits but being told "IT'S BETTER!" annoyed me quite a bit.
Issues I’ve encountered building an app with magic links:
1. Include a fallback sign-in code in your magic link, in case the user needs to log in on a device where accessing their email isn’t practical.
2. Make sure the sign-in link can handle email clients that open links automatically to generate preview screenshots.
3. Ensure the sign-in link works with email clients that use an in-app browser instead of the user’s preferred browser. For example, an iOS user might prefer Firefox mobile, but their email client may force the link to open in an in-app browser based on Safari.
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.
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.
>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.
Why not just have a username & password. Why make everything so complicated? We just successfully got password managers deployed to most users, only to drop passwords entirely for a subpar system?
One example is an unsubscribe link. Legally, it would be no bueno to have it behind any sort of login.
Another is just counting if a link from an email was clicked. I want friction to be as little as possible. That's done by having some sort of redirect, but you have to use a JavaScript initiated post to weed add false positives. That's already ridiculous, but because of automated link prefetchers, you still need to disable that and show a f'n button.
And then I have to answer to clients that want to know why their clickthrough stats are down precipitously and I don't honestly have the wherewithall to explain the inner workers of every filter that snoops their email before they read it.
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.
Surely this breaks the "email is not on same device as login" use case? At least with normal magic links, they're merely incredibly annoying but doable (via e.g. typing in the URL)
That use case still works. In fact it works better because if you click the link on your phone you don't automatically get logged in on your phone browser (or your email client's in-app browser). You can then copy the same link on your desktop and it will work as expected.
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.
1) It means your users will complain that their account was hacked (even if it was their fault) and might cancel their service
2) hackers can exploit your system which hurts you (you are a VPS provider and someone mines crypto and you have to wave it for PR) or you run an email service and someone uses your app to spam (which hurts your email rep) etc.
1. Sixty percent seems astronomically high, do you have a source?
and
2. Most "normal" non-tech-savvy people I know who do use a password manager (which I've typically installed for them), are revealed a while later to still use a variation of password reuse : either storing the same password per category of websites, or having a password template they use on all sites, e.g. "IdenticalSecretWord_SiteName"
I don't have the source, but don't think 1Password/LastPass/KeePass. Think the "would you like to save this login" built in to Chrome, Firefox, Edge, Windows, and iOS. These days, you have to opt-out of password management.
Right, use of a Password Manager does not imply they are using Password generation - it may just mean they click "Save this password" after logging in using a re-used password.
In my experience 60% seems too high even for supposedly technical users (ref: I work in a dev firm), at least away from their jobs.
I definitely don't believe it for the wiser population (my gut, again based on people I know, says the number is more like 10%, maybe 15). Even the 36% figure on the report on security.org posted above seems dubious, I suspect they have some bias in their survey. Unless that is some people who use the iCloud password manager for some things and no password manager for everything else, so it isn't claiming 36% routinely use a password manager away from a few key accounts.
Only having magic links gets you a load of stuff for free,
Higher level of security than just user+pass (w/ forgot password)
Email verification
Lifecycle management - in a SAAS when a user no longer has a corporate email, they can defacto not log in, wheras with a user+pass you need to remember to remove their account manually on each SAAS or have integration with your AD (for example)
It’s not a higher level of security than password-based authentication. Why do you state that?
One-time email verification is not the same as security model as magic links. Magic links require instant access. Many security sensitive sites require a time delay and secondary notification for password reset links, which you can’t reasonably do for login links.
Lifecycle management is an interesting point. There are some underlying assumptions that might not hold though—losing an email doesn’t necessarily mean downstream accounts should be auto disabled too. Think Facebook and college emails, for example.
> It’s not a higher level of security than password-based authentication. Why do you state that?
It could be, depending on how the user has secured their email inbox access. I know I pay a lot more attention to my inbox than some random account. I don't have data, but I think this is true of most people.
I'm also more likely to enable MFA on my email account than I will on every random account I sign up for. And as far as the account providers, I trust the big email providers to be more secure than some random website with an unknown level of security.
You raise some valid points about tying access to a third party and what makes sense. It's not a simple issue.
> It’s not a higher level of security than password-based authentication. Why do you state that?
Personally I'm no fan of magic links.
But the people who do like magic links would say the typical 'forgot password' flow is to send a password reset magic link by e-mail. That means you've got all the security weaknesses of a magic link, and the added weaknesses of password reuse and weak passwords.
Of course you can certainly design a system where this isn't the case. Banks that send your password reset code by physical mail. Shopping websites where resetting your password deletes your stored credit card details. Things like that.
That means you've got all the security weaknesses of a magic link, and the added weaknesses of password reuse and weak passwords.
Is objectively true. I don't really 'like' magic links but I think they're a very easy to implement and simple to use for infrequently accessed systems. Arguably easier than user/pass and certainly more secure.
Even with those assumptions (which I question), it is only a higher level of security if you assume that your users are reusing passwords, or using low entropy passwords. Neither would apply if they are using a password manager, which a growing majority of web users are.
That's a fair point, but does time delay or secondary notification (the latter could be done for magic links of course) really outweigh the practical security risk of password reuse, attacks, leaks etc? I would argue not, unless the user had a insecure email account for some reason.
Re Lifecycle management; Unless you're also linking a phone number or some other "factor" I think in a traditional user+pass scenario you're also SOL if you lose access to your $Email1 before you update your account to use $Email2, as changing your email to $Email2 would usually send a email to $Email1 to confirm the action. In that case you're in the same position as magic link login + email change functionality. Similarly Lifecycle management only comes for free if you don't implement email change functionality.
One weird reason I've personal run into: when building on the edge, like with cloudflare workers, you can run into timeout issues because of how long password hashing takes.
That should be only if you're on the free plan that has a 10ms time limit. Paid plan gets 30 whole seconds which is plenty of time to hash lots of passwords.
Oh, we support passwords! (And passkeys, and social login, and OIDC, and SAML.)
Just want to make sure magic links work as well as they can.
Different folks have different requirements, and since we're a devtool, we try to meet folks where they are at.
We actually recently added a feature which lets you examine the results of a login, including how the user authenticated, and deny access if they didn't use an approved method.
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.
I was gonna argue that you can fix this but I realized that you’re right. It’s a MITM attack where there’s really no way to stop it, same as passwords. It’s basically the same feature (sign in in a different browser) that also lets attackers in.
That said, here’s how I would mitigate it:
- Like usual, time based limits on the code
- Code is valid only for the initiating session, requiring the attacker to create a paper trail to phish
If you do have a magic link & want to use code as backup for authenticating a different device/browser, you could:
- Compare IP and/or session cookie between the initiating and confirming window. On match, offer login button. On mismatch, show the code and a warning stating how it’s different, eg ”You are signing in a different device or browser, initiated from $os $browser in $city, $country, $ip - $t minutes ago.”
It’s not perfect though and may still be prone to phishing.
That has the problem of opening up an attack where the attacker requests the sign-in link, the person receiving the link blindly clicks it, and the attacker now has access.
People blindly click links all the time. It would have a low success rate, but would be more than 0%.
I might receive a magic link on my phone but then sometimes I'll copy/paste that over to my desktop or another device.
This works on 99% of magic links I've tried except for cases when they are trying to prevent account sharing. I remember the Bird bike app did this, where they required the magic link to be clicked on the same device login was initiated on. I was using my friends account and he would just forward me the link until one day this stopped working.
The idea being the user(s) would then have to share a email inbox to share logins, not just a password. It might not be the most inconvenient - this is partly how Netflix did their "Household" lockdown. You can request a travel code and this gets emailed to the primary email.
I feel the way Netflix did this broke the social contract of profile sharing on purpose - before, if you were a good tenant, you could freeload off another paid account without inconveniencing them at all. Memes and jokes formed of still being on an ex-partner's account or how people would rename themselves "Settings".
Getting an email and being harassed for the code by all those account sharers? Much more open and open for annoyingness.
Have your logging-in session wait for / poll "has visited magic link", and authenticate that session when it's done.
Tons of systems do this. It works great, and it can quite easily work without any web browser at all on the logging-in side because it just needs to curl something -> poll for completion and save the cookies -> curl against the API. A number of oauth flows for e.g. TVs work this way, for instance, because it's a heck of a lot easier than integrating a full browser in the [embedded thing]. Many app-based 2FA (e.g. Duo) works this way too.
So I misclick a link in my email client and the evil guy who requested in is now logged in on his browser god knows where? Surely that can’t be real. It sounds awful. TVs involve copying a code to make sure the right device is being authenticated, or the ones I’ve used have at least.
Duo 2FA works the same way. In principle yes. And it's basically always accompanied by a "click this link" -> "are you trying to log in, and is this you? yes/no" page to resist that.
Small code copying is also a very good answer though, yes. Roughly as easily manipulated, but nothing's perfect, and it's less "I didn't mean to click that button"-prone.
Yeah but I routinely click links in emails whereas logging in is the sole purpose of Duo. I could easily just intend to scroll the page and end up tapping the link.
so have that open a site that says "confirm login? y/n".
I don't mean to imply that just visiting the link should be enough to complete a login. That's a GET and there's a LOT of issues with doing anything important on GET. Just "do something on a different machine, then automatically complete login on the one logging in", and magic links to trigger that flow are a rather straightforward option.
There's no reason at all that it has to all occur on the same machine, and many reasons why attempting to require that doesn't work out in practice even when it does happen on the same machine.
No "tons" of systems do not do this. If you come across one that does it was built by a team that has no idea about security.
TVs etc. are special cases because obviously there is no way to redirect to them, and even there developers will always have some kind of secondary checks like having you enter a code displayed on the screen.
When I sign on to a bank it sends an SMS. Then my phone prompts me to share that code with the brower, on my desktop. It's a neat QOL "feature" - but kinda feels too automated to be secure.
That's because the server recognizes both clients, and you are prompted to approve the other client from the client that has the code. You are giving permission to the remote client, not taking permission from the remote client.
Google does it. Paypal does it. Duo does it. Lots of single-sign-on systems do it. All of those including not-TV scenarios, just normal computer-and-phone stuff, as well as sometimes other weird flows. Many of these are far beyond what most would label as "security competent", into "login security is a large part of their business and they have significant numbers of specialists hired".
(it is probably safe to say none are "truly secure" or "actually security obsessed", but I doubt that's actually possible in large quantities. the requirements are too steep, for both implementers and users.)
It's not the most common, certainly, nor anywhere close. But it's very far from nonexistent.
1. Attacker starts a log in and triggers a magic link email
2. Email received and my browser client previews the link without my desire
3. Attacker is now logged in
That’s why you combine it with a check for source IP and tell your user that they need to approve from a device that has same IP as the one they are logging in on. So if I’m logging in on my laptop, and approving with my phone, it will be rejected if my phone is using mobile data while my laptop is using landline, but will approve if my phone is connected to WiFi of the same network my laptop is connected to, or if my laptop is tethered via my phone, because then I have same external source IP on both devices.
This scenario is a solution only in simplest cases. It doesn't work when someone routinely uses a VPN on the phone (when often uses free public wi-fi in airports, railway stations, markets etc) because of possible MITM attacks.
The links are one-time use so you need to take this into account anyway or users simply can't login. It's usually done with a required button click after following the magic link. Or you can try JavaScript techniques to detect a real browser.
One thing I recently found annoying with Slack was that I wanted the company chat on my phone, but I didnt want the company’s email on my phone given the overly broad control of my phone
so I got the magic link on their computer and then I made a qr code
but wait, the email quarantine system had altered the whole link so I had to extract that
but wait the redirect url back to slack was malformed because of the url encoding and i had to fix that and then make the qr code
like wow just give me a qr code or code instead in the original magic link email!
These same corps have opinions on where users can be logged into Slack as well. And ffiw most enterprises that have this kind of device management don't allow login via magic links via email anyways.
Genuinely: why? All that is related to the business email is already accessible, it's just been forwarded elsewhere. The info is already known. What's to discover?
It indicates that you used your this other email for work purposes. The point is that they don't know what's in there, and they want to see if you discussed stuff relevant to the case. The judge will deny such a request as a fishing expedition if there is no basis for believing that you used your personal email for work purposes. But if it is discovered that you started sending work emails to that address...
Assuming we are talking about discovery in a civil lawsuit involving your employer the party opposing your employer can ask for all documents you have that are relevant to the lawsuit. It is then up to you to turn over those documents.
If they specifically ask for documents that are not relevant or if their request is too broad so will produce a lot of irrelevant documents your company's lawyers will tell them no.
By the time someone is actually specifically giving you a list of things to turn over that includes your private email it will only be asking for things that are relevant. Most of your personal email will be excluded.
4. Make sure the sign-in link on mobile works with your mobile app.
When McDonald's switched from email/password to magic links I had a hard time getting the magic link to work with the McD app. It usually would just open in the McD website.
Thus was quite annoying because about 98% of the time I eat McD's I would not do so if I could not order via the app [1].
I finally gave up and switched to using "Sign in With Apple" (SIWA). There was no way that I could find to add SIWN to an existing McD account, so had to use the SIWA that hides the real email from McD. That created a new McD account so I lost the reward points that were on the old account, but at least I could again use the McD app.
[1] They have a weekly "Free Medium Fries on Friday" deal in the app available for use on orders of at least $1. Almost every Friday for lunch I make a sandwich at home and then get cookies and the free fries to go with it from McD.
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?
Sure they want user data to observe people's purchasing habits. But they already have that if you always use the same debit or credit cards like most people do.
But the more people use the app, the less cashiers they need and the less ordering kiosks they have to install. Plus customer satisfaction goes up because you can order ahead and your food is ready when you arrive. And getting used to the discounts means you probably won't switch to Burger King or Wendy's.
I think additional user data is a relatively minor part of it.
> you can order ahead and your food is ready when you arrive
That just sounds like a great way to get cold McDonald's...
> I think additional user data is a relatively minor part of it.
You're probably right about that, but I've always undervalued user data because I don't think it's ethical to exploit people like that.
I'm sure that a well-timed push notification suggesting a personalized meal deal right around hungry-o'clock is the real goal of pushing this stupid app on their customers.
They have your name too. From what I understand, the tracking is generally done via something like the hash of the card number though. I've never heard of any legal or compliance issues with that, since the card number itself is not stored.
The food does NOT start cooking when you order it if you’re picking up at drive thru. It starts cooking when you pull up to drive thru and give the magic code.
In fact if the food is not easy to prepare you get put in a special parking space, where you wait for your order to be prepared. If it includes soft drinks they might serve those before they make you go park.
Disagree on not going to BK/Wendy's. The "deals" game becomes a habit, switching costs are basically zero, people start to comparison shop each app for the best deal (like shopping for air travel). It's a bit of work because there is no single consolidator but it only takes a few seconds to scan each apps offers.
At this point, being a fast food chain that doesnt have an app with deals is probably not viable - but I am very skeptical it generates any loyalty.
I treat food delivery apps the same way. There’s no stickiness for me, I just check all of them and pick the one with the best coupons for my restaurant. A sign that this kind of stuff is very much a commodity. I usually end up on DoorDash, but that’s mainly because the current credit card I use affords discounts for it and as a result wins in the bidding war for my business
It’s not about data, it’s customer segmentation. Frequent customers are more price sensitive, and are willing to use the app to get all the discounts, while occasional customers will not, so they can capture both the more price sensitive part of the market while getting higher margins from occasional buyers.
As someone who spent many years segmenting customers and generating personalized marketing offers -- McDonald's is awful at this. I was a 2-3x/monthly customer (USA based) for years (even more frequent a decade ago, but I'm talking about since the app), ordering the exact same core items every time (except during breakfast).
When they began "value meals" last summer (which don't include their flagship items) they also removed the best deals from the app, the ones that did include Big Mac, QPC, 10-nuggets. I've placed one non-breakfast order in 6-8 months, whenever they started this.
I'm just one person, but if a customer declines from an expected 15-20 visits over a half-year period to 1, and you don't adjust your offer algorithm (and you're the biggest restaurant company in the world so no lack of resources), something is seriously wrong.
They used to have great deals on the app in Germany. I used to go to McDonald's all the time. The deals suck now, and now I only go if I'm really craving a McMuffin Bacon & Egg.
They've captured the user base with the money that corporate was pumping into the app deals, and are in the process of enshittifying it by transferring the value to themselves instead of the users.
This can work in a lot of industries - I am skeptical fast food is one of them. Switching costs are low, alternates are plentiful, and collecting information (reviewing deals/prices across companies) is relatively easy.
If McDonald's enshittifies its deals while continuing to raise prices, it's way too easy for loyal customers to go elsewhere. I'm saying this as a huge fan and extremely loyal customer of McDonald's for decades... they are at serious risk of losing people like me. As I stated, I've gone from 15-20 visits to 1 since last June/July, whenever they made the big change.
We've got similar opinions here. I'm just pointing out that the overall experience here feels familiar, and it wasn't until reading this thread that I really put it together.
I agree with you that I'd be surprised if Enshittification works as well here as it does in tech, but maybe since there's an app involved, they just think they can get away with it. Who knows.
Whenever this happens to me I keep wondering how much I am of the A/B data test where I'm in the "less important group". Is it possible that their changes engaged (or profited from) the more active (daily/weekly customers) by making your situation worse?
Perhaps. Let's assume that the value meals is a massive hit and they are collecting far more revenue from customers who like it, than they are losing from people like me.
That's the whole point of data analytics and personalized marketing - even if the value meal works for most people they can still go back to sending me the offers and promotions I responded to previously, in an attempt to reverse my recent decline in spend/visitation. The app makes it possible to send individualized offers. There shouldn't be an entire "B" group where they just say, oh well.
That is an incredible amount of cooked calories for that price. No idea this was a thing. I do remember being in college and local mcd’s doing the typical “if team wins chicken nuggets are $5 for 20” but never heard of this sports box concept
> Three large fries ordered at the counter costs over ten dollars.
This is kind of hilarious and depressing but I live in a high enough cost of living city in the states and I order mcd’s rarely enough that I cannot tell contextually whether your statement indicates this is overpriced or underpriced.
It depends on order size. I think orders for one or two people over time you'd save close to 50% between deals and using points. For larger orders 20% off once a day is about the best you can do. (I'm my area/experience.)
"Normally would" is more likely, prices from the mid-2010's. The order I used to pay about $12 and change for in 2015 (I know this because I ate there at least once a week), is now about $13, by using the app deals.
However since the rollout of "value meals" last summer, they took away some of the better deals and now McDonald's is simply expensive (for McDonald's) even with the app.
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.
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.
Recently ran into this issue as new mail accounts got confirmed automatically and magic links were invalid when the user clicked them, because Microsoft already logged in with it during checking.
The alternative is to send an OTP in the mail and tell the user to enter that.
In that way there is no link to auto confirm.
However, if you do that ensure that you have a way to jump straight to the page to enter the OTP because (looking at you Samsung) the account registration process can expire or the app is closed (not active long enough) and your user is stuck
I run an authorization service that allows to log-in using magic links and we managed to solve this. First approach was for the link opening GET request to do not log the user in, but to include an HTML page with JavaScript that issued a POST request with a code from the link to log the user in. This worked well for a long time, because email scanners were fetching links from emails with GET requests but did not execute JavaScript on the fetched pages. Unfortunately, some time ago Microsoft tools indeed started to render the fetched pages and execute JavaScript on them which broke the links. What works now is to check if the link is open in the same browser that requested the link (you can use a cookie to do it) and only automatically login the user in these cases. If a link is open in a different browser, show an additional button ('Login as <email address>') that the user needs to click to finish the login action. MS tools render the login page but do not click buttons on it.
The issue that MS tools introduced is broader, because it affects also email confirmation flows during signups. This is less visible, because usually the scanners will confirm emails that the user would like to confirm anyway. But without additional protection steps, the users can be signed up for services that they didn't request and MS tools will automatically confirm such signups.
> check if the link is open in the same browser that requested the link (you can use a cookie to do it) and only automatically login the user in these cases. If a link is open in a different browser, show an additional button ('Login as <email address>') that the user needs to click to finish the login action.
Thanks for checking if it's the same browser. Some companies don't care about that (cough booking cough) so harmful actors just spam users with login attempts in hope a user will click by accident. And puff, random guy gets full access to your account. I got those every day, if I ever needed to login this way I would not be able to figure out which request is mine.
Ok, what if an email has "click this link if it was you who tried to log-in", or "if it wasn't you"?
Will Microsoft automatically authenticate malicious actors, or block yourself from services built with assumptions that the email client won't auto-click everything?
Login links from my service were automatically clicked and rendered and I know that other services discovered similar problems. Based on this I think that it is very likely the case with all the links in emails, but I don't know if there is any additional heuristic involved that would treat some links differently.
> But without additional protection steps, the users can be signed up for services that they didn't request and MS tools will automatically confirm such signups.
Indeed it's a bad thing but how bad?
The admins of some web service get a database of emails, send them those registration links, make their mail software create the accounts and? They end up with a service with accounts that they could create without sending those emails, before they send some emails to solicit users to perform some action on their (long forgotten?) account. There is no additional threat unless I'm missing something.
The admins have only an extra thin layer of protection because of the confirmation step but I think that any court can see through it.
The exploitation and potential damage would be service specific. Say a Dropbox like service for computer file syncing: An attacker creates an account for 'alice@example.org' and gets the signup email automatically confirmed. The attacker uploads some malware files to the account. After some time Alice attempts to create a valid account and resets password for 'alice@example.com'. Then Alice installs a desktop file syncing client provided by the service and malware files from the attacker get downloaded to her machine.
Another example would be if a company hosted a web app for employees that allowed signups only from @company.com addresses. In such case an attacker could be able to signup with such an address.
> 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…
It's not actually insane if the application hosting the link follows the principle that GET requests should not mutate state.
This problem is ~20 years old from when CMS platforms had GET links in the UI to delete records and "browsing accelerator" browser extensions came along that pre-fetched links on pages, and therefore deleted resources in the background.
At the time the easiest workaround was to use Javascript to handle the link click and dynamically build a form to make a POST request instead (and update your endpoint to only act on POST requests), before the fetch API came along.
It is insane because it brings literally nothing security-wise (an attacker can easily detect that the link is being opened from something else than an end-user's browser, and not deliver the payload) while actualy compromising the security of their users (by allowing an attacker to know which addresses exist and which do not, which is very useful if you want to attack companies).
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.
TeMPOraL said, "magic links by definition violate the principle that GET requests should not change state". That is a reasonable thing to think, but it is not true, because you can GET a <form> which POSTs when you click the "log in" button, unless you think a link to such a <form> page should be excluded from the definition of "magic link".
> unless you think a link to such a <form> page should be excluded from the definition of "magic link".
Yes. Linking to a form requiring user to press a button to submit an actual POST request is one proper way of doing it, and won't confuse prefetchers, previewers and security scanners - but it lacks the specific "magic" in question, which is that clicking on a link alone is enough to log you in.
Can't really have both - the "magic" is really just violating the "GET doesn't mutate" rule, rebranding the mistake we already corrected 20+ years ago.
(EDIT: Also the whole framing of "magic links" vs. passkeys reads to me like telling people that committing sins is the wrong way of getting to hell, because you can just ask the devil directly instead.)
One of the biggest advantages of magic links is that they're unphishable while still being easy to use (unlike passkeys).
Having a code completely negates that advantage, as attackers can just set up a fake website that asks for the code.
Magic links should log you in on the device you click them, not on the device that requested the login session. Anything else, while being a little bit less annoying, is a security issue and should be treated as such.
The conventional password system requires you to have a shared password manager on every device or that your reuse or memorize passwords. And that none of the service's users reuse passwords.
I can access my password manager on my trusted device, and manually type in my password for whatever service on any other device. This is exactly what I do for the rare but important time when I need to login on a device I don't want to have total access to everything.
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]".
> However, as with all other iOS web browsers, the iOS version uses the WebKit layout engine instead of Gecko due to platform requirements.
I do agree with what you’re saying though! Just those two in particular will probably have pretty good compatibility, which I was amused to find out when I looked into it.
Honestly, having run a number of experiments with magic link, I wouldn’t recommend them. We saw our login success drop noticeably. We tried a few different approaches over the course of a quarter but even our best attempt only mitigated the drop compared to having email/password and Google Login.
Obviously, your mileage may vary but it was a good reminder to always validate your assumptions, especially in your critical user flows.
Pretty straightforward: you send an event for which variation your user saw and another when they login, attaching the login method to the attributes.
You can use Mixpanel or Heap, which have mechanisms for mapping the non-logged-in user to your verified user on login, though you might need a bit of custom code to do it.
No worries! Our experience is that the hardest part (and it's not trivial) is associating the "anonymous user ID" to the newly logged-in user. Segment has an identify() function (I think Mixpanel has something similar), where you link the aliases, which then makes the reporting work.
I've not tried June, so I can't say for sure, but it's a pretty common feature for product analytics. I'll be surprised if it's not possible.
> Stratechery, powered by Passport, uses this type of scheme (click link OR type in OTP), which is still shifting annoyances onto end-users to free developers from implementing passkeys, but at least has a bit more of an appreciation for end-users.
With Stratechery, once you get to the website with the magic link, I can then copy the authenticated podcast RSS feed to Overcast and the authenticated RSS feed for the articles to NetNewsWire.
Those subscriptions are then synced to Overcast and NNW on my iPad and Mac via iCloud.
Each podcast RSS link is personalized and you go to the show notes page and click on the link to Manage your account. It will take you to the website using the embedded browser where you can manage your subscription and get access to the various feeds.
Speaking of Overcast, even though its doesn’t create a username and password by default, you can create one. But it’s only to access the web version of Overcast.
Yeah the Stratechery implementation for podcasts is great. The more annoying thing is each of them has its own domain and requires logging in, if you don't know you can dig into Stratechery.com. I would prefer if I could login to it with a passkey or username+pwd, but it's a much better system overall than just dropping an email link.
Way better option: emailed OTP code and passkey with Conditional Mediation UI. If the user is logging in from a device that already has a passkey, the CM UI will let them just select it and log in instantly. If they are logging in from a device which doesn't, we can make the UX such that it asks them to enter the emailed code, and after that is successfully it immediately asks the user to set up a passkey for instant sign-in.
This gets the best of both worlds: the security of passkeys on existing devices, and the passwordless setup and account recovery for new devices.
Bonus: it even avoids vendor lock-in where cloud providers have all your passkeys.
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.
> As long as the user keeps using a relatively stable set of devices, they will 'approximately never' be exposed to MITM.
As long as the user keeps a relatively stable set of devices and knows to be suspicious if they get asked for an OTP on a device that they know has a passkey. If they don't know to be suspicious (which let's be real, most people won't), they'll happily follow the instructions and fork over the OTP to a phisher who can use it to complete the authentication somewhere on their end.
Magic links without an OTP fallback are more secure as the initial setup process because they can't be phished unless someone's actually MITM'ing their HTTPS traffic (at which point nothing can save you anyway). A phisher can get someone to send themselves a magic link, but it's much harder to get them to provide the link to them.
> Magic links without an OTP fallback are more secure as the initial setup process because they can't be phished...but it's much harder to get them to provide the link to them.
It's not that much harder. 'Due to security reasons, please copy and paste the entire link that we just sent you into the following input box. If you don't, your account will be compromised!'
That's way harder than just asking someone to do the exact thing that they've already done over and over on your legit site. Sure, some will still fall for it, but the bite rate will go way down.
Phishing attempts by definition create artificially urgent abnormal situations whose job it is to convince the intended victim that they're legitimate. A difference in degrees like this strikes me as not really something to haggle about. Users who fell prey to the attack aren't going to be reassured on hearing how much more unlikely it was.
I recently encountered a food delivery website that insisted on a magic link / 2FA code check after a password login. Come on... I'm trying to order a pizza.
If you want strong security, offer passkey login. It's safer than email and much more user friendly especially with FaceID/TouchID on Apple devices.
They aren't really 2FA at all since often you don't need a password. To login you just type your email and enter the code you got from the email or click a link.
Shopify works this way where buyers don't have passwords and only log in with codes sent via SMS/Email.
Except that some people prefer to purge cookies when closing their browsers. And the session typically doesn't last forever, even if you keep the cookies.
Am I misunderstanding something, or are passkeys not actually an alternative to magic links?
Every implementation of passkeys I've seen has presented me with the option to create a passkey after I've already logged in with some other method. I'll admit that I haven't dug into it deeply, but the UX I've been presented with consistently makes passkeys appear to be an alternative to the "Remember this computer" button, not to passwords in general. Somehow the service has to know that this new device is authorized. I know depending on the provider there's such a thing as passkey syncing, but that doesn't solve the problem of getting the initial authentication done.
The key insight with magic links is that your security system is no stronger than its recovery mechanism. We are never going to get to a world where passkeys are treated as the only authentication mechanism—there will always be a recovery mechanism, and in most cases an automated one via email. Given that that is the case, magic links simplify things by just not pretending that we have a more secure layer on top. By making the recovery mechanism the primary means by which you interact with the authentication flow you're being more honest about the actual security of your auth system.
The first thing I thought when I read this is how can the author make the specific criticisms of links/otp codes and then suggest passkeys, which have pretty much the same issues x10. Like if using a OTP from your phone or copying a link from your phone when using a work PC to visit a website is a pain, how much easier/better/same is it to try and have your work computer work with your personal passkey from a laptop or something?
> 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.
Even if we assume that you're ok with connecting discrete and disparate devices together (and you always have your personal tracking device near you all the time), Bluetooth is basically comprised of a giant bag of vulnerabilities and weaknesses.
> Even if we assume that you're ok with connecting discrete and disparate devices together (and you always have your personal tracking device near you all the time)
This is a solution for the masses. If you're not comfortable with it, nobody is forcing you to use it, and it certainly doesn’t diminish the value passkeys provide over traditional passwords and OTPs for the vast majority of people.
> Bluetooth is basically comprised of a giant bag of vulnerabilities and weaknesses.
That doesn’t really matter. The whole point of passkeys is their cryptographic primitives make snooping on the handshake pointless. Everything is E2E between the passkey provider, and the site you’re authenticating against. There’s no dependency on Bluetooths security to ensure that the actual passkey handshake is secure.
> > take 30 seconds to complete
> also, ouch.
That includes the time taken to fish my phone out of my pocket.
I think as Ricky wrote last week [1], they should augment Magic Links or other auth methods. There are some positives about Magic Links for sure (though I don't know if making your email an even stronger attack vector is necessarily one of them), but for people who use a password manager, for example, they are a definite friction point that I think passkeys most certainly could alleviate.
There are definite UX problems around passkeys that could be improved and I think exporting will make syncing across systems a lot better (one of the reasons I use 1Password as my primary password and passkey system is so I can use my passkeys across devices; of course it helps that my employer uses 1Password as our system so I am logged into my personal and enterprise accounts and can auth then from personal or work devices, provided additional auth or enrollment isn't needed) -- but if the problem as 404 defines it is that they don't want to be responsible or even have to worry about storing your passwords/auth controls, I think passkeys is at least better for a subset of users than Magic Links.
But again, like Ricky, I don't think it should be viewed as either or. It should be both.
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.
>The bad guys already know that your email is the best target. Magic links just make that very explicit.
That's a good point. I guess my rationale is that it being explicit makes me feel less comfortable for my parents/non tech-savvy friends, who already may not follow best-practices for email hygiene (and may not use email providers that enforce stricter hygiene like 2FA or other methods of protection) and thus, systems like this, make their email even more explicitly the ultimate place to go for access to stuff.
>feel less comfortable for my parents/non tech-savvy friends, who already may not follow best-practices for email hygiene
making people feel less comfortable is probably a good thing.
i've managed to convince my dad to start taking his email security more seriously by reminding him a few times that if somebody gets access to his email, they can reset his password on every site where he uses that email address. it's good to remind people of why email security matters, and that it's not just about the personal messages from friends.
> 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
Do you have an alternative proposal for letting users back into their accounts when they inevitably lose their passkey? Because if you don't, this isn't a serious answer.
Password, not passkey. Recovery codes should be setup on account creation, but recovery of the password manager itself is what is required, and that usually has its own recovery mechanism.
Social key recovery is an underutilized solution as well.
Password managers are now built into every operating system / browser, with trusted encrypted sync capabilities. The UX of using the built-in password manager is better than that of a magic link.
Passkeys are in a transition period right now. There is no reason you have to have an alternative login method if you are using Passkeys, but no service has switched over to being Passkey only yet. Some users on older OSs / Linux might not be able to generate and store Passkeys yet, many users are not using a cross platform credential manager so if you've created passkeys with iCloud Passwords, there isn't a way to log in via linux right now.
Give it a few more years and I suspect we will start to see services start with creating a passkey and never collecting a password. The passkey portability specs will be implemented, and hopefully Gnome/KDE implement passkey support.
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?
I'd think it's exactly the same as using a password manager. Yes in theory you could memorize 500 unique passwords or write them down, but no one is doing that.
There are a few things unique to passkeys though. You can register multiple passkeys for the same account so you could in theory have a physical USB key and cloud synced passkeys. Not many people would do this I would think though it would be easier than memorizing every password. There are also data portability specs in progress right now that let you export/import passkeys between services.
But at the end of the day I would suggest that it should be straight up illegal for a company to freeze your account without letting you export your data. It probably actually is by the GDPR. This problem also already exists for email too. If Google bans you, you'll find a lot of your accounts become unusable. Anything with email OTPs wont work, and some services like Discord won't allow updating your email without access to the existing one.
It can't be the same as my password manager if email password reset flows disappear. If I lose access to my password manager but not my email, then I can go through and systematically reset all of the accounts that I remember exist. What you're describing with passkeys, though, would not allow me to do that.
> But at the end of the day I would suggest that it should be straight up illegal for a company to freeze your account without letting you export your data.
This would be great but it only addresses the least likely failure mode out of the ones that I brought up.
And note that in many cases we're currently better off under the existing system if Gmail does ban you than we would be in your proposed world: only services that send OTPs on every login would be immediately inaccessibile, so you'll have time for most services to log in and switch to a new email address.
I think for most services you'd still be able to email reset your passkeys unless it's a particularly sensitive service, the kind which don't allow email resets of your 2FA tokens today.
A password/passkey reset flow is semantically equivalent to an alternative login method and if done via email is semantically equivalent to a magic link.
Which means that any service that claims to be passkey-only but supports email resets should just acknowledge that they support both magic links and passkeys as options—they're kidding themselves and their users if they pretend otherwise.
Passkeys are at least more convenient than magic links as they do not require opening an email or pulling your phone out for an SMS code. You're right though that they Passkeys + email reset is no more secure than email magic links, but I'd say email magic links are perfectly secure for most use cases. There really is no reason to continue using passwords these days and every website should switch to either magic links, Email OTP, or passkeys.
For more sensitive accounts like bank accounts and government services. You'd probably have to go through some other reset process involving real ID and possibly an in person visit to a support location.
If your passkey manager account gets frozen the clients on all your devices should still have local copies of the passkey database that you could continue to use until you have a chance to export and migrate to another passkey manager.
Passkeys are essentially an API for logging into websites that requires a password manager to use. The end state is that we become completely dependent on our password managers. To avoid a single point of failure, hopefully you own multiple password managers, and they’re on independent devices, and there is a way to sync them.
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.
I think this is really great as a response to 404's post last week. I love 404 but I'm as annoyed by Magic Links as OP for the same reasons they mention.
Ricky Mondello wrote a really great blog last week[1] about how passkeys, as OP alludes to at the end, can be used alongside Magic Links, that I think is worth a read.
Thank you, this is a better piece than TFA! Reading TFA I was rather confused at how passkeys are an alternative to magic links—it makes a lot more sense to view them as a complement. Magic links allow you access to passkeys, which are basically "Remember this Computer" on steroids.
I haven't had these specific issues with magic links specifically, but I do remember when Epic launched the Epic Games Store and they would e-mail you two-factor codes to log in. I consistently had issues where I wanted to log into their store, got prompted to enter the two-factor code they e-mailed me, got no email for several minutes, requested another code, didn't get that either, gave up and did something else, and then got both codes 30 minutes later.
The fact is that even in the best of times, e-mail isn't reliable. Things go to your junk folder. Links get blocked by work spam filters. Mailboxes get full (I assume? it's been a while).
Personally, I have my e-mail on my iPhone and anywhere else (work laptop or gaming PC) I have to log into icloud.com to check my e-mail; it's cumbersome. Let me put in a password. Let me scan a QR code like embedded devices do. Give me at least one other option.
I seriously HATE magic links. My email inbox is barely better a social network's time suck. Lots of urgent, little important, wrecks any flow I had.
Forcing me into my inbox is highly likely to cause me to forget about the reason I was there (to get into your app). Or, at best, it slows me way down and nearly always breaks my flow.
Perhaps this is acceptable for the security boost (?) for the average user, but man, when I get forced into magic links I sometimes just abandon the app altogether.
Disclaimer:
1. I have/pay for a password manager, which helps with the forgotten password problem a lot. It also allows me to have extremely hard-to-crack passwords.
Totally agreed - a correctly used password manager is many, many times easier and faster to use than so-called magic links. It's not even a contest.
I'd even say magic link emails border on misuse of email; they're a fundamentally different form of communication from all other uses of email. It's not easy on neurodivergent brains to deal with that combination of pollution (magic links in my inbox) and distraction (actual emails in my face when I'm trying to log in and was not trying to check my email). Protonmail's client could really make my day if they found a way to reliably separate those 2 channels so I didn't have to even open my inbox to get login codes/links.
What I don't understand is why I've never been prompted to use a password manager by any site with a signup flow. It seems easier to normalize their use through messaging than keep acting like passwords are supposed to be something you consciously remember. Nobody should remember their passwords, except for maybe 2-3. But now we're moving toward a world where login just means more friction and less control instead...
That is a very good point! You'd have to be careful to craft the messaging so that it doesn't imply you can help troubleshoot the password manager.
But something simple could work. Already you usually have a note under a password field, "Must contain at least 8 characters and at least one special character" or something to that effect. It could also have some note about "We suggest a randomly generated password from your password manager."
I'm not building this out so I don't need every hole poked in the idea, just seems like it could work.
If someone is going to do this, 'At least one special character' etc. is not the way to do it. According to OWASP guidelines, a secure password must enforce a minimum length but not any other specific criteria, because they actually end up reducing password strength. Instead, the best option is to add a password strength indicator below the password entry field, to encourage the user to create a strong password. The help text can also mention using a password manager but it's difficult to do in a good way.
One of my pet peeves is when rules counteract the purpose they are supposed to serve, usually because of incompetence. Two years ago, I worked for a few months for a company where time reporting was accessed through a specific web page.
They required the password to be changed monthly, have at least 10 characters, at least one number and at least one special character. On top of that – they locked out password managers and pasting. "We need to make sure you are the one logging in and not a hacker that hacked your password manager" they explained when I asked.
Out of spite I went for "Password12!" the first month and "Password123!" the month after, at which point I received an email from the IT department explaining to me that my choice of password was endangering the corporations security.
You can tell them to write their password on a piece of paper in their drawer. Seriously.
Many home users are pretty good about protecting important scraps of paper. The government gives us plenty to hold onto. Even if they’re a grandma that doesn’t understand all this password manager mumbo jumbo, they can deal with a notebook and be better off than using the same password on every site.
Magic links breaking my flow is my top issue as well. My inbox is distracting: don't send me there. One affordance I've seen was a site that detected I was using gmail and crafted a link like https://mail.google.com/mail/u/0/#search/example.com, which brought me directly to the email I needed, while hiding everything else. I think it did a MX lookup to guess my provider.
I wish magic links would go away, but if they need to stay, that approach was the least terrible.
I use magic links for my enterprise application. In my humble opinion I believe magic links are fine.
Almost everyone outside of some HN users use email regularly. They have it open on a second monitor and it is an important part of their workflow.
If their companies are not super tech savvy and not using SSO, the users probably at least have a company email address they’re logged into.
I don’t think it’s worth over optimizing for a small percentage of users. Worst case scenario you need to contact support.
99% of enterprise users will be fine with magic links, compared to dealing with people who use horribly weak passwords. Most of them seem to prefer them to passwords.
SSO is always best option if available but magic links are definitely second.
Magic links are so useful in specific circumstances. We have a client with hundreds of users that infrequently need access to a bespoke tool.
Setting up and managing user accounts for them is out of the question, but a magic link letting them sign in using an email of their corporate domain solves the issue easily.
I'm having a good experience with a recently implemented magic link system. I did it via WhatsApp instead of email, which is much more reliable. Of course, this is only possible because in my country every single person uses WhatsApp.
I'm building something for a very tech illiterate audience, and everybody loves the simplicity of it.
I've been a loyal Mercury customer for a while now, but their forced use of magic links as a third authentication factor any time my IP address changes (after authenticating with a secure password from my password manager and after a valid TOTP) has me ready to move my company's banking elsewhere.
I could understand requiring a third factor to authenticate if signing in from a different location or a different ISP than I've been using for the past 5 years, but it's ridiculous to do so if nothing has changed (except the final octet of my DHCP-assigned address) since I last signed in yesterday. I use a different computer (via SSH) to read my email than I do for web browsing, and cutting-and-pasting a signin link that's hundreds of characters long (spanning multiple lines in Emacs, so I have to manually remove \ where it crosses line boundaries) is a PITA.
Adding friction on every sign-in colors all subsequent interactions I have with an app, and makes me hate using it.
You shouldn’t get the device verification requirement if you’ve used the device before (we store a permanent cookie to check this) or for the same IP. Any chance your cookies are being cleared regularly?
We added this after attackers created clones of http://mercury.com and took out Google ads for it. When customers entered their password and TOTP on the phishing site, the phisher would use their credentials to login and create virtual cards and buy crypto/gold/etc. The phisher would also redirect the user to the real Mercury and hope they figured it was a blip.
This device verification link we send authorizes the IP/device you open it on, which has almost entirely defeated the phishers.
Since WebAuthn is immune to this style of phishing attack, we don’t require device verification if you use it. I highly recommend using TouchID/FaceID or your device’s flavor of WebAuthn if you can—it’s more convenient and more secure. You can add it here: https://app.mercury.com/settings/security
That said, we are talking internally about your post and we do recognize that as IPv6 gets more traction IPs will rotate much more regularly, so we’ll think if we should loosen restrictions on being a same-IP match.
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:
I have to manually remove the backslashes and re-combine the lines before pasting into my web browser.
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?
You have to send emails through third parties or people won't get them, because you are also always sending them to third parties who host the recipients email and manage their spam. It might be a good reason not to send magic links but here we are talking about a tertiary confirmation, so its useless on its own right?
The link in the email could be a direct link to Mercury's website, rather than one that passes through a third-party HTTP redirect service.
Authentication tokens (even tertiary ones) usually are supposed to have pretty strong secrecy guarantees. I've done multiple security audits for SOC, PCI, HIPAA, etc., and in every case the auditors would have balked if I told them signin tokens were being unnecessarily logged by a third-party service.
(Also: I strongly disagree that the only way to get reliable delivery is via a third-party email service, especially at Mercury's scale, but that's a digression from the topic at hand.)
How is there no security issue here? Email is not secure and it's even less so when you are sending it via a 3rd party. If this were a photo site or something that would not be a big deal but we're talking about a bank. SMS is not much better. Like somebody said elsewhere in the thread, you should allow people to opt out of insecure third-factor verifications since they are just an annoyance and are ultimately security theater.
It's not security theater. He explained above how this is used to defeat a specific phishing attack that they've actually seen in the wild. There are other, different threat vectors (e.g. compromise of the mail server) that it doesn't prevent. But that doesn't make it theater. as it does provide other value.
What does it stop? You already did a 2FA at this point. If an attacker has my 2FA he most likely already has my email so the 'value' being provided is at the cost of more complexity for the user. If this adds value then why not also do an SMS as well to be really, really sure that the user is legit? That would add even more value.
And again, I wasn't saying that you can't do all of this nonsense, but users who see it as nonsense should be able to turn it off.
The attack wasn't that the attacker has my second factor, the attack was that the attacker tricked me into verifying a single login/transaction using my two factors, on their behalf.
They probably judged that the inconvenience of the verification email affects few enough users that it is worth it. Most users don't switch IP addresses very often. And those that do, probably don't all clear their cookies after every session.
Adding SMS in addition to email would be obviously useless, as you point out.
The emails in question are a third factor, not a magic login link.
Even if they were, almost all email goes through third parties which are trusted implicitly. That's not great, but email is the only federated system in existence capable of implementing this type of decentralized login at scale.
Maybe someday we'll be able to use something like Matrix, Fediverse OAuth, or ATProto OAuth instead, but those are all a ways off.
> passes through a third-party HTTP redirect service
The vendor might not be the only party to use an HTTP redirect service too! My email goes through a security screen by $EMPLOYER, which also rewrites links to get processed through their redirect service. Sure, it's for company-approved reasons, but it's still another party that has access to the login token.
How about giving me a setting to disable device verification: "I know how to type mercury.com into the URL bar and accept all risk of getting phished."
I appreciate you guys are trying to protect people, but no other financial institution I deal with requires this level of annoyance, and at some point I'd rather switch to a less "secure," but more usable service.
(I put secure in scare quotes, because some suggestions, like trading true 2FA, where I have two separate secrets on two separate devices, for a single WebAuthn factor, are actually accomplishing the opposite, at least for those of us who don't click links in emails and don't use ads on Google for navigation.)
Edit to add: or maybe save the third factor for suspicious activity, such as "new device adding a new payee," rather than every signin. It's been months since I onboarded a new vendor, and I'd be OK with only having to do the cut-and-paste-the-link dance a couple of times a year, rather than every single time I want to check my balance.
My understanding (as CEO of a startup using Mailgun for magic links) is that you're seeing mailgun in the URL because they have click tracking enabled — which, to be fair, is not super useful in the case of verification emails.
They could use a custom subdomain for this click tracking and "hide" the mailgun url from you, but we're finding that for some reason Mailgun doesn't just use a let's encrypt certificate, so some users will complain that the tracking links are "http" (and trigger a browser warning when clicked).
Anyway, even with click tracking disabled and links going straight to mercury.com, the security issue would remain the exact same (since Mailgun logs all outgoing email anyway).
But my understanding is that the contents of that email and its link do not provide "login" capability but "verification" capability. As such, a Mailgun employee accessing your data, or an attacker accessing your Mailgun logs, would only be able to "verify" a login that they had already initiated with your password AND your OTP —which means that's effectively a third hurdle for an attacker to breach, not a one-step jump into your account.
> 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.
I've seen passkeys support something like what you're after. The browser will produce a QR code you scan with your phone, and then you authenticate with the passkey via the phone, which then authorizes the original browser.
I'm not absolutely certain that this is part of the spec or how it actually works. I'd like to know. It solves a couple different usability issues.
This is the option I prefer, but only on sites that allow me to enroll more than one device (primary, and backup for if the primary gets lost or damaged). AFAICT, Mercury only allows a single security key.
I have an encrypted offline backup of my TOTP codes, so if I drop my phone on the ground, I don't get locked out of all my accounts. I keep this separate from the encrypted offline backup of the password manager on my computer, and as far as I know, neither has ever been uploaded to anyone else's "cloud." Malware would have to compromise two completely separate platforms to get into my accounts, rather than just iCloud or whatever credentials.
I understand the desire for phish-proof credentials, but—given that I don't click links in emails—my personal threat model ranks a compromised device (via attack against a cloud service provider, or software supply chain attack against a vendor with permission to "auto-update," or whatever) much higher likelihood than me personally falling victim to phishing. I readily admit that's not true for everyone.
> my personal threat model ranks a compromised device ... much higher likelihood than me personally falling victim to phishing
I completely understand that. I'd actually be interested in reading anything practical you might have on that topic if you don't mind. I asked some experts who gave a talk on supply chain security last year ... they didn't have a lot of positive things to say. Developing software feels like playing with fire.
It feels unstoppable, which is why the best I can do is try to mitigate its impact. Some mitigations that come to mind:
The development environment where I'm downloading random libraries is on a completely separate physical machine than my primary computer. I generally spin up a short-lived container for each new coding project, that gets deleted after the resulting code I produce is uploaded somewhere. This is completely separate from the work-supplied machine where I hack on my employer's code.
On my primary computer, my web browser runs in an ephemeral container that resets itself each time I shut it down. My password manager runs in a different, isolated, container. Zoom runs in a different, also isolated, container. And so on.
Wherever possible, I avoid letting my computer automatically sync with cloud services or my phone. If one is compromised, this avoids spreading the contagion. It also limits the amount of data that can be exfiltrated from any single device. Almost all of the persistent data I care about is in Git (I use git-annex for file sync), so there's an audit trail of changes.
My SSH and GPG keys are stored on a hardware key so they can't be easily copied. I set my Yubikey to require a touch each time I authenticate, so my ssh-agent isn't forwarding authentication without a physical action on my part. I cover my webcam when not in use and use an external microphone that requires turning on a preamp.
I try to host my own services using open source tools, rather than trust random SaaS vendors. Each internet-facing service runs in a dedicated container, isolated from the others. IoT devices each get their own VLAN. Most containers and VLANs have firewall rules that only allow outbound connections to whitelisted hosts. Where that's not possible due to the nature of the service (such as with email), I have alerting rules that notify me when they connect somewhere new. That's a "page" level notification if the new connection geolocates to China or Russia.
I take an old laptop with me when traveling, that gets wiped after the trip if I had to cross a border or leave it in a hotel safe.
I have good, frequent backups, on multiple media in multiple offline locations, that are tested regularly, so it's not the end of the world if I have to re-install a compromised device.
> The development environment where I'm downloading random libraries is on a completely separate physical machine than my primary computer. I generally spin up a short-lived container for each new coding project, that gets deleted after the resulting code I produce is uploaded somewhere. This is completely separate from the work-supplied machine where I hack on my employer's code.
Something like VS Code remote dev with a container per project? Just plain docker/podman for containers?
> On my primary computer, my web browser runs in an ephemeral container that resets itself each time I shut it down. My password manager runs in a different, isolated, container. Zoom runs in a different, also isolated, container. And so on.
Qubes, or something else? I've been looking at switching to Linux for a while, but Apple Silicon being as good as it is has made making that leap extremely difficult.
Mostly Linux with systemd-nspawn, also some Kubernetes, plus the occasional full VM. (If I were setting this up from scratch, I'd probably try to figure out how to run my desktop as 100% Kubernetes, using something like k3s, but I don't know how practical things like GPU access or Waypipe forwarding would be via that method.)
I live inside Emacs for most things except browsing the web, either separate instances via SSH, or using TRAMP mode.
If you switch to Linux, I highly recommend configuring your browser with a fake Windows or MacOS user agent string. Our Cloudflare overlords really, really hate Linux users and it sucks to continually get stuck in endless CAPTCHAs. (And doing so probably doesn't hurt fighting against platform-specific attacks, either.)
So you are intentionally crippling your browser and ability to access email (you need to ssh to another computer and access via terminal). You also aren’t able to handle emacs wrapping of long lines. And you are complaining that the security in place to prevent stolen credentials is “inconveniencing you”.
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.
> 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.
522 comments
[ 3.8 ms ] story [ 383 ms ] threadPaul Vixie had a great talk and research about this ~2018: https://www.youtube.com/watch?v=nkoNjntc5Lw
The term "Magic Links" once meant a [futuristic PDA](https://en.wikipedia.org/wiki/Magic_Link). Nowdays, companies like [Auth0](https://auth0.com/docs/authenticate/passwordless/authenticat...) use it to refer to the slightly-magical feat of including a login link in an email.
Last week, the great website you should subscribe to if you haven't already (it's great, when you're not logged out), [404 Media](https://www.404media.co/), posted ["We Don't Want Your Password"](https://www.404media.co/we-dont-want-your-password-3/) in defense of so-called magic links.
Of course, as stated in the article, such email links are harder to phish than passwords, can't lead to a breach of passwords, and protect the site itself against users who might reuse passwords previously compromised.
The article even covers some of my annoyances with this system, but throws out this sentence:
> [We find this to be a much easier login process and wish it was more common across the web where appropriate.](https://www.404media.co/we-dont-want-your-password-3/)
Easier than what? Easier than a long password, without a password manager? Easier than a passkey? Easier than an OTP sent to the same email address?
This sentence reads to me as one written by someone mostly working and _living_ from a single laptop and mobile device. The second part of the sentence, calling for more sites to do this is why I am writing this.
For any scenario with a minimal amount of complexity, like users with multiple computers, and you're looking at a scenario where the site's unwillingness to deal with other login methods shoves friction on the end-user.
### What makes them tragic:
1. Multiple devices. Who doesn't use at least a few computers weekly? I don't have my email on my gaming PC, nor do I have it on my work laptops. 1. Slower. From 2 seconds slower to minutes slower, depending on SMTP delays as well as how awkward it is to get the link to the right browser. 1. Anti-mobile. As mentioned by 404 in their own article, this breaks the ability to use in-app browsers, which is quite annoying especially for RSS reader type apps. It makes interacting with any local link in the RSS feed extremely annoying. 1. Indirect security downsides. Pushing people to access personal email on work devices (or vice-versa) isn't exactly a win for security.
Another annoying _passwordless_ system is to email or SMS an OTP the end user can type in.
While this sucks, it at least allows you to easily log in in situations where you don't have a clear and easy copy/paste path from the email client to the browser you want to log in to.
[Stratechery](https://stratechery.com/), powered by [Passport](https://passport.online), uses this type of scheme (click link OR type in OTP), which is still shifting annoyances onto end-users to free developers from implementing passkeys, but at least has a bit more of an appreciation for end-users.
If you insist on using magic/tragic links by default, at least consider offering a robust alternative...
Local convenience cookie for authenticating device and permi-cookie for requesting device.
Permanent cookies should be accompanied with a 4 digit numeric PIN between any critical functions unless the session is new.
edit: saw that nicce basically said that a second before I hit post.
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.
That makes it impossible to text or speak it to a phisher.
Bonus points if you show the symbol as a noisy animated glyph, something like [2], or a link to a DRM'd video showing a symbol. That would make it very difficult to view even with screen recording or remote desktop software.
[1] https://www.bombmanual.com/web/index.html#:~:text=On%20the%2...
[2] https://www.youtube.com/watch?v=RNhiT-SmR1Q
There's nothing stopping anyone else from initiating the flow assuming the common implementation where only an email is required to initiate sending the link.
Here is the link you requested from ‘Android Device’ in ‘Belarus’ - click here to sign in and allow that device to access your account - only click this if you requested this email
You don’t click the link if you didn’t request it.
This is a simple quick login process, you wouldn’t use it in a place where 2FA is required. It is a mistake to think of this as a substitute for 2FA just because it has some of the same elements as a secondary device authentication. It’s not intended to be a 2 FA flow though! It’s a single factor - ‘does the user have access to a device that can read emails sent to this associated email address’. We aren’t combining it with a password or anything else.
That is the same level of auth used for things on many services like ‘registering for a free account’, and frequently for ‘resetting the password on an account’.
It’s not a complete security solution and you wouldn’t use it everywhere. It would be a bad fit for a banking app or access to a publishing interface. It’s not a bad interface for things like ‘logging in to my subscription on the TV’ or ‘returning as a customer to a website I shopped with once before’.
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.
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.
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...)
Sites that send an OTP (crazy-pink-horse-3837) that you can copy, and paste is a good middle ground if implementing the link that just Auths the original request is too difficult.
It's super vague and unclear why things should work this way, and I don't know if this is forced on them by iOS or what. I'm trying to think of why choosing "Safari" in the gmail settings would use the webview instead of the app, and the most-charitable reason I can think of is that they don't want to contribute to the person having hundreds of Safari tabs open...?
Less-charitable reasons might include wanting to keep users in the gmail app for driving "engagement". I read somewhere that when apps use the in-app webview, the app dev can inject arbitrary javascript and thus has full control and can see keystrokes, what the webview's viewport is looking at, etc. I really don't think that's what google is trying to do here, though.
wrt reason : I think that the webview has cookie isolation from the actual app, so using the webview is a bit more privacy-protective. Google being Google that seems unlikely to be the motivating reason, but who knows what good may lurk in the heart of men...
In other words:
1. A malicious individual sends them a fake login link
2. The link can't ask them for a username and password because the site doesn't have passwords, just magic links
3. The site could ask them for your OTP code if they have one, but the bad actor doesn't have their magic link and the OTP code expires in a few seconds anyway
4. Without the bad actor actually getting access to a legitimate magic link nothing happens
It does solve the issue of:
1. You visit the site on your device at the same time as they visit on their device
2. They get two e-mails and maybe click on the one that approves your session instead
3. Your session on your device logs in; theirs doesn't so they figure it's a bug and go click the other one. Now you're both logged in.
If you require the session to be logged in by the link directly, it ensures that only the device you're viewing the e-mail on gets signed in; in the above scenario, your malicious session is never logged in, but their legitimate one is.
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.
OTP is far better than an actual magic link - you can still include a link that pre-fills the code.
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.
You still need another method for the first login.
Discord implements this feature, and this phishing scheme is extremely common: bots/scammers will message you saying "to access <some desirable content>, please scan this QR code" -- and if you scan the code, the scammers have just taken over your account. It's not much harder than rickrolling someone unless they're savvy enough to be aware of the scam.
Of course this can be mitigated somewhat by putting a big scary confirmation screen that says "don't click continue unless you're trying to log into your account from another device", but 1) users don't read, they just click "continue"; and 2) the attacker controls the narrative before the user clicks the QR code; they can craft the language to make the scary warning screen make sense to the user ("yes, I am trying to log into this discord server that this person sent me an QR code to").
> 1. Multiple devices. Who doesn’t use at least a few computers weekly? I don’t have my email on my gaming PC, nor do I have it on my work laptops.
"Who doesn’t use at least a few computers weekly?"
I don't. And many, many other people.
See what I did there? I assumed that everyone's like me, just like you did in your blog post. Without data, both of us are wrong.
----
I'd add that magic links also act as a distraction: you open your email client, and it by default opens your inbox, and you start going through all of those unread emails that you just found in your inbox...
Shopify is a big proponent for magic links because they went all-in on their new "Shop" customer accounts. What a disaster. Branding something with such a generic word as "shop" is terrible and average customer doesn't understand that it's supposed to be a brand name.
When you consider that a smartphone is "another" computer (or for many users, the computer that is not the smartphone is the "other" computer), I imagine that number goes way up. Someone using a computer at work and a personal phone, for example.
1. Include a fallback sign-in code in your magic link, in case the user needs to log in on a device where accessing their email isn’t practical.
2. Make sure the sign-in link can handle email clients that open links automatically to generate preview screenshots.
3. Ensure the sign-in link works with email clients that use an in-app browser instead of the user’s preferred browser. For example, an iOS user might prefer Firefox mobile, but their email client may force the link to open in an in-app browser based on Safari.
Any suggestions on what needs to be handled here? My first thought is UA checking to see if it looks like a real browser.
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.
I've had to implement a system where if the link was minted x minutes ago, the JavaScript on the landing page is disabled.
It's just another arms race. It shouldn't be this hard, but in email it seems everything is additionally harder to do.
Source?
Another is just counting if a link from an email was clicked. I want friction to be as little as possible. That's done by having some sort of redirect, but you have to use a JavaScript initiated post to weed add false positives. That's already ridiculous, but because of automated link prefetchers, you still need to disable that and show a f'n button.
And then I have to answer to clients that want to know why their clickthrough stats are down precipitously and I don't honestly have the wherewithall to explain the inner workers of every filter that snoops their email before they read it.
I think that a link to a page where you enter a one time code gets around a lot of these issues.
Sending a code goes around a lot of issues.
https://www.webnots.com/how-to-autofill-verification-codes-i...
2) hackers can exploit your system which hurts you (you are a VPS provider and someone mines crypto and you have to wave it for PR) or you run an email service and someone uses your app to spam (which hurts your email rep) etc.
36%.
1. Sixty percent seems astronomically high, do you have a source?
and
2. Most "normal" non-tech-savvy people I know who do use a password manager (which I've typically installed for them), are revealed a while later to still use a variation of password reuse : either storing the same password per category of websites, or having a password template they use on all sites, e.g. "IdenticalSecretWord_SiteName"
I definitely don't believe it for the wiser population (my gut, again based on people I know, says the number is more like 10%, maybe 15). Even the 36% figure on the report on security.org posted above seems dubious, I suspect they have some bias in their survey. Unless that is some people who use the iCloud password manager for some things and no password manager for everything else, so it isn't claiming 36% routinely use a password manager away from a few key accounts.
Higher level of security than just user+pass (w/ forgot password)
Email verification
Lifecycle management - in a SAAS when a user no longer has a corporate email, they can defacto not log in, wheras with a user+pass you need to remember to remove their account manually on each SAAS or have integration with your AD (for example)
One-time email verification is not the same as security model as magic links. Magic links require instant access. Many security sensitive sites require a time delay and secondary notification for password reset links, which you can’t reasonably do for login links.
Lifecycle management is an interesting point. There are some underlying assumptions that might not hold though—losing an email doesn’t necessarily mean downstream accounts should be auto disabled too. Think Facebook and college emails, for example.
It could be, depending on how the user has secured their email inbox access. I know I pay a lot more attention to my inbox than some random account. I don't have data, but I think this is true of most people.
I'm also more likely to enable MFA on my email account than I will on every random account I sign up for. And as far as the account providers, I trust the big email providers to be more secure than some random website with an unknown level of security.
You raise some valid points about tying access to a third party and what makes sense. It's not a simple issue.
Personally I'm no fan of magic links.
But the people who do like magic links would say the typical 'forgot password' flow is to send a password reset magic link by e-mail. That means you've got all the security weaknesses of a magic link, and the added weaknesses of password reuse and weak passwords.
Of course you can certainly design a system where this isn't the case. Banks that send your password reset code by physical mail. Shopping websites where resetting your password deletes your stored credit card details. Things like that.
That means you've got all the security weaknesses of a magic link, and the added weaknesses of password reuse and weak passwords.
Is objectively true. I don't really 'like' magic links but I think they're a very easy to implement and simple to use for infrequently accessed systems. Arguably easier than user/pass and certainly more secure.
Re Lifecycle management; Unless you're also linking a phone number or some other "factor" I think in a traditional user+pass scenario you're also SOL if you lose access to your $Email1 before you update your account to use $Email2, as changing your email to $Email2 would usually send a email to $Email1 to confirm the action. In that case you're in the same position as magic link login + email change functionality. Similarly Lifecycle management only comes for free if you don't implement email change functionality.
Just want to make sure magic links work as well as they can.
Different folks have different requirements, and since we're a devtool, we try to meet folks where they are at.
We actually recently added a feature which lets you examine the results of a login, including how the user authenticated, and deny access if they didn't use an approved method.
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.
That said, here’s how I would mitigate it:
- Like usual, time based limits on the code - Code is valid only for the initiating session, requiring the attacker to create a paper trail to phish
If you do have a magic link & want to use code as backup for authenticating a different device/browser, you could:
- Compare IP and/or session cookie between the initiating and confirming window. On match, offer login button. On mismatch, show the code and a warning stating how it’s different, eg ”You are signing in a different device or browser, initiated from $os $browser in $city, $country, $ip - $t minutes ago.”
It’s not perfect though and may still be prone to phishing.
I assume it generates a session on the post-login screen and authorize that session upon accessing link
People blindly click links all the time. It would have a low success rate, but would be more than 0%.
This works on 99% of magic links I've tried except for cases when they are trying to prevent account sharing. I remember the Bird bike app did this, where they required the magic link to be clicked on the same device login was initiated on. I was using my friends account and he would just forward me the link until one day this stopped working.
I feel the way Netflix did this broke the social contract of profile sharing on purpose - before, if you were a good tenant, you could freeload off another paid account without inconveniencing them at all. Memes and jokes formed of still being on an ex-partner's account or how people would rename themselves "Settings".
Getting an email and being harassed for the code by all those account sharers? Much more open and open for annoyingness.
Have your logging-in session wait for / poll "has visited magic link", and authenticate that session when it's done.
Tons of systems do this. It works great, and it can quite easily work without any web browser at all on the logging-in side because it just needs to curl something -> poll for completion and save the cookies -> curl against the API. A number of oauth flows for e.g. TVs work this way, for instance, because it's a heck of a lot easier than integrating a full browser in the [embedded thing]. Many app-based 2FA (e.g. Duo) works this way too.
Small code copying is also a very good answer though, yes. Roughly as easily manipulated, but nothing's perfect, and it's less "I didn't mean to click that button"-prone.
I don't mean to imply that just visiting the link should be enough to complete a login. That's a GET and there's a LOT of issues with doing anything important on GET. Just "do something on a different machine, then automatically complete login on the one logging in", and magic links to trigger that flow are a rather straightforward option.
There's no reason at all that it has to all occur on the same machine, and many reasons why attempting to require that doesn't work out in practice even when it does happen on the same machine.
TVs etc. are special cases because obviously there is no way to redirect to them, and even there developers will always have some kind of secondary checks like having you enter a code displayed on the screen.
But somehow, the desktop browser and my mobile are tied together for this app. But no other sites have this magic.
Google does it. Paypal does it. Duo does it. Lots of single-sign-on systems do it. All of those including not-TV scenarios, just normal computer-and-phone stuff, as well as sometimes other weird flows. Many of these are far beyond what most would label as "security competent", into "login security is a large part of their business and they have significant numbers of specialists hired".
(it is probably safe to say none are "truly secure" or "actually security obsessed", but I doubt that's actually possible in large quantities. the requirements are too steep, for both implementers and users.)
It's not the most common, certainly, nor anywhere close. But it's very far from nonexistent.
1. Attacker starts a log in and triggers a magic link email 2. Email received and my browser client previews the link without my desire 3. Attacker is now logged in
so I got the magic link on their computer and then I made a qr code
but wait, the email quarantine system had altered the whole link so I had to extract that
but wait the redirect url back to slack was malformed because of the url encoding and i had to fix that and then make the qr code
like wow just give me a qr code or code instead in the original magic link email!
Maybe this one email would have been fine, but if it gets tripped, it’s not worth the headache.
I'm not suggesting this is actually a problem, but that's how an argument could go.
If they specifically ask for documents that are not relevant or if their request is too broad so will produce a lot of irrelevant documents your company's lawyers will tell them no.
By the time someone is actually specifically giving you a list of things to turn over that includes your private email it will only be asking for things that are relevant. Most of your personal email will be excluded.
When McDonald's switched from email/password to magic links I had a hard time getting the magic link to work with the McD app. It usually would just open in the McD website.
Thus was quite annoying because about 98% of the time I eat McD's I would not do so if I could not order via the app [1].
I finally gave up and switched to using "Sign in With Apple" (SIWA). There was no way that I could find to add SIWN to an existing McD account, so had to use the SIWA that hides the real email from McD. That created a new McD account so I lost the reward points that were on the old account, but at least I could again use the McD app.
[1] They have a weekly "Free Medium Fries on Friday" deal in the app available for use on orders of at least $1. Almost every Friday for lunch I make a sandwich at home and then get cookies and the free fries to go with it from McD.
Three large fries ordered at the counter costs over ten dollars.
But the more people use the app, the less cashiers they need and the less ordering kiosks they have to install. Plus customer satisfaction goes up because you can order ahead and your food is ready when you arrive. And getting used to the discounts means you probably won't switch to Burger King or Wendy's.
I think additional user data is a relatively minor part of it.
That just sounds like a great way to get cold McDonald's...
> I think additional user data is a relatively minor part of it.
You're probably right about that, but I've always undervalued user data because I don't think it's ethical to exploit people like that.
I'm sure that a well-timed push notification suggesting a personalized meal deal right around hungry-o'clock is the real goal of pushing this stupid app on their customers.
> That just sounds like a great way to get cold McDonald's...
The idea is to order 3 or 4 minutes in advance, not half an hour before...
Don't they have only the last 4 digits and the issuer of the card? It is likely enough but there will be some noise.
Not to mention any potential legal trouble if they used the card details without explicit consent. App contracts will get around that.
The food does NOT start cooking when you order it if you’re picking up at drive thru. It starts cooking when you pull up to drive thru and give the magic code.
In fact if the food is not easy to prepare you get put in a special parking space, where you wait for your order to be prepared. If it includes soft drinks they might serve those before they make you go park.
At this point, being a fast food chain that doesnt have an app with deals is probably not viable - but I am very skeptical it generates any loyalty.
When they began "value meals" last summer (which don't include their flagship items) they also removed the best deals from the app, the ones that did include Big Mac, QPC, 10-nuggets. I've placed one non-breakfast order in 6-8 months, whenever they started this.
I'm just one person, but if a customer declines from an expected 15-20 visits over a half-year period to 1, and you don't adjust your offer algorithm (and you're the biggest restaurant company in the world so no lack of resources), something is seriously wrong.
Whatever they're doing also isn't working for me.
They've captured the user base with the money that corporate was pumping into the app deals, and are in the process of enshittifying it by transferring the value to themselves instead of the users.
If McDonald's enshittifies its deals while continuing to raise prices, it's way too easy for loyal customers to go elsewhere. I'm saying this as a huge fan and extremely loyal customer of McDonald's for decades... they are at serious risk of losing people like me. As I stated, I've gone from 15-20 visits to 1 since last June/July, whenever they made the big change.
I agree with you that I'd be surprised if Enshittification works as well here as it does in tech, but maybe since there's an app involved, they just think they can get away with it. Who knows.
That's the whole point of data analytics and personalized marketing - even if the value meal works for most people they can still go back to sending me the offers and promotions I responded to previously, in an attempt to reverse my recent decline in spend/visitation. The app makes it possible to send individualized offers. There shouldn't be an entire "B" group where they just say, oh well.
Ask for a “bundle box” next time you’re there. They’re usually named after a local sports team.
Two Big Macs, two cheeseburgers, two fries, and a 10-piece nuggets for $12-15 depending on the market.
I think retail for just the Big Macs is that much these days.
No app required.
This is kind of hilarious and depressing but I live in a high enough cost of living city in the states and I order mcd’s rarely enough that I cannot tell contextually whether your statement indicates this is overpriced or underpriced.
However since the rollout of "value meals" last summer, they took away some of the better deals and now McDonald's is simply expensive (for McDonald's) even with the app.
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.
Recently ran into this issue as new mail accounts got confirmed automatically and magic links were invalid when the user clicked them, because Microsoft already logged in with it during checking.
The alternative is to send an OTP in the mail and tell the user to enter that.
In that way there is no link to auto confirm.
However, if you do that ensure that you have a way to jump straight to the page to enter the OTP because (looking at you Samsung) the account registration process can expire or the app is closed (not active long enough) and your user is stuck
The issue that MS tools introduced is broader, because it affects also email confirmation flows during signups. This is less visible, because usually the scanners will confirm emails that the user would like to confirm anyway. But without additional protection steps, the users can be signed up for services that they didn't request and MS tools will automatically confirm such signups.
Thanks for checking if it's the same browser. Some companies don't care about that (cough booking cough) so harmful actors just spam users with login attempts in hope a user will click by accident. And puff, random guy gets full access to your account. I got those every day, if I ever needed to login this way I would not be able to figure out which request is mine.
I think it should check if browser requesting is the same as the one confirming, or just drop that whole dumb mechanism entirely.
Will Microsoft automatically authenticate malicious actors, or block yourself from services built with assumptions that the email client won't auto-click everything?
See also this issue which suggests that all links are opened: https://techcommunity.microsoft.com/discussions/microsoftdef...
Note that this doesn't affect all Outlook users, this Microsoft Defender for Office 365 is a separate product that only some companies use.
Indeed it's a bad thing but how bad?
The admins of some web service get a database of emails, send them those registration links, make their mail software create the accounts and? They end up with a service with accounts that they could create without sending those emails, before they send some emails to solicit users to perform some action on their (long forgotten?) account. There is no additional threat unless I'm missing something.
The admins have only an extra thin layer of protection because of the confirmation step but I think that any court can see through it.
Another example would be if a company hosted a web app for employees that allowed signups only from @company.com addresses. In such case an attacker could be able to signup with such an address.
What an insane policy, why am I surprised Microsoft came up with it…
This problem is ~20 years old from when CMS platforms had GET links in the UI to delete records and "browsing accelerator" browser extensions came along that pre-fetched links on pages, and therefore deleted resources in the background.
At the time the easiest workaround was to use Javascript to handle the link click and dynamically build a form to make a POST request instead (and update your endpoint to only act on POST requests), before the fetch API came along.
Yes. Linking to a form requiring user to press a button to submit an actual POST request is one proper way of doing it, and won't confuse prefetchers, previewers and security scanners - but it lacks the specific "magic" in question, which is that clicking on a link alone is enough to log you in.
Can't really have both - the "magic" is really just violating the "GET doesn't mutate" rule, rebranding the mistake we already corrected 20+ years ago.
(EDIT: Also the whole framing of "magic links" vs. passkeys reads to me like telling people that committing sins is the wrong way of getting to hell, because you can just ask the devil directly instead.)
Your theological analogy is hilarious!
Having a code completely negates that advantage, as attackers can just set up a fake website that asks for the code.
Magic links should log you in on the device you click them, not on the device that requested the login session. Anything else, while being a little bit less annoying, is a security issue and should be treated as such.
I don't like that for a number of reasons.
It's all trade offs, else it would be easy.
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]".
Hey, wasn’t Firefox on iOS based on Safari related tech anyways?
https://en.m.wikipedia.org/wiki/Firefox
> However, as with all other iOS web browsers, the iOS version uses the WebKit layout engine instead of Gecko due to platform requirements.
I do agree with what you’re saying though! Just those two in particular will probably have pretty good compatibility, which I was amused to find out when I looked into it.
Obviously, your mileage may vary but it was a good reminder to always validate your assumptions, especially in your critical user flows.
How are you tracking login success rates?
You can use Mixpanel or Heap, which have mechanisms for mapping the non-logged-in user to your verified user on login, though you might need a bit of custom code to do it.
I've not tried June, so I can't say for sure, but it's a pretty common feature for product analytics. I'll be surprised if it's not possible.
With Stratechery, once you get to the website with the magic link, I can then copy the authenticated podcast RSS feed to Overcast and the authenticated RSS feed for the articles to NetNewsWire.
Those subscriptions are then synced to Overcast and NNW on my iPad and Mac via iCloud.
Each podcast RSS link is personalized and you go to the show notes page and click on the link to Manage your account. It will take you to the website using the embedded browser where you can manage your subscription and get access to the various feeds.
Speaking of Overcast, even though its doesn’t create a username and password by default, you can create one. But it’s only to access the web version of Overcast.
It will give you all of the links to all of your podcasts. I did this from the “Dithering” podcast notes
https://imgur.com/a/ThbTaly
This gets the best of both worlds: the security of passkeys on existing devices, and the passwordless setup and account recovery for new devices.
Bonus: it even avoids vendor lock-in where cloud providers have all your passkeys.
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.
As long as the user keeps a relatively stable set of devices and knows to be suspicious if they get asked for an OTP on a device that they know has a passkey. If they don't know to be suspicious (which let's be real, most people won't), they'll happily follow the instructions and fork over the OTP to a phisher who can use it to complete the authentication somewhere on their end.
Magic links without an OTP fallback are more secure as the initial setup process because they can't be phished unless someone's actually MITM'ing their HTTPS traffic (at which point nothing can save you anyway). A phisher can get someone to send themselves a magic link, but it's much harder to get them to provide the link to them.
It's not that much harder. 'Due to security reasons, please copy and paste the entire link that we just sent you into the following input box. If you don't, your account will be compromised!'
Since the application only sends a weekly email (a markdown template for goal/task tracking) it seemed easier to just use a magic link, only.
I am happy at how much easier the auth code ended up, and fail to see much downside for such an application.
I'm not sure it would be a good system for more complex apps and services.
If you want strong security, offer passkey login. It's safer than email and much more user friendly especially with FaceID/TouchID on Apple devices.
Would it be possible to bookmark the login link so that in the future I don't first have to go to my email in order to log into the service?
Shopify works this way where buyers don't have passwords and only log in with codes sent via SMS/Email.
Every implementation of passkeys I've seen has presented me with the option to create a passkey after I've already logged in with some other method. I'll admit that I haven't dug into it deeply, but the UX I've been presented with consistently makes passkeys appear to be an alternative to the "Remember this computer" button, not to passwords in general. Somehow the service has to know that this new device is authorized. I know depending on the provider there's such a thing as passkey syncing, but that doesn't solve the problem of getting the initial authentication done.
The key insight with magic links is that your security system is no stronger than its recovery mechanism. We are never going to get to a world where passkeys are treated as the only authentication mechanism—there will always be a recovery mechanism, and in most cases an automated one via email. Given that that is the case, magic links simplify things by just not pretending that we have a more secure layer on top. By making the recovery mechanism the primary means by which you interact with the authentication flow you're being more honest about the actual security of your auth system.
Edit: filmgirlcw has a link to an article that is much better than this one that explains how the two actually complement each other: https://news.ycombinator.com/item?id=42628226
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.
> take 30 seconds to complete
also, ouch.
This is a solution for the masses. If you're not comfortable with it, nobody is forcing you to use it, and it certainly doesn’t diminish the value passkeys provide over traditional passwords and OTPs for the vast majority of people.
> Bluetooth is basically comprised of a giant bag of vulnerabilities and weaknesses.
That doesn’t really matter. The whole point of passkeys is their cryptographic primitives make snooping on the handshake pointless. Everything is E2E between the passkey provider, and the site you’re authenticating against. There’s no dependency on Bluetooths security to ensure that the actual passkey handshake is secure.
> > take 30 seconds to complete
> also, ouch.
That includes the time taken to fish my phone out of my pocket.
There are definite UX problems around passkeys that could be improved and I think exporting will make syncing across systems a lot better (one of the reasons I use 1Password as my primary password and passkey system is so I can use my passkeys across devices; of course it helps that my employer uses 1Password as our system so I am logged into my personal and enterprise accounts and can auth then from personal or work devices, provided additional auth or enrollment isn't needed) -- but if the problem as 404 defines it is that they don't want to be responsible or even have to worry about storing your passwords/auth controls, I think passkeys is at least better for a subset of users than Magic Links.
But again, like Ricky, I don't think it should be viewed as either or. It should be both.
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
> 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.
That's a good point. I guess my rationale is that it being explicit makes me feel less comfortable for my parents/non tech-savvy friends, who already may not follow best-practices for email hygiene (and may not use email providers that enforce stricter hygiene like 2FA or other methods of protection) and thus, systems like this, make their email even more explicitly the ultimate place to go for access to stuff.
making people feel less comfortable is probably a good thing.
i've managed to convince my dad to start taking his email security more seriously by reminding him a few times that if somebody gets access to his email, they can reset his password on every site where he uses that email address. it's good to remind people of why email security matters, and that it's not just about the personal messages from friends.
Well, don't do that.
Social key recovery is an underutilized solution as well.
Of course, any website's auth system is as weak (or strong) as their recovery process. Different sites will implement this differently.
Like what? I'm failing to come up with a single benefit (for the user).
Give it a few more years and I suspect we will start to see services start with creating a passkey and never collecting a password. The passkey portability specs will be implemented, and hopefully Gnome/KDE implement passkey support.
There are a few things unique to passkeys though. You can register multiple passkeys for the same account so you could in theory have a physical USB key and cloud synced passkeys. Not many people would do this I would think though it would be easier than memorizing every password. There are also data portability specs in progress right now that let you export/import passkeys between services.
But at the end of the day I would suggest that it should be straight up illegal for a company to freeze your account without letting you export your data. It probably actually is by the GDPR. This problem also already exists for email too. If Google bans you, you'll find a lot of your accounts become unusable. Anything with email OTPs wont work, and some services like Discord won't allow updating your email without access to the existing one.
> But at the end of the day I would suggest that it should be straight up illegal for a company to freeze your account without letting you export your data.
This would be great but it only addresses the least likely failure mode out of the ones that I brought up.
And note that in many cases we're currently better off under the existing system if Gmail does ban you than we would be in your proposed world: only services that send OTPs on every login would be immediately inaccessibile, so you'll have time for most services to log in and switch to a new email address.
Which means that any service that claims to be passkey-only but supports email resets should just acknowledge that they support both magic links and passkeys as options—they're kidding themselves and their users if they pretend otherwise.
For more sensitive accounts like bank accounts and government services. You'd probably have to go through some other reset process involving real ID and possibly an in person visit to a support location.
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.
Ricky Mondello wrote a really great blog last week[1] about how passkeys, as OP alludes to at the end, can be used alongside Magic Links, that I think is worth a read.
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
I'm still used to Apple people being almost completely invisible publicly.
The fact is that even in the best of times, e-mail isn't reliable. Things go to your junk folder. Links get blocked by work spam filters. Mailboxes get full (I assume? it's been a while).
Personally, I have my e-mail on my iPhone and anywhere else (work laptop or gaming PC) I have to log into icloud.com to check my e-mail; it's cumbersome. Let me put in a password. Let me scan a QR code like embedded devices do. Give me at least one other option.
Agreed with some other folks that Passkeys is not a replacement for email verification.
I seriously HATE magic links. My email inbox is barely better a social network's time suck. Lots of urgent, little important, wrecks any flow I had.
Forcing me into my inbox is highly likely to cause me to forget about the reason I was there (to get into your app). Or, at best, it slows me way down and nearly always breaks my flow.
Perhaps this is acceptable for the security boost (?) for the average user, but man, when I get forced into magic links I sometimes just abandon the app altogether.
Disclaimer: 1. I have/pay for a password manager, which helps with the forgotten password problem a lot. It also allows me to have extremely hard-to-crack passwords.
I'd even say magic link emails border on misuse of email; they're a fundamentally different form of communication from all other uses of email. It's not easy on neurodivergent brains to deal with that combination of pollution (magic links in my inbox) and distraction (actual emails in my face when I'm trying to log in and was not trying to check my email). Protonmail's client could really make my day if they found a way to reliably separate those 2 channels so I didn't have to even open my inbox to get login codes/links.
What I don't understand is why I've never been prompted to use a password manager by any site with a signup flow. It seems easier to normalize their use through messaging than keep acting like passwords are supposed to be something you consciously remember. Nobody should remember their passwords, except for maybe 2-3. But now we're moving toward a world where login just means more friction and less control instead...
But something simple could work. Already you usually have a note under a password field, "Must contain at least 8 characters and at least one special character" or something to that effect. It could also have some note about "We suggest a randomly generated password from your password manager."
I'm not building this out so I don't need every hole poked in the idea, just seems like it could work.
They required the password to be changed monthly, have at least 10 characters, at least one number and at least one special character. On top of that – they locked out password managers and pasting. "We need to make sure you are the one logging in and not a hacker that hacked your password manager" they explained when I asked.
Out of spite I went for "Password12!" the first month and "Password123!" the month after, at which point I received an email from the IT department explaining to me that my choice of password was endangering the corporations security.
Sounds like they were logging/storing passwords in plaintext.
And password managers (keepassxc anyways) have a pretty nifty auto-type feature that gets around that anyways.
Many home users are pretty good about protecting important scraps of paper. The government gives us plenty to hold onto. Even if they’re a grandma that doesn’t understand all this password manager mumbo jumbo, they can deal with a notebook and be better off than using the same password on every site.
I wish magic links would go away, but if they need to stay, that approach was the least terrible.
Almost everyone outside of some HN users use email regularly. They have it open on a second monitor and it is an important part of their workflow.
If their companies are not super tech savvy and not using SSO, the users probably at least have a company email address they’re logged into.
I don’t think it’s worth over optimizing for a small percentage of users. Worst case scenario you need to contact support.
99% of enterprise users will be fine with magic links, compared to dealing with people who use horribly weak passwords. Most of them seem to prefer them to passwords.
SSO is always best option if available but magic links are definitely second.
I'm building something for a very tech illiterate audience, and everybody loves the simplicity of it.
I could understand requiring a third factor to authenticate if signing in from a different location or a different ISP than I've been using for the past 5 years, but it's ridiculous to do so if nothing has changed (except the final octet of my DHCP-assigned address) since I last signed in yesterday. I use a different computer (via SSH) to read my email than I do for web browsing, and cutting-and-pasting a signin link that's hundreds of characters long (spanning multiple lines in Emacs, so I have to manually remove \ where it crosses line boundaries) is a PITA.
Adding friction on every sign-in colors all subsequent interactions I have with an app, and makes me hate using it.
You shouldn’t get the device verification requirement if you’ve used the device before (we store a permanent cookie to check this) or for the same IP. Any chance your cookies are being cleared regularly?
We added this after attackers created clones of http://mercury.com and took out Google ads for it. When customers entered their password and TOTP on the phishing site, the phisher would use their credentials to login and create virtual cards and buy crypto/gold/etc. The phisher would also redirect the user to the real Mercury and hope they figured it was a blip.
This device verification link we send authorizes the IP/device you open it on, which has almost entirely defeated the phishers.
Since WebAuthn is immune to this style of phishing attack, we don’t require device verification if you use it. I highly recommend using TouchID/FaceID or your device’s flavor of WebAuthn if you can—it’s more convenient and more secure. You can add it here: https://app.mercury.com/settings/security
That said, we are talking internally about your post and we do recognize that as IPv6 gets more traction IPs will rotate much more regularly, so we’ll think if we should loosen restrictions on being a same-IP match.
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:
I have to manually remove the backslashes and re-combine the lines before pasting into my web browser.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?
Authentication tokens (even tertiary ones) usually are supposed to have pretty strong secrecy guarantees. I've done multiple security audits for SOC, PCI, HIPAA, etc., and in every case the auditors would have balked if I told them signin tokens were being unnecessarily logged by a third-party service.
(Also: I strongly disagree that the only way to get reliable delivery is via a third-party email service, especially at Mercury's scale, but that's a digression from the topic at hand.)
That said, our security team and I agree there is no security issue here. Mailgun already can see the text of the emails we send.
And again, I wasn't saying that you can't do all of this nonsense, but users who see it as nonsense should be able to turn it off.
The attack wasn't that the attacker has my second factor, the attack was that the attacker tricked me into verifying a single login/transaction using my two factors, on their behalf.
They probably judged that the inconvenience of the verification email affects few enough users that it is worth it. Most users don't switch IP addresses very often. And those that do, probably don't all clear their cookies after every session.
Adding SMS in addition to email would be obviously useless, as you point out.
Even if they were, almost all email goes through third parties which are trusted implicitly. That's not great, but email is the only federated system in existence capable of implementing this type of decentralized login at scale.
Maybe someday we'll be able to use something like Matrix, Fediverse OAuth, or ATProto OAuth instead, but those are all a ways off.
The vendor might not be the only party to use an HTTP redirect service too! My email goes through a security screen by $EMPLOYER, which also rewrites links to get processed through their redirect service. Sure, it's for company-approved reasons, but it's still another party that has access to the login token.
To be clear this is what we're trying to avoid. An easily typeable code like that can be typed into a phisher's website.
I appreciate you guys are trying to protect people, but no other financial institution I deal with requires this level of annoyance, and at some point I'd rather switch to a less "secure," but more usable service.
(I put secure in scare quotes, because some suggestions, like trading true 2FA, where I have two separate secrets on two separate devices, for a single WebAuthn factor, are actually accomplishing the opposite, at least for those of us who don't click links in emails and don't use ads on Google for navigation.)
Edit to add: or maybe save the third factor for suspicious activity, such as "new device adding a new payee," rather than every signin. It's been months since I onboarded a new vendor, and I'd be OK with only having to do the cut-and-paste-the-link dance a couple of times a year, rather than every single time I want to check my balance.
They could use a custom subdomain for this click tracking and "hide" the mailgun url from you, but we're finding that for some reason Mailgun doesn't just use a let's encrypt certificate, so some users will complain that the tracking links are "http" (and trigger a browser warning when clicked).
Anyway, even with click tracking disabled and links going straight to mercury.com, the security issue would remain the exact same (since Mailgun logs all outgoing email anyway).
But my understanding is that the contents of that email and its link do not provide "login" capability but "verification" capability. As such, a Mailgun employee accessing your data, or an attacker accessing your Mailgun logs, would only be able to "verify" a login that they had already initiated with your password AND your OTP —which means that's effectively a third hurdle for an attacker to breach, not a one-step jump into your account.
I've seen passkeys support something like what you're after. The browser will produce a QR code you scan with your phone, and then you authenticate with the passkey via the phone, which then authorizes the original browser.
I'm not absolutely certain that this is part of the spec or how it actually works. I'd like to know. It solves a couple different usability issues.
You could always use something like a Yubikey.
This is the option I prefer, but only on sites that allow me to enroll more than one device (primary, and backup for if the primary gets lost or damaged). AFAICT, Mercury only allows a single security key.
I have an encrypted offline backup of my TOTP codes, so if I drop my phone on the ground, I don't get locked out of all my accounts. I keep this separate from the encrypted offline backup of the password manager on my computer, and as far as I know, neither has ever been uploaded to anyone else's "cloud." Malware would have to compromise two completely separate platforms to get into my accounts, rather than just iCloud or whatever credentials.
I understand the desire for phish-proof credentials, but—given that I don't click links in emails—my personal threat model ranks a compromised device (via attack against a cloud service provider, or software supply chain attack against a vendor with permission to "auto-update," or whatever) much higher likelihood than me personally falling victim to phishing. I readily admit that's not true for everyone.
We allow multiple security keys. You can add more here: https://app.mercury.com/settings/security
I completely understand that. I'd actually be interested in reading anything practical you might have on that topic if you don't mind. I asked some experts who gave a talk on supply chain security last year ... they didn't have a lot of positive things to say. Developing software feels like playing with fire.
The development environment where I'm downloading random libraries is on a completely separate physical machine than my primary computer. I generally spin up a short-lived container for each new coding project, that gets deleted after the resulting code I produce is uploaded somewhere. This is completely separate from the work-supplied machine where I hack on my employer's code.
On my primary computer, my web browser runs in an ephemeral container that resets itself each time I shut it down. My password manager runs in a different, isolated, container. Zoom runs in a different, also isolated, container. And so on.
Wherever possible, I avoid letting my computer automatically sync with cloud services or my phone. If one is compromised, this avoids spreading the contagion. It also limits the amount of data that can be exfiltrated from any single device. Almost all of the persistent data I care about is in Git (I use git-annex for file sync), so there's an audit trail of changes.
My SSH and GPG keys are stored on a hardware key so they can't be easily copied. I set my Yubikey to require a touch each time I authenticate, so my ssh-agent isn't forwarding authentication without a physical action on my part. I cover my webcam when not in use and use an external microphone that requires turning on a preamp.
I try to host my own services using open source tools, rather than trust random SaaS vendors. Each internet-facing service runs in a dedicated container, isolated from the others. IoT devices each get their own VLAN. Most containers and VLANs have firewall rules that only allow outbound connections to whitelisted hosts. Where that's not possible due to the nature of the service (such as with email), I have alerting rules that notify me when they connect somewhere new. That's a "page" level notification if the new connection geolocates to China or Russia.
I take an old laptop with me when traveling, that gets wiped after the trip if I had to cross a border or leave it in a hotel safe.
I have good, frequent backups, on multiple media in multiple offline locations, that are tested regularly, so it's not the end of the world if I have to re-install a compromised device.
Something like VS Code remote dev with a container per project? Just plain docker/podman for containers?
> On my primary computer, my web browser runs in an ephemeral container that resets itself each time I shut it down. My password manager runs in a different, isolated, container. Zoom runs in a different, also isolated, container. And so on.
Qubes, or something else? I've been looking at switching to Linux for a while, but Apple Silicon being as good as it is has made making that leap extremely difficult.
I live inside Emacs for most things except browsing the web, either separate instances via SSH, or using TRAMP mode.
If you switch to Linux, I highly recommend configuring your browser with a fake Windows or MacOS user agent string. Our Cloudflare overlords really, really hate Linux users and it sucks to continually get stuck in endless CAPTCHAs. (And doing so probably doesn't hurt fighting against platform-specific attacks, either.)
Not sure why we suddenly went from 2 factors (password + TOTP) to 1 factor (passkey), even if passkeys themselves are better.
TOTP should at least be an option for the users.
security = 1/convenience
but also vice versa
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.