Do not add security questions to a new app: they fail as a recovery factor, since the answers are guessable, public or forgotten, and NIST’s current guidance tells services not to prompt for them when users choose passwords. For examples of security questions, the 20 standard ones are below in 5 types, each with how its answer gets found.
Examples of security questions: the standard list, by type
Examples of security questions fall into 5 types: family and origin, such as mother’s maiden name and city of birth; firsts, such as first pet or first school; favorites, such as food or team; places and dates, such as the street you grew up on; and documents and numbers. Every type has answers that are public, guessable or forgotten.
This list of security questions is here so you can recognize them on forms you fill in and in code you inherit; no question on it is endorsed. Where it fits in the wider set of login controls is covered in the authentication checklist.
Okta’s guide and OWASP’s cheat sheet use several of the 20 as their own security questions examples: city of birth, oldest sibling’s middle name, favorite teacher, favorite movie, first car and first school. The rest are the same kind of question, grouped here by what the answer is about. The third and fourth columns are my reading, written in general terms: where an answer tends to be exposed, and whether the true answer drifts or slips from memory.
| Question | Type | Where the answer can be found | Drifts or forgotten |
|---|---|---|---|
| What is your mother’s maiden name? | Family and origin | Public records, family members’ social profiles | Stable; spelling varies |
| In what city were you born? | Family and origin | Public records, social profiles, a short list of common answers | Stable; town or nearest city |
| What is your father’s middle name? | Family and origin | Anyone who knows the family, a short list of common names | Stable |
| What is your oldest sibling’s middle name? | Family and origin | Anyone who knows the family, social profiles | Stable; not everyone has a sibling |
| What was your first pet’s name? | Firsts | Social profiles and photo captions, a short list of common pet names | Which pet counted as first |
| What was the name of the first school you attended? | Firsts | Social profiles, alumni pages | Full name or short name |
| What was your first car? | Firsts | Old social posts, a short list of common makes | Make, model, or both |
| Who was your first employer? | Firsts | Professional profiles | First real job or first summer job |
| What is your favorite food? | Favorites | A guess from a short list of common answers | Drifts |
| What is your favorite movie? | Favorites | Social profiles, anyone who knows the person | Drifts |
| Who was your favorite teacher? | Favorites | Classmates, school yearbooks | Drifts; surname spelling |
| What is your favorite sports team? | Favorites | Social profiles, a guess from where the person lives | Drifts; not everyone follows a team |
| What street did you grow up on? | Places and dates | Public records, anyone who knows the person | Stable; street or full address |
| Where did you meet your partner? | Places and dates | Social profiles, friends | Wording varies; not everyone has a partner |
| In what city was your first job? | Places and dates | Professional profiles | Which job counted as first |
| What is your wedding anniversary? | Places and dates | Public records, social posts | Date format; not everyone is married |
| What are the last digits of your ID or account number? | Documents and numbers | A data breach, a lost or photographed document | Forgotten; changes when reissued |
| What was your childhood phone number? | Documents and numbers | Relatives, old directories | Forgotten |
| What is your library card number? | Documents and numbers | Rarely public | Forgotten |
| What is your license plate number? | Documents and numbers | Anyone who sees the car, photos of it | Changes with the car |
If you need a sample of security questions for a settings page you are building, read the next two sections before you ship any of them. If you searched for the 10 or 20 common security questions and answers, all 20 questions are in the table; how to answer them effectively when a site forces one on you is in the FAQ at the end, because this page publishes no answers to use.
What is a security question, and what was it for?
A security question is a knowledge-based identity check: a question set at signup whose answer is requested later, usually to recover a password. It belongs to the same family as the password, something you know, so it backs up one secret with a weaker one that friends, public records and old breaches can reveal.
OWASP lists the common cases where it would be used: logging in, resetting a forgotten password and resetting a lost MFA token. OWASP’s cheat sheet puts the design flaw in one line: “The combination of a password and security questions does not constitute MFA, as both factors as the same (i.e. something you know).” In my reading, that is the whole problem: the fallback for a forgotten secret is another secret, and usually an easier one.
Two other things share the name and are not this. One is the set of questions a customer sends a vendor during procurement, covered in its own section below. The other is interview questions for security staff, which this page does not cover.
How to fill it in: what would make a good security question, and why almost none qualify
A good security question would have to pass 5 tests at once: memorable, consistent over time, applicable to every user, confidential and specific. Family questions fail confidentiality, favorites fail consistency, firsts fail memory years later. An answer that passes all five is a random string in a password manager, which is a recovery code by another name.
The five tests are OWASP’s, in its order, from OWASP’s cheat sheet on security questions. The third column applies them to the 20 questions above; that part is my reading.
| Criterion | What it means (OWASP’s words) | Which of the 20 fail it, and why |
|---|---|---|
| Memorable | ”The user must be able to recall the answer to the question, potentially years after creating their account.” | Firsts and numbers: first school, first employer, childhood phone number and library card slip away over the years |
| Consistent | ”The answer to the question must not change over time.” | All four favorites, and the license plate |
| Applicable | ”The user must be able to answer the question.” | Pet, sibling, partner, anniversary and sports team: not everyone has one |
| Confidential | ”The answer to the question must be hard for an attacker to obtain.” | Family and origin, places and dates: public records and social profiles hold them |
| Specific | ”The answer should be clear to the user.” | First car (make or model), first school (full or short name), anniversary (date format), maiden name (spelling) |
The measured version comes from the published study of real recovery answers, by Joseph Bonneau, Elie Bursztein, Ilan Caron, Rob Jackson and Mike Williamson, presented at WWW 2015 and drawn from millions of account recovery attempts. On guessing, the paper finds that with a single guess an attacker would have a 19.7% success rate against English-speaking users’ answers to “Favorite food?”, and that with 10 guesses an attacker would be able to guess 39% of Korean-speaking users’ answers to “City of birth?”.
Recall was just as bad. In the paper, 40 percent of English-speaking US users could not recall their answers when needed, while SMS reset codes succeeded over 80 percent of the time. Memory also fades: for “Favorite food?” the recall rate was 74 percent after a month, 53 percent after 3 months and 47 percent after a year. “Library card number?” had a 22 percent recall.
False answers did not rescue it.
In the study’s survey, 37 percent of the users who admitted giving fake answers said they did so to make them harder to guess, and the paper found that “on aggregate this behavior had the opposite effect as people ‘harden’ their answers in a predictable way.” Its conclusion: “it appears next to impossible to find secret questions that are both secure and memorable.”
My verdict on the best security questions examples other pages list: a question that passes all five tests is a second password. The strongest setup I know is a random answer kept in a password manager, and at that point the question adds nothing a recovery code would not do better.
That is also why I give no good security questions examples here to copy. OWASP’s cheat sheet does give guidance on choosing strong questions, but only for legacy use: “While there are no acceptable uses of security questions in secure software, this cheat sheet provides guidance on how to choose strong security questions for legacy purposes.”
User-written questions are worse, not better. OWASP warns that “users might even set a recovery question to a reminder of what their password is” and concludes “it is generally best not to allow users to write their own questions.”
A worked example: security question and answer pairs for one account, and what an attacker needs
A security question and answer pair is a credential, and it leaks by 5 routes: guessing from common answers, public and social information, phishing, reuse after another site’s breach, and a persuaded support agent. An app that accepts two correct answers without control of the mailbox can be taken over without touching the password.
Take a fictional user with three typical pairs: first pet, city of birth and favorite team. Take an app that lets anyone who answers two of the three set a new password. The case below is a scenario, built to show the mechanism.
| Question and answer pair | What exposes it | The control that stops or catches it |
|---|---|---|
| First pet → the pet’s name | A public profile with pet photos captioned by name | Recovery through the mailbox: the reset goes to the owner’s inbox, whatever the answers |
| City of birth → the city | An old breach of another site that stored the answers in plain text | A notice to the owner on every reset, plus a record of who reset what |
| Favorite team → the team | A short list of common answers, tried one after another | A rate limit on the recovery endpoint, so a run of wrong tries stops early |
In the scenario, one answer sits on a public profile, one comes out of an old breach and one falls to a short list of common guesses.
No email access is needed, no alert fires, and the real user finds out at the next login, when the password no longer works.
The five routes, one line each, as I read them:
- Guessing: many people share the same few answers.
- Public and social information: birthplaces, pets and schools are posted freely.
- Phishing: a fake form or quiz can ask the same questions, and answers feel less secret than passwords.
- Reuse: the same questions and answers across many sites, so one site’s breach exposes the rest.
- Support: an agent can be talked into a reset by someone who knows the answers.
OWASP names the reuse risk directly: “there is a risk that users will re-use recovery questions between different sites, which could expose the users if the other site is compromised.”
Three controls cover these routes: recovery that needs control of the mailbox stops this reset outright, a limit on repeated tries at the recovery endpoint slows the guessing (brute force login protection), and a record of who reset what with an alert to the account owner catches a reset that gets through (see audit logging best practices).
The point for an app owner: security questions and answers are credentials, and OWASP says to treat them “in the same way as passwords”. In my reading, an app that stores them keeps a second password table, one that users fill with answers they reuse everywhere.
Security questions and answers in a vendor questionnaire: a different thing
Security questions and answers also means something unrelated on this results page: the form a customer’s procurement team sends a vendor. That form asks about encryption, access control, backups and incident response, and it has its own standard templates and example answers, which belong to a different page.
If a questionnaire is what landed in your inbox, the standard forms, sample answers and the evidence to attach are a separate subject: security questionnaire examples. The two meanings do meet once: a questionnaire may ask how your app handles account recovery, and in my reading “security questions” is the wrong answer to give there.
What to use instead: the best security questions for password reset are none, and this ladder
Password reset is safest with no security questions at all. NIST’s current guidance tells services not to prompt for them when users choose passwords, and a small app uses a 5-rung ladder instead: an emailed single-use reset link, a second factor or passkey, one-time recovery codes, a waiting period with notices for high-value changes, and logged support-assisted recovery.
The rule is in NIST SP 800-63B, Revision 4, section 3.1.1.2, in the list of rules for password verifiers : “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 document lists four general classes of account recovery (saved recovery codes, issued recovery codes, recovery contacts and repeated identity proofing), and security questions are not one of them.
OWASP goes further. Its security questions cheat sheet opens with “Security questions are no longer recognized as an acceptable authentication factor per NIST SP 800-63”, and OWASP’s Forgot Password cheat sheet says they “should not be used as the sole mechanism for resetting passwords due to their answers frequently being easily guessable or obtainable by attackers.”
So security questions used for password resets get replaced, not tuned. Here is the ladder I’d build for a small app, in this order; it is my working rule, and the build column uses Supabase as the example provider.
| Recovery method | What it proves | What it costs to build on managed auth (Supabase) | Where it fails |
|---|---|---|---|
| 1. Emailed single-use reset link that expires | Control of the mailbox | Reset email provided: resetPasswordForEmail() does not reveal whether an account exists; an SMTP server is required; single use and expiry are not stated on Supabase’s password page | A taken-over mailbox takes the account with it |
| 2. Second factor, or a passkey | Possession of a phone, authenticator app or device | Provided: authenticator app (TOTP), free and enabled on all projects by default; phone factors are a paid add-on ($75 a month for the first project, $10 for each additional one, plus per-message SMS charges); passkeys are marked experimental and need an explicit opt-in | A lost phone needs rung 3 |
| 3. One-time recovery codes shown at enrollment, stored hashed | Possession of codes saved at setup | Not stated in Supabase’s MFA docs: your own code | Codes never saved |
| 4. Waiting period plus a notice to the old address and devices | Time for the real owner to object | Your own code | An owner who never reads the old address |
| 5. Support-assisted recovery with a written procedure, two people for owner accounts, every step logged | A person checked identity against the procedure | Your own code and process | An agent persuaded to skip a step |
Rung 1 is the reset flow itself, and how to build and test it is in authentication best practices. OWASP’s rules for it: the reset token is “Single use and expire after an appropriate period”, and the request returns “a consistent message for both existent and non-existent accounts.” Rung 2 means a reset alone no longer grants access; the setup is in how to implement two-factor authentication, and the provider side for Supabase is in Supabase’s MFA documentation.
Rungs 3 and 4 follow NIST’s recovery section. It says a provider offering saved recovery codes “SHOULD issue a recovery code to the subscriber” at enrollment and that they “SHALL be stored in the subscriber account in hashed form”, and that “An account recovery event always causes one or more notifications to be sent to the subscriber”.
Recovery must never be easier than login.
That is my working rule across the whole ladder, and OWASP says the same in other words: “Account recovery is just an alternate way to authenticate so it should be no weaker than regular authentication.”
When customers cannot get in at all, the platform-side causes are in why users cannot log in to your app.
Password rules come from the same NIST document: the NIST minimum password length and the rest of the current rules.
If you already shipped security questions: harden this week, retire on a date
An app that already uses security questions is fixed in 7 steps: require mailbox control as well, hash stored answers like passwords, rate limit the recovery endpoint, stop enrolling new users, add recovery codes and a second factor, delete the answers on an announced date, and check backups and analytics for copies.
- 01 Make sure answers alone can never reset a password: require control of the mailbox as well.
- 02 Hash stored answers the way you hash passwords, after lowercasing them and trimming extra spaces, and never display them back.
- 03 Rate limit the recovery endpoint per account and per IP address, and return the same response for known and unknown emails.
- 04 Stop enrolling new users in security questions.
- 05 Add the replacement, a second factor and one-time recovery codes, and prompt existing users to set it up at their next login.
- 06 Set a retirement date, announce it, and on that date delete the answers table and the code path, recording the deletion.
- 07 Check backups and analytics for copies of the answers, and note when each copy ages out.
Steps 2 and 3 draw on OWASP. Answers “should be treated in the same way as passwords, and stored using a secure hashing algorithm such as Bcrypt”, after you “convert the answer to lowercase before hashing”; trimming spaces is my addition. For the recovery endpoint OWASP names “rate-limiting on a per-account basis, requiring a CAPTCHA, or other controls” (the per-IP limit is my addition), but OWASP also says “Accounts should not be locked out in response to a forgotten password attack”, so throttle the tries rather than locking the account.
If an AI coding tool wrote the recovery flow, I would check three things in the code: answers stored in a plain-text column, answers compared in the browser rather than on the server, and a recovery route with no rate limit.
For context from my own audits: the Authentication pillar averaged 52.8 out of 100, scored on 14 of the 21 third-party apps, which ranks it 8th of 12 pillars, counting from the weakest. Those 21 are the third-party apps I audited in June and July 2026, a selected set rather than a random sample of AI-built apps; the other seven were marked not applicable for this pillar and left out, not scored zero.
In one app I audited, a Q&A app treated a missing or placeholder build-time database value as “run offline” instead of refusing to build: sign-in silently fell through to a passwordless lookup in the browser. The delivered production env file held exactly the placeholder values. The lesson I take from it: an identity check the browser performs is one the server never made.
How to verify the result
Account recovery is verified with 6 tests on your own app: answers alone cannot reset a password, wrong attempts hit a limit, no plain-text answers exist in the database, known and unknown emails get identical responses, a reset notifies the owner and writes an audit entry, and admin sign-in without the second factor reaches nothing.
Run them against the deployed app, or a staging copy with the same auth settings, using test accounts only. Each check is written so a correct build passes and a broken one fails.
- 01 Walk every recovery path as a stranger who knows the three answers but does not control the mailbox. Pass: no reset. Fail: a new password can be set. Keep: the responses.
- 02 Send wrong answers and wrong emails to the recovery endpoint from one test client until the limit trips. Pass: the limit trips, a further request from the same client inside the window is refused, and after the documented window the real test user can still recover. Fail: no limit, or the real user is locked out for good. Keep: the responses with their times.
- 03 Read the database. Pass: no plain-text answers, or no answers table at all. Fail: answers readable as typed. Keep: the query and its result.
- 04 Request a reset for a known and an unknown email and compare status, body and rough timing over several tries. Pass: no difference a script could use. Fail: any consistent difference. Keep: both responses.
- 05 Reset the password on a test account. Pass: the owner is notified and an access-controlled audit entry exists. Fail: either is missing. Keep: the notice and the entry.
- 06 Sign in to each owner and admin account with the password alone, in the app and on each provider dashboard. Pass: no admin page, admin data or dashboard setting is reachable until the second factor is passed. Fail: anything admin loads. Keep: dated screenshots.
On check 6, Supabase marks a password sign-in as aal1, and aal2 only after a second factor; its docs say that by reading that level you can create authorization rules in your frontend, backend and database that enforce your MFA policy, and check 6 is what tests those rules.
In the Production Hardening Sprint, we verify deliverable 1.6, Authentication abuse protection, this way: simulate repeated attempts and verify limits, responses, and normal-user recovery.
Where the sprint fits
No sprint deliverable is named “remove security questions”. The four closest are Complete authentication flow review, where we review and fix signup, login, logout, password reset, email verification, and OAuth callbacks (1.1); Authentication abuse protection, where we implement rate limits and brute-force protections on authentication and recovery endpoints (1.6); Sensitive-action audit log (1.10); and Two-factor authentication for owner and admin accounts (1.11). New features that change the product’s core capabilities are separate work; the sprint includes only the supporting interfaces the listed controls need, such as session management, account deletion and billing self-service. Formal third-party certifications and independent audit opinions are separate from the sprint deliverables. Every deliverable is listed in the published scope.
Common questions about secret questions and recovery
What is a funny security question?
A funny security question is one you write yourself as a joke, and it is harder to find in public records but easier to forget or misspell. If a site lets you write one, my working rule is to make the answer a random string saved in a password manager, and keep the humor for yourself.
What should I put as my security question?
When a site forces a security question on you, pick any question and give it a random answer, stored in your password manager next to the password: never a true fact, and never the same answer on two sites. That is my working rule, and Okta’s guide gives similar advice: “use a false answer that others can’t verify, ideally with a random string of characters.”
What is an easy security question?
An easy security question is one whose answer is easy to give, which also makes it easy to guess or look up; that is the whole problem with them. The family and origin questions and the firsts in the list above are the easy ones.
What if I forgot the answer to my security question?
Use the provider’s other recovery route, such as email, a phone or recovery codes, and be ready for a wait: NIST notes that, depending on the situation and the recovery methods offered, recovery “may involve extended waiting times.” On a Microsoft work or school account, for example, Microsoft’s support page has you select “Can’t access your account?” and then “Select one of the methods to verify your identity and change your password”; if self-service reset is off, you see a “Contact your administrator” link instead.
For an app owner, this is the support ticket that replacing security questions removes.
The checks in this guide show you where the app is open. The sprint below closes those gaps, tests the result and writes the evidence down.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase