As far as I've read, passwordless login like Slack uses (user inputs their email and then clicks on the login link in their email) is becoming more common and is just as secure as logins that require a password.

I am a designer at a financial technology company whose users skew older. Perhaps this type of login will feel unfamiliar to them (and thus untrustworthy) or too easy, like some secure step is missing. Has any research been done on the perceived security of this flow?

  • offer both authentications method and make the "magic link" optinal (this article explains further auth0.com/blog/… )
    – BlueWizard
    Jan 8, 2019 at 13:08
  • It’s sad but the answers say a lot about UX StackExchange: A lot of opinions, some engineering judgment on the factual security, but actually looking into users’ experiences including their feelings and perceptions is very rare. Sorry I can’t help either, but I’d be very interested as well.
    – Andy
    Feb 6, 2023 at 9:46

5 Answers 5


I work on security products for many years. The current product I'm working on, (mobile app to secure employees' data), uses exactly that.

In the last ~5 years that the product exists, we never heard a claim from end-users (banks, healthcare, insurance, medical) or admins, that the authentication method is not safe enough. Not sure what it says about your specific users and product though - decide yourself.

What you should not decide by yourself and be responsible for, is what authentication method to use. There are different considerations to that. Always consult a security expert.


Similar to the OP, I work in FinTech and the hip & trendy designers want "Magic Links" for login because they see them done by less security conscious (but "successful") companies like Slack.

But I urge you to think about what you are telling the users of your app: It's not only "OK" to click links in email, it's the only way to authenticate!

Encouraging people to click links in email is a mega security anti-pattern that will make them vulnerable to Phishing. When they receive a doggy email from a scammer that looks like it came from their bank, and you have trained them to click on "Magic Links", they will click it and bad things happen. 😢

A far better way of doing this that also feels more secure to both people using your app and the security auditors is a 3 step:

  1. Register or sign-in with email address.
  2. Send them an one-time (single-use) code to their email.
  3. Require them to manually input (or copy paste) that code in the next screen to verify. This creates their session.

This has the advantage of verifying their email and not encouraging them to click arbitrary links.


Passwordless authentication is quite likely more secure than a standard password; people have little patience with traditional username/pw security, and it's almost a 2-factor authentication process. The easier for the end user your security protocols are, the more secure the authentication process is (password123 anyone?).

So...I don't know of extant research in perception, specifically, but it would be a fantastic usability test to run with your users/target audiences. Since you're working for a financial institution they have the resources to run a test on this. Or to let you do the same!

I'd love to hear if y'all do run this kind of test - it'd be great to share with the community. And quite possibly an industry-first customer experience upgrade. There's a lot of benefit to this approach IMO.

  • Yeah that would be great. A classical usability would not cover the question of perceived security, though. You’d need to add a survey-based method. Something along the lines “Would you trust this app to securely manage your financials?”
    – Andy
    Feb 6, 2023 at 9:40

Depends to the sign-in flow design, I would argue magic-link style passwordless sign-in would be more secure than traditional username/password sign-in.

In magic-link style of authentication approach, to compromise one's login access to your web application, adversary will need to compromise victim's email account access to the extent that he can read the email from victim's at the time he going to sign-in your web application. It causes more trails and mail alert, which is harder to cover up, and victim will notices about that easier, hence more difficult to success.

However, in username/password authentication approach, adversary is possible to compromise the access totally unnoticed by user, since the adversary may bought the database dump from dark web containing the password and crack it offline. Hence it is possible that adversary can use the cracked password the login the web application without any notice to the user, and additional countermeasures will need to implement to improve the situation (e.g. a follow up email to user that he's logged in the web application).

  • Hi Angus, what about the perceived security of this feature? The OP was concerned that older users might regard is as untrustworthy.
    – Nash
    Jul 24, 2020 at 7:09
  • I have yet to identify a specific study mentioning about perceived security of magic link. But from a study about perceived security, a quote's here: The evidence shows that perceived security is influenced by the perception of interface design features, perceived control, and conscientiousness and that there are interrelationships among these three dimensions. I think the completeness of UX is of utmost importance in this aspect.
    – Angus
    Oct 18, 2020 at 15:11

It's fine if you Do it Right. But that doesn't mean clicking on magic links.

Google does a nice job of it. They pop a prompt up on the user's phone and say "Are you trying to log in to xyz?"

If the user says "yes", the login on the web browser goes though. If not, it doesn't.

This bases security on the fact that the user possesses their phone and has logged in to the phone (a pattern or PW or PIN is required).

All the crypto stuff is handled in a security chip (at least with Pixel phones)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.