Auth Key (TOTP) Generator

What an auth key generator creates

Two-factor authentication apps such as Google Authenticator, Microsoft Authenticator, Authy, 1Password and Bitwarden all work from one shared secret: a random string, usually written in Base32, that both your server and the app know. Every 30 seconds each side runs the same calculation on that secret and the current time and arrives at the same six digits. That scheme is called TOTP, short for time-based one-time password, and it is defined in RFC 6238 on top of the HOTP counter method in RFC 4226. This page generates the shared secret, builds the otpauth:// link and QR code that authenticator apps import, and shows the live code so you can check everything works before you ship it.

Typical uses are building 2FA into your own app and wanting a test secret, setting up a second authenticator for an account that gives you a text key instead of a QR code, and learning how the algorithm behaves. If you need a plain password or API key instead, use the Password and Key Generator.

How to use it

1. Enter an issuer and account. These are only labels. They show up in the authenticator app so you can tell entries apart, for example "Example App" and "you@example.com".
2. Pick a strength. 160 bits (32 Base32 characters) is the length RFC 4226 recommends and what most services issue. The 80-bit option is the minimum the RFC allows and is only for compatibility testing.
3. Keep SHA-1, 6 digits and 30 seconds unless you control both ends. Those are the only parameters every authenticator app honours. Google Authenticator in particular ignores the other settings and will show wrong codes if you change them.
4. Scan the QR code with your authenticator app, or paste the secret in manually. The app should immediately show the same six digits as the live code on this page.
5. Verify. Type the code from your app into the check box. A match inside a one-step window either side of now counts as valid, the same tolerance servers use for small clock drift.

Everything stays in your browser

The secret is created with the browser's cryptographic random generator and every code is computed locally with the Web Crypto HMAC functions. Nothing is sent to a server, and nothing is stored once you close the tab. That still does not make a secret you pasted into any web page throwaway: treat any key you use for a real account like a password, and do not generate production keys on a shared computer.

Adding TOTP to your own app safely

• Generate one secret per user on the server with a cryptographic random source, never derived from the user's name or email.
• Store it encrypted, not hashed. The server needs the actual secret to compute codes, so protect it the way you protect other credentials, with encryption keys held separately from the database.
• Accept a small window. Allow the previous and next time step to cover clock drift, and reject a code that was already used so it cannot be replayed within the window.
• Rate-limit attempts. A six digit code has only a million possibilities, so lock or slow down after a handful of wrong guesses.
• Offer recovery. Issue single-use backup codes at enrolment, and let users re-enrol by proving identity another way. Our guide to sending passwords safely covers handoff options for the codes themselves.

Troubleshooting codes that do not match

The most common reason a code is rejected is clock drift. TOTP depends on both sides agreeing on the time to within a step, so a phone with automatic time switched off, or a server that has lost NTP sync, produces codes that never validate. Check the device time first. The second cause is mismatched parameters: if you changed the algorithm, digits or period here but the app ignored them, the app is computing a different code. Reset to SHA-1, 6 digits and 30 seconds. The third cause is typing the secret by hand with look-alike characters. Base32 never uses 0, 1, 8 or 9, so a character like O or I in a secret is a typo.

Frequently asked questions