I am building an application that a user can receive an access to by an internal worker. This works using a magic link, where the user will receive a one time link to authenticate in the app. Now I want the application to be secured with 2FA, so I decided that the link should also include a totp secret code in the form of a QR code that can be scanned. This will prompt an authenticator app (eg. Google Authenticator) to store the secret and generate TOTP codes. The web app (that is isntalled via angular PWA) will be mainly used on tablets and phones.

Now, the idea is that if a user wants to do some important operation in the app, or has somehow lost their session cookie and wants to re-authenticate(something like "forgot your password?" functionality), instead of using the magic links, they can simply use their totp code from the authenticator app to authenticate themselves. Because the user needs the phone (something they have) and the means to access the phone (fingerprint, face id, code), can this be considered inherently 2FA?

I have a few concerns about this. Let's say the user's unlocked device gets stolen. Then the attacker has gained the access to the app, because the application and the authenticator app is on the same device, and authenticators don't ask for the phone passcode when opening the app. But let's say an attacker somehow gets access to the user's session cookie, then they should not be able to access the app if it asks for the totp code, because the attacked doesn't have the device that the totp code in generated on.

So my question is, does this solution with totp code actually offer a true 2FA protection? Or would a simple passwordless magic link implementation offer the same level of protection. I would greatly appreciate any insights on best practices or suggestions for this authentication setup.

  • We have some questions here about that already
    – schroeder
    Commented Nov 29, 2023 at 14:13

1 Answer 1


If you're using a magic link via email, then you can actually probably just continue using that in place of the MFA verification. You're already using an external service to authenticate, so why introduce passwords into the mix*?

The main concern I have at that point is just that the MFA QR code should not be available with every link (and, for clarity, I am assuming that the QR code is in the web page that the link leads to, not that the MFA secret is within the link itself). You should have separate link flows for registration (with QR code) and login (without) if you're going to use that approach. Of course, the issue of phone theft is actually a bit more prevalent there, as I'll explain later.

To answer your primary question, however, this is actually a valid concern behind mobile 2FA as it currently stands. The idea behind MFA, however, is not to achieve absolute security, but to minimize the impact of one factor's compromise. If you solely have a password but no phone or MFA secret to regenerate OTPs, then the attacker might be able to spam push notification-style apps a la the uber attack, but if they're dealing with a 6-digit code, they have to get a little more creative, and also make sure their victim is susceptible to phishing. Similarly, if you only have the phone compromised but are unable to retrieve the password, an attacker is forced to brute force credentials somehow.

That said, if the attacker steals a phone and the user has their email open that can receive those links with no further protections (the latter of which, granted, is common)? That's when you start running into problems. However, at that point, that sort of compromise is much less likely to happen, and there are very simple ways around it. For instance, a lot of email and social apps have the ability to instantly revoke other sessions, so attackers get logged out before they can exploit the password reset and/or magic link.

To address session token stealing, yeah, it is a thing, but it doesn't prevent MFA from adding that additional layer of security. MFA is primarily an authentication solution, not a session security solution. For session security, definitely look into locking down your cookies.

Hope this helps!

*As a note, if you can swing it, avoiding password authentication entirely is rather handy, since password security is a difficult and troublesome task. The usability of passwords is also rather poor.

  • Thanks! I am avoiding managing passwords entirely and still wanted MFA, so thats why I thought using TOTP from an authenticator app to replace passwords entirely. The MFA totp secret QR code will only be shown when the user first registers to the app with the magic link. For every following authentication the qr code and the magic link won't be used. Instead, after the first registration, the user will receive a session cookie, so they can either access the app without any verification using the session cookie, or will have to input TOTP code. I am not sure if totp adds additional security Commented Nov 30, 2023 at 14:31
  • Oh, I see what you're getting at. I think if you're exclusively using a TOTP for authentication (basically FIDO2, single factor), then it kinda defeats the benefits of that MFA. I'd recommend seeing if you can introduce either offloaded access or a second factor somehow. Commented Dec 3, 2023 at 0:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .