AnyTool
Your files never leave your device. All processing happens locally in your browser.

How do I set up two-factor authentication with an authenticator app?

Use the 2FA Setup Guide: it generates a strong Base32 secret in your browser, shows an otpauth:// QR to scan (or a manual-entry key) for Google Authenticator / Authy / Microsoft Authenticator / password manager apps, verifies the 6-digit code your app returns with real RFC 6238 crypto, and creates one-time backup codes to download or print. Everything runs locally — nothing is uploaded — and the real service you’re protecting must store the same secret.

  • Step 1: generate a 160-bit Base32 secret (crypto.getRandomValues) + set issuer / account
  • Step 2: scan the otpauth QR or type the manual key into your authenticator app
  • Step 3: verify the live code matches the secret (RFC 6238, ±1 step for clock drift)
  • Step 4: download or print 10 single-use backup / recovery codes and store them offline
  • 100% client-side — the secret and codes never leave the browser

What is

TOTP 2FA setup

Setting up app-based two-factor authentication (2FA) means sharing a secret key between a service and an authenticator app so the app can generate Time-based One-Time Passwords (TOTP, RFC 6238). Setup has four parts: a random Base32 secret, an otpauth:// key URI (usually shown as a QR code) that carries the secret plus algorithm, digit count and time period, a verification step where you prove the app produces a matching code, and a set of one-time backup codes kept offline in case the authenticator device is lost.

Security & Privacy

Related terms

TOTPRFC 6238RFC 4226 HOTPBase32otpauth URIauthenticator appGoogle AuthenticatorAuthybackup codesrecovery codesHMAC-SHA1passkeys / WebAuthn

Frequently Asked Questions

No. The secret, the QR, every TOTP code and the backup codes are generated and checked entirely in your browser and are never uploaded, logged or stored on a server.

The whole wizard is 100% client-side. The Base32 secret and the backup codes come from your browser’s crypto.getRandomValues, each TOTP code is computed with the native Web Crypto API (crypto.subtle HMAC, RFC 4226 / 6238), and the otpauth QR is drawn on a local canvas — there is no server, no upload and no CDN in the crypto path. Nothing persists once you close the tab. Because it runs offline, it is safe for real secrets, but you should still treat the secret and codes like passwords and keep them somewhere secure.

They are single-use codes that let you sign in if you lose your authenticator device. Keep them offline — printed and stored safely, or in a password manager — never only on the same phone as the app.

When you turn on app-based 2FA, most services also give you a handful of one-time backup (recovery) codes. Each works once and bypasses the need for your authenticator, so they are your lifeline if your phone is lost, wiped or replaced. Store them the way you would store a spare key: print them and keep the paper in a safe place, or save them in an encrypted password-manager entry for that service — crucially, not only on the same device that holds the authenticator, and never as a screenshot in your photo roll or an email to yourself. Regenerate a fresh set (which invalidates the old ones) if you ever suspect they were exposed.

Keep the defaults: SHA-1, 6 digits, 30 seconds. They match every major authenticator app and almost every service.

RFC 6238 lets a service pick the HMAC algorithm (SHA-1/256/512), the code length (usually 6, sometimes 8) and the time step (usually 30 s). If the service and your app disagree on any of these, the codes will never line up. In practice you should leave SHA-1 / 6 / 30 alone: Google Authenticator ignores the algorithm field and always uses SHA-1, so SHA-256/512 only take effect in apps like password manager apps, Authy or Bitwarden. Only change a value if the specific provider you’re enrolling with explicitly asks for it.

TOTP is far stronger than SMS (no SIM-swap or SS7 interception) but is still phishable in real time. Where a service offers passkeys or hardware security keys, those are stronger.

Authenticator-app TOTP is a solid, widely-supported second factor and a big upgrade over SMS codes, which can be intercepted via SIM-swapping or SS7 attacks. Its weak points are the secret itself — anyone who obtains it can generate your codes forever, so guard it — and real-time phishing, where an attacker relays a code within its short window; TOTP is not fully phishing-resistant. For the strongest protection, prefer passkeys or hardware security keys (WebAuthn / FIDO2) on services that support them, and always keep TOTP as one factor alongside a strong, unique password.

Detailed Explanation

How It Works

What the 2FA / TOTP Setup Guide Does

This tool is a guided, four-step wizard for turning on app-based two-factor authentication, run entirely in the browser. Step 1 generates a strong 160-bit Base32 secret (RFC 4648) with crypto.getRandomValues and lets you set the issuer, account label and the algorithm / digits / period. Step 2 renders the otpauth:// key URI as a scannable QR and shows the manual-entry key with per-app hints for Google Authenticator, Authy, Microsoft Authenticator and password manager apps. Step 3 verifies the code your app produces against the secret using the native Web Crypto HMAC, with a ±1-step tolerance for clock drift. Step 4 issues ten single-use backup / recovery codes to download or print. A live current code and countdown ring show, at a glance, exactly what your app should display.

  • Four steps: secret → add-to-app QR → verify → backup codes
  • 160-bit Base32 secret and recovery codes from crypto.getRandomValues
  • otpauth QR + manual key for the major authenticator apps
  • Verify uses Web Crypto HMAC with ±1-step drift tolerance
  • Live current code + countdown ring for reassurance
