prash_murali21

"you really have no hope of knowing whether or not your account has been compromised/used for some nefarious purpose already" this is an interesting point.

Although the same would be true if your password to site in question itself got compromised, which is probably more likely. You wouldn't have any way of knowing if your account has been used for some nefarious purpose already too.

Agree with this. I don't see why you cannot add 2FA to email based login flows.

I believe we have to view from the context of how most sites do auth, which is email + password with an 'email recovery' for the password. This is effectively the same thing with worse UX and an added attack vector of the password for the site being compromised.

The point on password reuse I agree with, but flakiness here is that there do unfortunately exist dodgy sites without TSL and without password hashing and salting in place. This overall increases the probability of a breach and since re-use is common the supposedly secure sites become vulnerable too. At least with email, most major email providers have some level of securing the email (example 2FA involved when attempting to login from a different device).

If the comparison is between email magic links and a site that offers email / password with no recovery at all or "secret questions" as the means of password recovery, which I haven't seen in years, that's a whole other debate all together.

Yes exactly. If the email itself doesn't require MFA, you can always add MFA on top of email magic links.

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.

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.