Passwordless Login / Magic Links, share your findings.
What is your take on magic links? It'll be helpful if you guys have stats, i.e. number of users using passwordless, or if transitioning to passwordless benefited your sign up rates etc.
Cheers people!
I've collected about info about them, that I can share here.
Lots people will say they make things easier and better experience for users. There is some truth in that. However there are also lots of issues:
How will you handle multiple logins? Perhaps you are hoping that the email provider lets users add the email label (adding a + to any email), but how many users know about that sort of functionality?
How will you handle changing email addresses? This is one of those cases that will happen, but you hope you’ll never have to deal with it. When a user wants to change their email address, then they should be able to change it. So now you need another complex flow to make that happen. When a user is coupled to a userId generated separately by the user, that’s less of a problem.
You also open yourself up to common attack vectors that hackers use, and that is account impersonation. By having only a single string to represent each user, an attacker can continually guess email addresses until they have a hit. From there they can choose who they want to target. When you need both an email/username and a password, you can block requests where either is incorrect.
Another common problem is insecure email addresses. What happens when your email provider has a security breach. Account logins now are a huge issue, because each one of those is the login itself. Or what if a user is connected to a vulnerable hotspot and accesses their email in an unsecured way, a link as a login offers its own insecurities. This is the main reason why Oauth2.1 specifically forbids the use of tokens in query strings. Tokens in URLs are not safe.
Replay is a huge problem, what happens for a user with multiple tabs or closing and opening, or miss-clicking. The links will have to be one-time use only, but that means, if the user “logs out” and then returns they’ll need to go through the email flow again.
You can’t predict every user’s email provider, that means that the user will have to leave your app to log in. They’ll have to access their email provider and click there. If they have tons of emails or in the middle of doing something else it’s easy to have them get lost.
Attackers can use your service to send login emails to many different users. You start paying for the resources. If you are using SMS to send those links, then an attacker will cause you to fraudulently send messages to every number they put in.
The longer version article: Magic Links
While I also see passwordless logins via links as a mixed bag, I find this list of information rather misleading:
For mutliple logins - in what sense? The link replaces the password auth, just like in a normal password reset scenario.
Changing an email address is a simple flow. Request a change, send the email, the user clicks and it's changed.
The major difference between the two scenarios is only when the hacker wants to target a specific user. Otherwise there is virtually no difference. The only easy way to mitigate this is IP based rate limiting.
If your email account gets compromized it really does not matter whether magic links or username passwords are being used. The attacker can just send the common password reset email. From that point on there is virtually no difference anymore. And if people don't secure their primary email account (and even check their email in an unsecure way) it opens the door for attacks for any email related auth method.
The browser tabs do share cookies and local storage. That fact does not change with the auth method. If you decide to keep it only e.g. in session storage - that's a unrelated decision and problem. I am not sure how this relates to "replay".
Here I agree. With emails delays are a major problem. Nothing is more frustrating to a user than waiting for the login link that does not arrive in a timely manner. Given they are at the top of the inbox I don't see the problem of them "getting lost" though. They are not meant to be kept around.
People can create costs by asking for reset emails or DDos attacks. Since the attacker cannot send arbitrary messages there is nothing specific to passwordless auth.
For a startup, magic links are a lower-friction onboarding process. People hate setting a new password, most ordinary people don't even have a password manager. The only real downside, is that the magic links add some time & friction into the development / testing process as you must log out / log in to many accounts in sequence for testing scenarios.
Did you end up implementing a passwordless solution for your website? If yes, which auth provider did you use?
I have implemented passwordless authentication on AWS Cognito with lambda triggers for custom auth flow. Instead of magic links, I actually went with one-time codes. Asking users to follow some link in an email can be regarded as kinda insecure. And yes, it definitely improved signup rates.
i actually really like it for the project i'm building. i didn't think i would, but, now it makes a lot of sense.
I think there was already a thread on this topic last year if you do a search.
Things might've happened in the past year, no?
I've implemented magic links in Firebase (super simple) and AWS cognate (super convoluted) but they work really well. It's a bit if a hassle to test, but it's excellent user experience.
No idea how to add a 2fa to the flow if extra security is needed tho.
Will use magic link for the foreseeable future for all my projects. Either magic link or SMS code (almost the same thing). It's easier for people to use, they don't need to remember passwords, I don't need to implement "forgot passord"-flows and if I ever get hacked no passwords can be lost.