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.

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.

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.

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.

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

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.

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%.

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.

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.

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.

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.

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 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.

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

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.