Guides / Concepts explained

What Is Two-Factor Authentication? A Plain-English Guide

Two-factor authentication asks for a second proof beyond a password. How codes, apps, passkeys and SMS compare, and what to ask an AI builder to add it.

Mythex Team · 2026-09-29 · 7 min read

Two-factor authentication (2FA) is a login that asks for two different kinds of proof that you are who you say you are — typically something you know, like a password, plus something you have, like your phone or a security key. If a criminal steals or guesses your password, they still can't get in without the second factor. It is one of the simplest ways to protect accounts that matter.

Why it matters when you build with AI

When you ask an AI builder for "login", you usually get email and password. That's a fine start, but passwords get reused, phished and leaked. If your app holds anything valuable — customer records, invoices, admin controls, payment settings — a single stolen password could expose all of it.

2FA also affects decisions you might not think about at first:

• Who must use it. Optional for everyone, required for admins, or required for all?
• Which methods you support. Codes from an app, text messages, passkeys, security keys.
• What happens when someone is locked out. Lost phones are the most common support request for any app with 2FA.
• Where it's enforced. The check has to happen on the server. A 2FA screen that only hides the page in the browser can be skipped.

You don't have to build the cryptography yourself — well-tested libraries and auth providers handle that. But you do need to know what to ask for.

An everyday analogy

Think of a bank safe-deposit box. To open it, you need your ID (something the bank checks you are or know) and the physical key (something you have). A thief who copies your signature still doesn't have the key. A thief who pickpockets the key still can't pass the ID check.

2FA works the same way. The password is the signature; the phone or security key is the physical key. Each one alone is not enough.

The three kinds of factors

Security standards, such as the US National Institute of Standards and Technology's digital identity guidelines, group factors into three kinds:

The key word is different. A password plus a security question is two things you know, so it isn't true two-factor authentication. If one leak can reveal both, it only counts as one.

The common 2FA methods compared

NIST's guidance treats methods where you type a code (SMS, email, authenticator apps) as not phishing-resistant, and marks sending codes over the phone network as "restricted". Passkeys and hardware security keys, based on the WebAuthn/FIDO2 standards, are the ones it counts as phishing-resistant.

A practical takeaway: an authenticator app is a strong, easy default for most apps, and passkeys are worth offering if your users are comfortable with them.

A worked example: 2FA for a client portal

Say you've built a portal where a small accounting firm shares tax documents with clients. Here's how a sensible 2FA setup works, step by step.

Turning it on (enrolment). Priya, a client, opens Settings and clicks "Turn on two-factor authentication." The app generates a secret and shows it as a QR code. She scans it with her authenticator app, which starts showing six-digit codes. She types the current code back into the portal to prove the setup worked. The app shows ten recovery codes and asks her to save them somewhere safe.

Logging in afterwards.

1. Priya enters her email and password. The server checks them.
2. Instead of logging her straight in, the server marks the session as "password OK, second factor pending" and shows the code screen.
3. She types the code from her app. The server checks it against her stored secret, allowing for a little clock drift.
4. Only now does the server create a full session and let her see documents.

What an attacker sees. If Priya's password leaked from another site, the attacker gets stuck at step 3. Every failed code attempt is counted, and after several wrong tries the account is temporarily locked and Priya gets an email.

Losing her phone. Priya uses one of her recovery codes to log in, turns 2FA off and on again with her new phone, and gets fresh recovery codes. The used code can never be used again.

For staff. The firm's accountants can see every client's files, so the portal requires 2FA for staff accounts; they can't reach the dashboard until they've enrolled.

Common terms explained

Common mistakes and misconceptions

• "2FA makes an account unhackable." It makes it much harder. Phishing sites can still capture typed codes in real time, which is why passkeys exist.
• Checking the code only in the browser. If the server issues a full session after the password, the code screen is decoration. The server must refuse access until the second factor passes.
• No limit on code guesses. A six-digit code has a million possibilities. Without rate limiting and lockouts, an attacker can simply keep guessing.
• Forgetting recovery. No recovery codes means every lost phone becomes a support ticket, or a locked-out customer.
• Storing the TOTP secret carelessly. The shared secret should be encrypted in the database, and never shown again after setup.
• Letting users turn 2FA off without re-checking. Disabling 2FA or changing the email should require the password and a current code.
• A password plus a security question counts as 2FA. It doesn't — both are things you know.

What to ask your AI builder for

• "Add optional two-factor authentication using an authenticator app (TOTP), with a QR code for setup and a confirmation code before it's switched on."
• "Show ten single-use recovery codes when 2FA is enabled. Store them hashed, like passwords."
• "Enforce 2FA on the server: no full session until the second factor passes."
• "Limit code attempts and lock the login for 15 minutes after repeated failures. Email the user when that happens."
• "Require 2FA for admin accounts."
• "Ask for the password and a current code before disabling 2FA or changing the account email."
• "Use a well-known library or our auth provider's built-in 2FA — don't write the crypto yourself."
• "Explain which method you used and where the secrets are stored."

If you use a hosted auth provider, check whether it already offers 2FA or passkeys; turning on a built-in feature is usually safer than custom code. The step-by-step version is in how to add two-factor authentication, and what authentication is covers the login basics underneath it.

Two-factor authentication in Mythex

Mythex doesn't include a built-in login system for your app's users, so 2FA is part of whatever auth approach you choose — your own email-and-password login backed by the project's database, or a hosted provider that offers 2FA. You ask the agent to add it in chat, and any provider keys go in project secrets rather than in the chat itself. The docs recipe on adding login to your app has a starter prompt to adapt, and security for apps you build covers the habits around keys. Before launch, run through the security checklist for AI-built apps.