[jeremyjh]

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?

[dpifke]

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

[MaxGabriel]

Oh good find, the link going through Mailgun as a redirect is a recent regression. We have a PR to fix that going live soon.

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.

[dexterdog]

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.

[apitman]

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.

[adastra22]

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.

[dexterdog]

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.

[Jolter]

Again, see the post by MaxGabriel at https://news.ycombinator.com/item?id=42629109 where he explains how this measure actually defeated that particular pihishing/MITM attack.

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.

[edaemon]

Why would the attacker having your Mercury TOTP mean they most likely have access to your email?

[mbreese]

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