Methodology

How TOTP Setup Works (RFC 6238 / 4226 / 4648)

A shared secret is the root of app-based 2FA. The wizard encodes 20 random bytes as Base32 (RFC 4648, alphabet A–Z 2–7) so it can be typed or embedded in a QR. The otpauth:// key URI carries that secret plus issuer, account, algorithm, digits and period. To produce a code, the app and this tool both build a counter = floor(unixTime / period), compute HMAC(secret, counter) with the chosen hash (RFC 4226 HOTP), apply dynamic truncation to the MAC, and reduce it modulo 10^digits — the TOTP construction of RFC 6238. Verification recomputes the code for the current step and the neighbouring steps and compares, so a small clock offset still matches. Defaults are SHA-1 / 6 digits / 30 seconds because those interoperate with every mainstream app.

  • Secret: 20 random bytes → Base32 (RFC 4648)
  • counter = floor(unixTime / period); HMAC(secret, counter) = HOTP (RFC 4226)
  • Dynamic truncation → code mod 10^digits = TOTP (RFC 6238)
  • otpauth:// URI carries secret + algorithm/digits/period
  • Defaults SHA-1 / 6 / 30 interoperate with all major apps
Technical Details

Local Cryptography and Backup Codes

All secure randomness comes from crypto.getRandomValues — never Math.random. Each TOTP code is computed with crypto.subtle (Web Crypto) HMAC over the decoded secret bytes, matching the maths the authenticator app runs. The QR is drawn on a local canvas via the qrcode library; no image is fetched. Backup codes are generated by a pure engine (recoveryCodesEngine.ts) using rejection sampling over a 31-symbol unambiguous alphabet (digits 2–9 and lowercase letters minus 0/1/i/l/o), which removes modulo bias and hand-typing errors while keeping roughly 49 bits of entropy per code. The downloadable / printable file is self-describing: it records the service, account and date, states that each code is single-use, and includes offline-storage guidance.

  • crypto.getRandomValues for the secret and every backup code
  • crypto.subtle HMAC computes the TOTP codes (no mocks)
  • QR rendered locally with the qrcode library — no fetch
  • Backup codes use rejection sampling → no modulo bias, ~49 bits each
  • Downloaded file records service, account, date + storage advice
Limitations

Honest Limitations

This wizard configures and tests TOTP correctly, but it is an aid, not a guarantee. The single most important caveat: the real service you are protecting must store this same secret — a key generated here in isolation does not protect an account that never received it, so use it inside the provider’s own "set up authenticator" flow. The secret is everything: anyone who has it can generate your codes forever, so guard it like a password and put your authenticator on a device separate from the browser holding your passwords. Codes depend on an accurate clock; a wrong device time yields wrong codes, and the ±1-step verify absorbs only small drift. And TOTP is phishable in real time and not fully phishing-resistant — where a service offers passkeys or hardware security keys (WebAuthn / FIDO2), those are strictly stronger.

  • The real service must store the SAME secret — enrol via its own flow
  • Whoever holds the secret can generate your codes — guard it
  • Wrong device clock → wrong codes (±1 step absorbs only small drift)
  • TOTP is phishable in real time; not fully phishing-resistant
  • Passkeys / hardware keys (FIDO2) are stronger where available
Privacy & Security

Private by Design

Everything happens on your device. The secret and backup codes come from crypto.getRandomValues, TOTP codes are computed with the Web Crypto API, and the otpauth QR is drawn on a local canvas — there is no server, upload, CDN, logging or telemetry in the crypto path, and nothing is persisted, so closing the tab erases it. That makes it safe to generate real secrets and codes here. The downloadable backup-code file is created in the browser with a Blob and never leaves your machine; the print option opens a local window. The only optional network use anywhere on the site is consent-gated ads, which never see your secret, codes or QR.

  • Secret, codes and TOTP all generated/computed locally
  • No server, upload, CDN, logging or telemetry in the crypto path
  • Nothing persisted — closing the tab erases everything
  • Backup-code file built locally with a Blob; never uploaded
  • Only optional network use is consent-gated ads
Second-factor options compared
MethodStrengthMain weaknessThis tool
Authenticator-app TOTPStrong, widely supportedPhishable in real time; secret must be guardedSets up + verifies
SMS one-time codesWeakSIM-swap / SS7 interception; plaintextNot recommended
Backup / recovery codesFallback onlySingle-use; must be stored offline and safeGenerates 10 codes
Passkeys / security keys (FIDO2)StrongestRequires service + device supportPrefer where offered

App-based TOTP is a major upgrade over SMS; add passkeys / hardware keys where a service supports them. Everything here runs locally in the browser. As of July 2026.