[orev]

After reading that, nobody should be taking security advice from you and I would avoid using your product. Most of the piece is spent talking about UX (which is almost always in conflict with security), and ignored the extremely large problem that email is sent over the Internet without encryption, and then sits on some cloud server somewhere without encryption. Maybe that’s fine for managing a newsletter subscription, but it’s complicated inappropriate for anyone wanting real security.

[prash_murali21]

Perhaps a better title would be "trade-offs between security and UX for Magic Links"? Actually agree with most of what you said (bar the first sentence ;))

2 key things highlighted in the post though:

1. The trade-offs you take are entirely dependent on the type of web app you have and there isn't really a one size fits all solution (nor should there be). If you are having a banking app vs a newsletter subscription, of course the solution would (and should) be different. You can always supplement the email magic links with 2FA based on "something you have" like SMS, TOTP authenticators or WebAuthn. Just like you can supplement traditional un/pw auth with extra factors...

2. The encryption argument is factual but completely irrelevant if the comparison is really between a magic link flow and a password reset flow, which pretty much every site has to deal with. Magic link flow would give 'at least' that amount of security without the problems of passwords being phished or brute forced. This is true whether are not the email is e2e encrypted or not. Recovery mechanisms for some reason tends to get overlooked... and email is by far the most common recovery mechanism present in the internet today.

[SAI_Peregrinus]

> UX (which is almost always in conflict with security)

UX is arguably a security concern. Poor UX impacts availability of the service, and availability is definitely a security concern. It can also tempt users to bypass security mechanisms if they have poor UX, often leading to worse security than before the mechanism was added!

[emptysongglass]

I had to double take here because that just isn't true. I can't even remember when the last time was that I sent an email over the wire without encryption and if you're using one of the big free providers (most are) you can be absolutely certain those emails are encrypted at rest.

[jjav]

SMTP connections tend to be opportunistically encrypted, but intercepting the connection via MITM is much easier than for e.g. a HTTPS connection.

So while it's true that most SMTP connections are encrypted, that doesn't mean anything unless the endpoints are enforcing trust on each other which mostly they're not.

[orev]

The more we assume that everyone is using the big email providers, the more it becomes a reality. And everyone agrees that a centralized Internet controlled by only a few companies is one of the worst case scenarios.

I have no certainty at all that any of those free providers use encryption at rest. How would they mine the messages for data to sell? And, cloud compute is expensive, and disk encryption takes more CPU cycles. Why would they spend that money? SMTP connections are more visible so it makes sense to use that from a marketing standpoint.

[prash_murali21]

Yeah the big providers will not be encrypting at rest for sure. Even if so, the encryption keys would lie with the provider and not the end user, which kind of defeats the purpose.

[jaywalk]

Most email these days is sent over encrypted connections and encrypted at rest.