Beyond the password · 4 min read

Security questions: why NIST says no

Security questions ask for facts that are often public or easy to guess. Here is the evidence, the NIST rule, and what treating the answer as a password does.

“What was the name of your first pet?” “In what city were you born?” Security questions, also called secret questions or knowledge-based authentication (KBA), ask you to supply a fact about your life when you sign up, then ask for it again when you need to prove who you are, usually during password recovery.

The idea is appealing: you will not forget where you were born. The problem is that the properties that make an answer memorable also tend to make it guessable, findable, or both.

What NIST says

NIST SP 800-63B-4 lists this among its password requirements:

“Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.”

The same section also bans a close relative, the password hint: verifiers “SHALL NOT permit the subscriber to store a hint (e.g., a reminder of how the password was created) that is accessible to an unauthenticated claimant.”

KBA does not appear anywhere in NIST’s list of authenticator types. Its account recovery section recognizes four methods (saved recovery codes, issued recovery codes, recovery contacts, and repeated identity proofing), and security questions are not among them. OWASP’s cheat sheet on the topic opens with the same conclusion: “Security questions are no longer recognized as an acceptable authentication factor.”

Why they are weak

A good secret is unpredictable to everyone except you. Security-question answers fail that in several ways.

The answers come from small, skewed distributions. Many people share the same favorite foods, the same common pet names, and a few large cities account for many birthplaces. An attacker does not need to know you; guessing the most common answer first works surprisingly often.

Many answers are discoverable. Birthplaces, schools, family names and old addresses appear in public records, social media and past data breaches. Someone who knows you, or who spends an hour searching, may simply know the answer.

They do not change. A password can be replaced after a breach. Your mother’s maiden name cannot. Once an answer leaks from one site, it stays useful to an attacker at every other site that asks the same question.

People forget or fudge them. Answers typed years ago may not match what you type today (“NYC” or “New York City”?), and people who invent false answers to be safe often cannot remember which false answer they used.

What the data showed

The first large-scale study of real security-question data is a 2015 paper by Joseph Bonneau and colleagues at Google, covering “hundreds of millions of secret answers and millions of account recovery claims.” Among its reported findings:

• “using a single guess an attacker would have a 19.7% success rate at guessing English-speaking users’ answers for the question ‘Favorite food?’“
• “With 10 guesses an attacker would be able to guess 39% of Korean-speaking users’ answers to ‘City of birth?’“
• On memorability, “a significant fraction of users (e.g 40% of our English-speaking US users) were unable to recall their answers when needed.”
• Of users who admitted giving fake answers, 37% did so “in an attempt to make them ‘harder to guess’ although on aggregate this behavior had the opposite effect as people ‘harden’ their answers in a predictable way.”

The authors concluded that “it appears next to impossible to find secret questions that are both secure and memorable.”

Treating the answer as a random secret

If a site still requires security questions, nothing obliges the answer to be true. One approach is to treat each answer field as another password: generate a random value, store it in a password manager next to the login, and never try to remember it.

This changes the question from “what is your first pet’s name” into “what random string did you save,” which removes both the guessability and the public-record problem. It has costs: the answer is only available where your password manager is, and if a support agent reads the question aloud over the phone, a random string is awkward to say. A short random passphrase is easier to read out than random characters.

Worked example: a real answer versus a random one

Take the paper’s measured figure for “Favorite food?” among English-speaking users: a single guess succeeds 19.7% of the time, roughly 1 in 5.

Now answer the same question with 4 words drawn at random from the 7,776-word EFF list, for example oxidize-banjo-sleep-thicket (an illustration; do not reuse it). The number of equally likely answers is 7,776^4 = 3,656,158,440,062,976, about 3.7 × 10^15, which is 51.70 bits. The chance that a single guess is right is 1 in that number, about 2.7 × 10^-16.

Even three random words (38.77 bits, 7,776^3 = 470,184,984,576 possibilities) give a one-guess chance of about 1 in 470 billion. Because recovery prompts are an online attack and should be rate-limited, that is far beyond what a guesser can reach. The passphrase generator produces exactly this kind of answer; how passphrases work explains the arithmetic.

Note: A random answer fixes guessing. It does not make security questions a second factor. It is still something you know, typed into a form, and it can be phished like a password.

What replaces them

Sites that follow current guidance recover accounts with one-time codes: saved recovery codes you keep offline, or codes sent to a phone number or email address you registered, along with notifications so you know when recovery is used. A second registered authenticator, such as a passkey on another device, avoids recovery altogether. See recovery codes and backups and two-factor authentication explained.

For the general reason why chosen secrets are weaker than generated ones, see random versus human-chosen passwords.

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