[MaxGabriel]

I’m the CTO of Mercury

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.

[dpifke]

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:

  https://email.mg.mercury.com/c/eJxMzs1u4jAUBeCncXZB9vVfvPACZshoWIwYoiasdgkra2KV_JCGqPTpK-imq7xxx40vlO9IKia6ggL6zUlQHObdF6\
  JI0alRHBWQvWKRuD4loLZxsJSRXZAwfNBQeQWozasdgeWsMyFZozE4RKZ4d151NOFtuq9w6IqLb-d5fGdyzaBmUIdx_NkzqBeacrqXkZaMxGSNQyQmf7_9GW7\
  Hf1cJ8zW9TshAwwba3ccLuN3u_r_PR9j_GkxxxmadDu32c59jMfkYFmKKP0baIT0vzP4ynHN_-yyhZOTy9jmPPQn6gL-VLMfvvIA_XxbywRYhUbZUp0RpVCUC\
  qDsbasJHeObFMZ4YrFw1cAAAD__4XPZXw

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?

[incompatible]

I set Firefox to delete cookies at shutdown, and also an add-on called Cookie AutoDelete, but they both have an option to whitelist a site.

[packtreefly]

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

You could always use something like a Yubikey.

[dpifke]

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

[packtreefly]

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

[dpifke]

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.

[packtreefly]

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

[MaxGabriel]

> AFAICT, Mercury only allows a single security key.

We allow multiple security keys. You can add more here: https://app.mercury.com/settings/security

[dpifke]

Oh, nice! This wasn't obvious from the help text. Maybe add it to the FAQ on the "Adding security keys" sidebar?

[watermelon0]

Is there a reason that TOTP cannot be used as a second factor when using Passkeys?

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.

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

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

[mhitza]

At the very least, you can be creative with workarounds for such issues. A bookmarklet can be convenient.

    javascript:void(window.location.href = window.prompt().replace(/\\\n\s*/g, ''));

[thefreeman]

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

[adastra22]

Pretty sure that is eMacs formatting, not the email itself? Can you kill-copy the URL?

[lyime]

What would be a more secure (yet reliable) method for email delivery for such emails?

[dpifke]

Make the link in the email https://mercury.com/something instead of https://mailgun.com/something (which then redirects to https://mercury.com/something). Or (in addition to, or instead of, a hyperlink) provide a 6-10 digit numeric or alphanumeric code that could be copied out of the email message into a form field on the signin screen.

[MaxGabriel]

> 6-10 digit numeric or alphanumeric code that could be copied out of the email message into a form field on the signin screen.

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.

[dpifke]

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.

[sebastiennight]

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.

[miyuru]

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

[m463]

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.

security = 1/convenience

but also vice versa