Answers · The network and the web
Why isn't a password plus a security question really two-factor authentication?
In shortA security question is another thing you know, so it is the same kind of proof as a password, not a second kind.
It is not two-factor because both the password and the security question are things you know. Two-factor authentication requires two different kinds of proof, such as something you know plus something you have, and two remembered answers are one kind of proof used twice.
A prompt is not a factor
A factor is a category of proof, not a request for a value. The common categories are knowledge, possession and a physical trait. A password is knowledge: the user recalls a secret and types it. A security question asks the user to recall another fact and type that, so it is knowledge too. The user is doing the same thing twice. That can increase the number of guesses an attacker must make, but it does not add a second kind of proof. The same attack works against both values: persuade the user to type them, or find them written down.
Take a twelve-character password from a 72-character alphabet. The number of possible passwords is , which is about : , and squaring that gives to two significant figures. Now suppose a security answer has 1,000 equally likely values. If the two are independent, the pair has possibilities. That is a real increase in guessing work, but it is still two knowledge values. If the answer can be found on a public profile, or reset by a help desk, the second value has one effective possibility for an attacker who looks, and the total falls back to . The second prompt has not become a second factor. It has become a second lookup.
Why the natural guess fails
The natural guess is that any second prompt is a second factor, and that more prompts mean more security. That fails because the category matters. Two passwords are two prompts and one factor. A password plus a security question is also one factor, and the second secret is often weaker than the first, because answers tend to be short, reused across services and drawn from facts that are not secret. A security question is frequently the reset channel rather than a lock, so the real proof may be access to a mailbox or a support desk. If an attacker can answer it by reading a public profile, the second prompt adds no secret at all.
| Sequence | What the second value is | Second factor? | Survives a convincing fake sign-in page? |
|---|---|---|---|
| password only | nothing | no | no |
| password plus security question | another remembered fact | no | no |
| password plus app code | a device the user possesses | yes | no |
| password plus hardware key | a private key held by a device | yes | yes |
Calling it two-step verification is accurate: the sign-in has two steps. Calling it two-factor authentication is not, because the steps are not different factors. This distinction is not pedantry. It tells you what the second prompt can resist. Two independent knowledge secrets can make guessing harder, since their spaces multiply. They do not make a convincing fake sign-in page harder, because the user can type both values into the same page in the same minute. The attacker relays the password, waits for the challenge, relays the answer, and receives a valid session. The second value was never bound to the service that asked for it.
Where the arithmetic changes but the category does not
Two knowledge secrets are not useless. If the answer is genuinely secret, has many possible values, is unique to this service and is never used as a reset route, it can add guessing resistance. But that is a narrow condition, and it still does not satisfy the definition of two-factor authentication. It is one factor with two values. The moment the answer is discoverable, guessable or resettable through another channel, the added resistance falls away. The account is then protected by a password plus whatever protects the reset channel, which may be a mailbox password or a support agent's judgement.
The methods that survive a convincing fake sign-in page work by binding the proof to the address of the service that asked for it. A hardware key or a passkey signs a challenge together with the address in the browser, using a private key that never leaves the device. A fake page can get a signature, but it is a signature over the fake page's address, so it fails when replayed to the real service. A security question has no such binding. It is a value a person can read and retype, and therefore a value somebody can ask them for.
Worth keeping
- Two prompts are not two factors if both ask for something you know.
- A security question is usually a weaker knowledge secret, not a possession proof, and it is often the account recovery route.
- A proof survives a convincing fake sign-in page only when it is bound to the address that asked for it, which a typed answer is not.
Where this goes next
This question is one step of Proving Who You Are, a course that works through its subject from the beginning. The page that teaches this part of it is The First Proof, and it reads the whole way through whether or not you have an account.
What an account changes is the practice: problems standing under every idea, marked with a reason rather than a tick, in a copy of the course that is yours.
Read that pageThe whole courseOther questions people ask about this
- Where should a session ID be stored so JavaScript can't read it?Store it in an HttpOnly cookie set by the server; that is the only browser storage JavaScript running on the page cannot read.
- Does signing out actually invalidate my token on the server?No. Signing out clears your browser's copy of the token, but the server keeps accepting that token until it expires.
- How can another site make a request as me if it can't read my cookies?A foreign page does not need to read your cookie. It makes your browser send a request to the site that owns the cookie, and the browser attaches the cookie automatically.
- What does it mean for an API method to be safe?A safe method is one that changes nothing on the server when it is called, so a caller may repeat it freely and a cache or a crawler may use it without anything being altered.
- Why does the TLS handshake take so many round trips before any data is sent?It is not one key exchange. The handshake agrees a secret, proves the server's identity and checks for tampering, and modern TLS fits those into one round trip; a fresh connection still needs three before the page starts.
- If a website has HTTPS, can someone on the same Wi-Fi read my password?No. HTTPS encrypts the form contents and cookies, so someone on the same Wi-Fi cannot read the password itself; they can still see the site, timing and packet sizes.