Don't delude yourself with fake 2FA

Authentication is the act of verifying that a person is who they claim to be. On the web, this was traditionally accomplished using passwords. Ideally, Alice is the only one who knows her password, so she can prove it's her by providing it. Passwords have the inherent vulnerability that they can be stolen. And once the password is compromised, you can no longer distinguish the real Alice from an impostor.

Two-Factor Authentication (2FA) mitigates this risk by utilising two distinct factors of authentication. Becoming an indistinguishable impostor then requires two separate, different attacks.

The most prevalent 2FA setup is a traditional password combined with a short-lived code sent to the user's phone. This setup is so common that ‒ although this is far from the only possible setup ‒ this is often synonymous with “2FA”.

I don't mind bending the definition of the term with a little totum pro parte; but some bend it even further. Some refer to that short-lived code sent to the user's phone as “2FA”. They'll tell you "our service uses 2FA", despite this short-lived phone code being their only authentication factor. If that's the only authentication factor, an impostor has to pull off one single attack (such as SIM swapping) to become successful.

For some projects, this might be an acceptable level of risk. 1FA vs 2FA is a trade-off between convenience and security, and the weightage given to each depends on context. Moreover, a short-lived phone code is arguably safer than a traditional password, even if it is less safe than the combination of the two. But let's not delude ourselves into believing we're using 2FA when, in reality, we are not.