They are generally secure. Password reset typically uses email as the sole factor. So it's no less secure than that, which is generally considered necessary and secure.
In an enterprise setting, access to email can be made to require MFA. The email loop itself, to major providers, is generally secure.
You mean the SaaS can add their own MFA? No, they can't. If you do that, you have no reasonable way to recover accounts. You get down the rabbit hole of extremely difficult UX, vs easily bypassed MFA. Once you add MFA, you cannot allow account recovery without it. This is the still-hard part of MFA.
By the time you go through all the rigamarole, you're just better off forcing your customer to manage their own MFA.
Hmm, it "feels" insecure to me, but thinking on it, I'm not sure why, especially since most email is web-based these days, and pretty much all the rest goes over encrypted IMAP/POP/Exchange.
That is also true for every password-based account without 2FA by means of password reset.
Plus, having someone access your email account means you're pwned anyway - they can see your sensitive documents that were received / sent as attachments, they can read recent conversations and phish information, maybe even ask for a downpayment, etc.
So the basic rule should be: don't lose access to your email.
That doesn't mean that email-based login is good, just that IMO this point is kind of moot.
Yes, you're very pwned if somebody has access to your email account. But less pwned than if they can also access all your other accounts directly at the same time =)
Of course, combining email-based login with another factor makes it more secure again, I was just talking about one factor.
There is none. I implemented passwordless on an app a few months back and a few weeks ago it passed a CHECK pentest with no flaws detected or expected in auth. It’s basically asking the user to reset their password every time, which is much safer than having them using “123456” as their password.
I use Sendgrid to send the email and have had no issues with the service so far.
It doesn't really matter if they're secure or not (but they're not).
They're also infuriating, massively increase friction (especially for users of a web-based email system that they may not keep open) by forcing a user out of their workflow, as well as infantilizing users by deciding that for them that they just don't know any better and can't be trusted to use a secure password/turn on 2FA.
If security were actually the concern, push users to turn on 2FA with a non-removable banner until they do it, and on that page prominently educate them on the best ways to smooth THAT out via the many 2FA tools that help manage logins, until we have a good 2FA standard or good, wide implementation of webauthn or similar.
Perhaps we tolerate emailed password reset links currently until there is a better method. There's an additional advantage to them in that "if they work, you know they haven't been lifted/used, and your password still works/has been set". On the other hand, given that anyone can go ask for a login link to be sent as many times as they want, if you come home to a mailbox full of login link requests you haven't requested and which have already expired you really have no hope of knowing whether or not your account has been compromised/used for some nefarious purpose already. Even having immutable-to-the-end-user session info saved and displayed probably isn't enough to remedy this.
"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.
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 withoutencryption, and then sits on some cloud server somewhere withoutencryption. Maybe that’s fine for managing a newsletter subscription, but it’s complicated inappropriate for anyone wanting real security.
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.
> 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!
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.
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.
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.
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.
Login via URL ("magic link") is about as insecure as it gets. You can do worse, but have to try.
Password reuse is bad because it allows compromising one site if another one is compromised. By sending someone a URL to login via email, now you've effectively forced password reuse of their email password as the site password (because obviously, if someone gets access to email they also get access to the emailed links).
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.
In an enterprise setting, access to email can be made to require MFA. The email loop itself, to major providers, is generally secure.