What is a TOTP secret?
Understand the shared Base32 key behind time-based authentication codes.
Contents
- What the secret actually is
- How your authenticator generates a code
- Your code is rejected and you typed it correctly
- Treat the secret like the password itself
- Recovery codes are the part people skip
- TOTP vs HOTP vs passkeys
- What to remember
- References
You're setting up two-factor authentication. The site shows a QR code and, underneath, a string like JBSWY3DPEHPK3PXP. It says to keep it safe. Safe from what, and what happens if you lose it?
That string is a public demonstration value. Never use it to protect a real account.
Short version. A TOTP secret is a shared key used to generate time-based one-time passwords. Your authenticator and the service both hold it. Someone who obtains the key can reproduce your codes while the service still accepts that key. Generating a code does not require an internet connection.
What the secret actually is
During setup, the service provides a secret that your authenticator stores. Think of it as giving two people the same key-making instructions: both can produce matching results independently.
The secret is commonly displayed in Base32, using letters A–Z and digits 2–7. This is a text representation of the key, not encryption.
A setup QR code normally contains more than the secret. It can also identify the account and service and specify settings such as the code length or refresh interval. Scanning it imports that information. Manual setup can produce the same result, provided the key and required settings match.
Treat the QR code as sensitive too. A photo of it may be enough for someone to copy your authenticator setup.
How your authenticator generates a code
The app combines the secret with a time-step number using a keyed calculation called HMAC, then reduces the result to a short numeric code. Six digits and 30-second steps are common, but other settings exist.
The service checks your submitted code using the same setup. Generation happens locally; the code is sent to the service when you enter it to sign in.
That's why an authenticator can generate codes in airplane mode. Optional backup or synchronisation features are separate from this calculation.
Try the public demonstration value above at the TOTP Generator. Use it only to observe the mechanism, never as an account secret.
Your code is rejected and you typed it correctly
An incorrect device clock is one possible cause, but rejection alone does not identify the problem. Check these points in order:
- Confirm the account. Choose the entry for the correct service and username. An old or duplicate entry may use a different secret.
- Wait for a fresh code. A code near the end of its displayed interval may expire before submission.
- Check the device clock. Enable automatic date and time in the device settings. The service's allowed time tolerance varies; there is no universal cutoff at exactly 30 seconds.
- Check the setup. If codes have never worked, a mistyped key or mismatched settings are possibilities, alongside an incorrect clock. Follow the service's setup instructions.
- Use the service's recovery options if needed. Repeated attempts may trigger a temporary limit. Follow any message shown by the service.
Older instructions may mention a separate Google Authenticator time-correction menu. Google removed it in version 7.0; use the operating system's time settings.
Do not delete your only authenticator entry while troubleshooting. First confirm that you can access the account through a recovery code, another registered method, or the service's recovery process.
Treat the secret like the password itself
A stolen secret compromises the TOTP factor. It does not necessarily reveal your password or bypass every other sign-in check, but it removes the protection that factor was meant to provide.
- Keep real secrets and setup QR codes out of support tickets, chats and shared screenshots.
- Avoid storing unprotected copies in email or ordinary notes.
- Use a secure backup method that you understand and can recover.
- Use demonstration secrets in testing tools. Do not enter a live account secret into this website's generator.
If a secret is exposed, use the affected service's security settings to reset or replace its authenticator registration. Confirm that the replacement works and that the old registration has been revoked.
Deleting an entry from your authenticator app does not revoke the service's secret. It only removes that app's copy. A password change alone should not be relied on to invalidate the exposed TOTP key either.
Recovery codes are the part people skip
If the service offers one-time recovery codes, save them during setup. They can provide another way in if your authenticator becomes unavailable.
Keep them somewhere secure that you can reach without the lost phone. That might be a protected password manager you can access from another device, or a printed copy stored safely.
Check the recovery dependency: if opening your password manager requires the very authenticator you lost, a copy inside it may not help.
Losing a phone does not always mean losing account access. You may have an authenticator backup, another registered device, a passkey or another recovery method. The available options depend on the service and your setup.
If you have none of these, recovery may be difficult or unavailable. Do not assume support can restore access.
TOTP vs HOTP vs passkeys
| Feature | TOTP | HOTP | Passkeys |
|---|---|---|---|
| Main mechanism | Shared secret and time step | Shared secret and counter | A cryptographic key pair associated with the service |
| What the user does | Enters a short code | Enters a short code | Approves sign-in through an authenticator, often with device unlock |
| Timing | Commonly 30-second steps | No inherent timed expiry; acceptance follows counter state and service rules | Uses a sign-in challenge rather than a rotating code |
| Clock agreement for code calculation | Required within the service's tolerance | Not required | No shared clock-based code calculation |
| Phishing resistant | No | No | Yes, through binding to the intended service |
HOTP advances with a counter, which can move forward when a code is requested. It therefore needs counter coordination rather than a shared time step.
A phishing page can ask for a TOTP code and immediately relay it to the real service while it remains acceptable. A passkey authenticates to the intended service instead of exposing a reusable password or a code for the user to hand over.
Where supported, passkeys offer stronger protection against this kind of phishing. Recovery methods and fallback sign-in options still matter. Adding TOTP to a password remains a useful improvement over using the password alone.
What to remember
- Protect the secret and its setup QR code.
- Code generation works offline; account sign-in still involves the service.
- Check the account, code timing, device clock and setup when codes fail.
- Establish recovery access before deleting an authenticator entry.
- Reset an exposed secret at the service; deleting the app entry is not enough.
- Consider passkeys where available, and keep recovery methods secure.
Explore the mechanism with a demonstration secret at the TOTP Generator.