I arrived at the same conclusion after going through the steps and seeing that some corporate systems mark the login link as malicious, and there’s nothing I can do about it.
Only having magic links gets you a load of stuff for free,
Higher level of security than just user+pass (w/ forgot password)
Email verification
Lifecycle management - in a SAAS when a user no longer has a corporate email, they can defacto not log in, wheras with a user+pass you need to remember to remove their account manually on each SAAS or have integration with your AD (for example)
It’s not a higher level of security than password-based authentication. Why do you state that?
One-time email verification is not the same as security model as magic links. Magic links require instant access. Many security sensitive sites require a time delay and secondary notification for password reset links, which you can’t reasonably do for login links.
Lifecycle management is an interesting point. There are some underlying assumptions that might not hold though—losing an email doesn’t necessarily mean downstream accounts should be auto disabled too. Think Facebook and college emails, for example.
> It’s not a higher level of security than password-based authentication. Why do you state that?
Personally I'm no fan of magic links.
But the people who do like magic links would say the typical 'forgot password' flow is to send a password reset magic link by e-mail. That means you've got all the security weaknesses of a magic link, and the added weaknesses of password reuse and weak passwords.
Of course you can certainly design a system where this isn't the case. Banks that send your password reset code by physical mail. Shopping websites where resetting your password deletes your stored credit card details. Things like that.
That means you've got all the security weaknesses of a magic link, and the added weaknesses of password reuse and weak passwords.
Is objectively true. I don't really 'like' magic links but I think they're a very easy to implement and simple to use for infrequently accessed systems. Arguably easier than user/pass and certainly more secure.
Even with those assumptions (which I question), it is only a higher level of security if you assume that your users are reusing passwords, or using low entropy passwords. Neither would apply if they are using a password manager, which a growing majority of web users are.
> It’s not a higher level of security than password-based authentication. Why do you state that?
It could be, depending on how the user has secured their email inbox access. I know I pay a lot more attention to my inbox than some random account. I don't have data, but I think this is true of most people.
I'm also more likely to enable MFA on my email account than I will on every random account I sign up for. And as far as the account providers, I trust the big email providers to be more secure than some random website with an unknown level of security.
You raise some valid points about tying access to a third party and what makes sense. It's not a simple issue.
That's a fair point, but does time delay or secondary notification (the latter could be done for magic links of course) really outweigh the practical security risk of password reuse, attacks, leaks etc? I would argue not, unless the user had a insecure email account for some reason.
Re Lifecycle management; Unless you're also linking a phone number or some other "factor" I think in a traditional user+pass scenario you're also SOL if you lose access to your $Email1 before you update your account to use $Email2, as changing your email to $Email2 would usually send a email to $Email1 to confirm the action. In that case you're in the same position as magic link login + email change functionality. Similarly Lifecycle management only comes for free if you don't implement email change functionality.
Oh, we support passwords! (And passkeys, and social login, and OIDC, and SAML.)
Just want to make sure magic links work as well as they can.
Different folks have different requirements, and since we're a devtool, we try to meet folks where they are at.
We actually recently added a feature which lets you examine the results of a login, including how the user authenticated, and deny access if they didn't use an approved method.
One weird reason I've personal run into: when building on the edge, like with cloudflare workers, you can run into timeout issues because of how long password hashing takes.
That should be only if you're on the free plan that has a 10ms time limit. Paid plan gets 30 whole seconds which is plenty of time to hash lots of passwords.
In my experience 60% seems too high even for supposedly technical users (ref: I work in a dev firm), at least away from their jobs.
I definitely don't believe it for the wiser population (my gut, again based on people I know, says the number is more like 10%, maybe 15). Even the 36% figure on the report on security.org posted above seems dubious, I suspect they have some bias in their survey. Unless that is some people who use the iCloud password manager for some things and no password manager for everything else, so it isn't claiming 36% routinely use a password manager away from a few key accounts.
1. Sixty percent seems astronomically high, do you have a source?
and
2. Most "normal" non-tech-savvy people I know who do use a password manager (which I've typically installed for them), are revealed a while later to still use a variation of password reuse : either storing the same password per category of websites, or having a password template they use on all sites, e.g. "IdenticalSecretWord_SiteName"
I don't have the source, but don't think 1Password/LastPass/KeePass. Think the "would you like to save this login" built in to Chrome, Firefox, Edge, Windows, and iOS. These days, you have to opt-out of password management.
Right, use of a Password Manager does not imply they are using Password generation - it may just mean they click "Save this password" after logging in using a re-used password.
1) It means your users will complain that their account was hacked (even if it was their fault) and might cancel their service
2) hackers can exploit your system which hurts you (you are a VPS provider and someone mines crypto and you have to wave it for PR) or you run an email service and someone uses your app to spam (which hurts your email rep) etc.
I was gonna argue that you can fix this but I realized that you’re right. It’s a MITM attack where there’s really no way to stop it, same as passwords. It’s basically the same feature (sign in in a different browser) that also lets attackers in.
That said, here’s how I would mitigate it:
- Like usual, time based limits on the code
- Code is valid only for the initiating session, requiring the attacker to create a paper trail to phish
If you do have a magic link & want to use code as backup for authenticating a different device/browser, you could:
- Compare IP and/or session cookie between the initiating and confirming window. On match, offer login button. On mismatch, show the code and a warning stating how it’s different, eg ”You are signing in a different device or browser, initiated from $os $browser in $city, $country, $ip - $t minutes ago.”
It’s not perfect though and may still be prone to phishing.
I've had success with sending a code, and the link takes you to a page where the input is pre-filled with the code, and you just have to click "Login".
> I think that a link to a page where you enter a one time code gets around a lot of these issues.
I've done both in my SaaS product - link is GET with the OTP in the link, the target page checks if the link is in the URL, and if not, then the user can type it in.
Only for signup, though. For sign-in, the default is to always have the user type it in.
I think that a link to a page where you enter a one time code gets around a lot of these issues.