Legitimate use cases

Guide · when generated codes are the right tool

The ReKey generator produces codes that look like 2FA backup codes but authenticate nothing. That limitation is the point: there is a whole class of work where you need realistic-looking codes precisely because real credentials must stay out of it. Here are the four legitimate uses.

1. Testing 2FA login flows

If you are building or maintaining an application with two-factor authentication, the "lost your device?" path needs exercising just like the happy path. Generated codes let you:

• Walk through the backup-code entry screen: input validation, formatting, error states for wrong codes.
• Test the single-use lifecycle: mark a code as spent after first use and confirm the second attempt is rejected.
• Verify regeneration flows: issuing a fresh set and invalidating the old one.
• Seed automated tests and staging databases with plausible fixtures instead of hand-typed placeholders like AAAA-AAAA.

Use these only against test and staging environments with test accounts. Never paste generated strings into production authentication systems and expect them to mean anything — and never use real backup codes as test fixtures, since that puts genuine credentials into logs, screenshots and version control.

2. Documentation and tutorials

Writing a setup guide, a security onboarding doc, or a tutorial about two-factor authentication? Readers need to see what a backup-code screen looks like. A generated set gives you:

• Realistic examples for help-center articles ("your codes will look something like this").
• Filler for video tutorials and course material where showing a real set would leak genuine credentials.
• Sample data for API documentation of endpoints that issue or accept recovery codes.

Pair the examples with a clear caption that they are illustrative — readers should never mistake sample codes for working ones.

3. Demos, mockups and screenshots

Designers and developer advocates constantly need believable screens without believable secrets:

• UI mockups and prototypes of 2FA settings pages, where lorem ipsum would break the illusion.
• Product screenshots and marketing pages showing a backup-code list — with generated codes, there is nothing sensitive to accidentally expose.
• Conference talks and live demos, where projecting a real code list would be a genuine security incident.

4. QA seed data and load testing

QA engineers need volume: hundreds of code sets to test list rendering, pagination, copy/download features, and edge cases like the maximum set size. Generating 50 sets in seconds beats hand-crafting fixtures, and because the strings are random, they exercise validation logic more honestly than repeated TEST-1234 values.

What these codes are never for

Equally, do not use this tool to impersonate a service's security communications, forge "backup code" emails, or create phishing material. Generated strings are for building and explaining — never for deceiving.

A quick checklist before you generate

• Am I in a test, doc or demo context? If yes, generate away.
• Could anyone mistake these for working codes? Label them as samples.
• Am I touching a real account or production system? Stop — only that service's own issued codes apply there.