Security questions, generated for testing
This tool produces classic knowledge-based authentication (KBA) question-and-answer pairs, the kind you still see in legacy account-recovery flows: “What was the name of your first pet?”, “In what city were you born?”, and so on. Each pair comes with a randomly chosen but plausible sample answer so the data is self-consistent for QA fixtures and UI demos.
How it works
The generator keeps a curated bank of common security questions and, for each question, a matching pool of realistic-but-fake answers (pet names, cities, school names, and so on). When you generate a set it samples questions without repeats, then picks one answer at random from the pool that fits that question. The result is a list of pairs you can drop straight into a recovery-flow mockup or a test database.
Because the answers are drawn from fixed pools, the same question can produce different answers on each run, which is exactly what you want for stress-testing a form.
Example output
[
{ "question": "What was the name of your first pet?", "answer": "Biscuit" },
{ "question": "In what city were you born?", "answer": "Bristol" },
{ "question": "What was the name of your primary school?", "answer": "Maplewood Primary" }
]What developers actually use this for
QA engineers seed test databases so automated recovery-flow tests run against realistic data rather than blank fields that would never appear in production. UI designers fill in a security-question screen during a Figma prototype review so stakeholders see real-looking text instead of placeholder labels. Security trainers use the generated pairs to demonstrate to non-technical colleagues why KBA is a weak second factor — seeing how guessable a typical “first pet’s name” is makes the lesson concrete.
Why KBA remains common despite its weaknesses
Security questions are cheap: they need no additional hardware, no SMS gateway, and no email. For systems built before modern MFA was practical — banking portals, government services, healthcare platforms — they persist in account-recovery paths even when login itself uses stronger factors. Many organisations cannot remove them without risking customer lockouts, so they stay.
Tips and notes
- KBA is a weak factor. Real answers are often discoverable on social media, so never rely on these for production security. Treat the output strictly as fixtures.
- For seeding a database, use the JSON output. For a quick screenshot or design review, use the plain list.
- Pair this with the backup-code generator if you are mocking a full account-recovery screen.
- Generate several batches to simulate different user profiles — a real recovery-flow test suite covers at least a dozen distinct question types.