Beyond the password · 5 min read

Two-factor authentication explained

The factors, the common second-factor methods side by side, and why a code you type can be relayed by a phishing page while a security key cannot.

Two-factor authentication (2FA), or multi-factor authentication (MFA) more generally, means a login needs two different kinds of evidence instead of one. The point is independence: an attacker who has stolen one kind should still be stuck without the other.

The three factors

Authentication standards sort evidence into three kinds. NIST SP 800-63B-4 uses the same phrases:

• Something you know: a password, passphrase or PIN.
• Something you have: a phone, a hardware key, a list of codes, a device holding a cryptographic key.
• Something you are: a fingerprint or face. NIST says biometrics “SHALL only be used as part of multi-factor authentication with a physical authenticator”, typically to unlock a phone or key that holds the real secret.

Two passwords are not two factors. A password plus a security question is not either: both are things you know, and both can be phished or guessed the same way. Two factors means two categories.

The common second factors

Text messages and calls

A code sent by text or voice is an out-of-band method in NIST’s terms: the secret travels over a second channel, the phone network. It is easy to set up and works on almost any phone. Its weaknesses are the phone network itself and the phone number. If someone persuades a carrier to move your number to their SIM, the codes go to them. NIST lists the telephone network as its one current “restricted authenticator” and says verifiers “SHOULD consider risk indicators (e.g., device swap, SIM change, number porting, other abnormal behavior)” before relying on it.

Push prompts

A push notification asks you to approve a login on your phone. The simplest version, a plain “Approve / Deny” button, is no longer acceptable to NIST because of “authentication fatigue” attacks, “in which an attacker generates many out-of-band authentication requests to the subscriber, who might approve one to eliminate the annoyance.” NIST now requires that a secret actually be transferred between the login screen and the phone, for example by typing a number shown on one into the other.

Authenticator apps

An authenticator app holds a secret it shares with the service and turns the current time into a short code every 30 seconds. Nothing is sent to the phone, so the phone network is out of the picture. The details are in how authenticator apps work.

Security keys and passkeys

A security key, or a passkey stored on a phone or computer, holds a private key. At login, the service sends a random challenge and the device signs it. The browser includes the site’s domain in what gets signed, and the device will only use a key on the domain it was created for. There is no code for a person to read or type. See passkeys explained.

Why typed codes are not phishing-resistant

NIST defines phishing resistance as “the ability of the authentication protocol to prevent the disclosure of authentication secrets and valid authenticator outputs to an impostor verifier … without relying on the vigilance of the claimant.” It then rules out every method where a person copies a code:

“Authenticators that involve the manual entry of an authenticator output (e.g., out-of-band and OTP authenticators) SHALL NOT be considered phishing-resistant because the manual entry does not bind the authenticator output to the specific session being authenticated. For example, an impostor verifier could relay an authenticator output to the verifier and successfully authenticate.”

In practice, a phishing page asks for your password, passes it to the real site in real time, then asks for your code and passes that along too. The code is valid, because it is the real code. It just went to the wrong place. A security key does not have this weakness: the signature it produces names the domain the browser was actually on, and a signature made for a look-alike domain is useless on the real one.

That does not make typed codes pointless. They stop the much more common attack of replaying a password leaked from somewhere else (see credential stuffing and password reuse), because the attacker does not have your phone or your secret. They just do not stop a live phishing relay.

Worked example: guessing a 6-digit code

A 6-digit code has 10^6 = 1,000,000 possible values. Suppose only one code is valid at a time and the service follows NIST’s rate-limiting ceiling of 100 consecutive failed attempts before it disables the authenticator.

• Chance of a correct blind guess on one try: 1 in 1,000,000.
• Chance within 100 tries: 100 / 1,000,000 = 1 in 10,000 (0.01%).

If the service accepts the codes from two adjacent 30-second windows to allow for clock drift, two values are valid at once and the chance roughly doubles, to about 0.02% over 100 tries. NIST notes that the limit of 100 “was chosen to balance the likelihood of a correct guess (e.g., 100 attempts against a six-digit decimal OTP authenticator output) versus the potential need for account recovery.”

Short codes are only safe because of that rate limit. The same 6 digits used as an offline secret would fall instantly; the PIN guide explains why.

Factors and fallbacks

A second factor raises the bar for the main login. The account is only as strong as its weakest way in, though, and that is often recovery. If a lost phone can be bypassed with an email link or a security question, an attacker can take that route instead. NIST requires services that rely on phone-network codes to make other authenticator types available, and says an account recovery event “always causes one or more notifications to be sent to the subscriber.” Recovery codes and backups covers the mechanisms, and security questions explains why they are not a factor at all.

General explanation, not advice for a particular situation. Updated 2026-10-31.