Twilio Authy

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me a two-factor authenticator that replaces Authy: my one-time-code seeds, encrypted, backed up, and on more than one device.

Read this first, because it is the whole point. This holds the second factor for every account you own. A bug here does not lose data, it locks you out of your bank, your email and your entire identity. Build it carefully or use one of the excellent open alternatives — and either way, print your recovery codes today.

STACK
- The app: a small cross-platform client, or a web app installable as a PWA with an offline-first store
- The sync server: Node 20+ with Fastify, SQLite through better-sqlite3
- Cryptography from a reviewed library — libsodium, or the platform's own. Never a hand-rolled construction, never a homemade key derivation
- Caddy in front

THE CODES THEMSELVES
- TOTP per RFC 6238: HMAC-SHA1 by default, six digits, a thirty-second step, with SHA256 and SHA512 and eight digits supported because some services use them
- HOTP per RFC 4226, with a counter, for the few services that use it
- Accept a window of one step either side on verification, and show the remaining seconds as a ring so a code is never typed at the moment it expires
- Import from an otpauth:// URI and from a QR code, including the migration format that exports a whole set at once
- The implementation is fifty lines. Test it against the vectors in the RFC before anything else exists

ENCRYPTION, WHICH IS THE ACTUAL PRODUCT
- The seeds are encrypted on the device with a key derived from a passphrase using argon2id at parameters that cost a second on the slowest device you support
- The server stores ciphertext and nothing else. It never has the passphrase, never has the key, and cannot decrypt a single seed. This is not a feature, it is the reason to trust the thing
- Authenticated encryption with a random nonce per record; a tampered blob fails to decrypt rather than decrypting to rubbish
- The passphrase is separate from the account password. If it is lost, the backup is gone — say this at setup, in plain words, and make the user acknowledge it
- Key rotation: re-encrypt everything under a new passphrase, atomically, with the old blobs kept until the new ones are confirmed on every device

SYNC AND MULTIPLE DEVICES
- Each device has its own key pair; adding one is approved from a device already trusted, by scanning a code or confirming a short number shown on both
- The vault syncs as encrypted records with a version and a last-writer timestamp; a conflict keeps both and asks, rather than silently choosing
- Removing a device revokes its access immediately and forces a re-encryption if the passphrase might have been on it
- A device list showing name, platform, when it was added and when it was last seen

RECOVERY, WHICH IS THE ONLY REASON PEOPLE LEAVE A PLAIN AUTHENTICATOR
- An export: the whole vault as an encrypted file, downloadable at any time, in a documented format
- A plain export too, behind a deliberate confirmation, because a vault you cannot leave is a trap of a different kind
- Printable recovery sheet with the QR codes, which is what you actually want in a safe
- A written recovery procedure in the README: what to do with a lost phone, a forgotten passphrase, a dead laptop. Untested recovery is not recovery — test all three

THE APP
- Works entirely offline. The server is for backup and sync, and the app must generate codes with no network at all, forever
- Biometric or device passcode to open, with a timeout, and the seeds held encrypted at rest in the platform's secure storage
- Search, folders, and an icon per service
- Copy a code with one tap, and clear the clipboard after a short delay
- Never take a screenshot of the code list on platforms where that can be prevented

WHAT NOT TO DO
- No cloud backup that the server can read. That is the design flaw people criticised the original product for
- No SMS anything, ever
- No analytics in the app. Not one event. This app knows which services you have accounts with, and that list is nobody's business
- No web view showing codes on a site you do not control

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, HASH_SALT
- Migrations on boot, each once
- The server's backup contains only ciphertext, which makes it safe to store anywhere — and say so
- Health endpoint

WHAT MATTERS MOST
The RFC vectors, then the encryption, then recovery. Write the TOTP tests first, use a reviewed crypto library for everything else, and rehearse a full restore onto a clean device before you move a single real account onto this. Nothing else in this catalogue can lock you out of your own life.

Give me the repository, the app, the sync server, migrations, .env.example, and a README with the threat model, the recovery procedure and the honest statement of what is and is not protected.