TOTP Generator
Free TOTP generator for 2FA codes from a Base32 secret or an otpauth link. Checks a code against nearby time steps and runs in your browser.
Updated
A Base32 secret or an otpauth://totp or otpauth://hotp link.
A code from an app, a device, or a log.
Options
Type, algorithm, digits, and period come from the otpauth:// link.
A whole number from 1 to 3600.
Added to this device's clock, from -86400 to 86400.
Unix seconds, or a UTC date and time such as 2023-11-14T22:13:20Z.
Create a test secret
A random secret as long as the HMAC output of the selected algorithm, for test accounts only. The otpauth:// link and QR code use these names.
Paste a Base32 secret or an otpauth:// link, or create a test secret.
What Is a TOTP Generator?
The TOTP generator computes the one-time codes an authenticator app shows for a shared secret. Paste a Base32 secret or an otpauth:// link and it shows the current code, the previous and next codes, and the seconds left in the time step. It also computes HOTP codes for a counter, checks a code from another device against nearby time steps and other settings, and creates test secrets with an otpauth:// link and a QR code. The page computes the codes with the Web Crypto API.
How to Use the TOTP Generator
- Paste a Base32 secret or an otpauth:// link. Spaces, hyphens, and padding in a secret are ignored.
- For a plain secret, open Options and pick the type, algorithm, digits, and period the service uses. A link sets them for you.
- Read the current code and the seconds left. Switch to a fixed time under Options to reproduce a code from a log or a test.
- To find out why a code was rejected, enter it under Check a code. The tool searches nearby time steps and other settings.
- To set up a test account, open Create a test secret, then show the QR code or copy the otpauth:// link.
How It Works
A TOTP code is an HOTP code whose counter is the number of time steps since the Unix epoch: T = (current Unix time - T0) / X, rounded down, where X is the time step in seconds and T0 is 0 (RFC 6238). The default step is 30 seconds. With a 30 second step, T is 1 at Unix time 59 and 2 at Unix time 60.
HOTP (RFC 4226) signs the counter, as an 8-byte value, with HMAC and the shared secret. Dynamic truncation takes the low 4 bits of the last byte of the HMAC as an offset, reads 4 bytes from there as a 31-bit number with the first bit masked off, and keeps the remainder after division by 10 to the power of the number of digits. RFC 4226 uses HMAC-SHA-1 and allows 6, 7, or 8 digits. RFC 6238 allows HMAC-SHA-256 and HMAC-SHA-512 for TOTP.
Secrets are usually written in Base32 (RFC 4648 section 6), which uses the letters A to Z and the digits 2 to 7, ignores case, and pads the end with "=". RFC 4648 requires decoders to reject characters outside the alphabet. Whole bytes always encode to 0, 2, 4, 5, or 7 characters past a multiple of 8, so a secret with 1, 3, or 6 extra characters was cut short. Conforming encoders set the unused bits of the last character to zero.
Authenticator apps usually receive a secret as an otpauth:// link in a QR code, in the Key Uri Format: otpauth://type/label?parameters. The label is the issuer and the account name separated by a colon, and neither may contain a colon of its own. The parameters are secret, issuer, algorithm (SHA1 by default), digits (6 by default), period (30 seconds by default), and counter, which HOTP requires. Padding should be left out of the secret.
The Key Uri Format page was last edited on 26 November 2018, and its repository was archived on 6 April 2021. It states that Google Authenticator ignores the algorithm and period parameters, and that on Android and BlackBerry it ignores digits. When an app shows different codes, compare them with SHA-1, 6 digits, and 30 seconds.
A verifier must accept each code only once (RFC 6238, NIST SP 800-63B-4). RFC 6238 recommends allowing at most one time step of network delay and setting a limit on how many steps a device may drift. NIST SP 800-63B-4 states that OTP authentication is not phishing-resistant.
RFC 6238 Appendix B lists test codes for HMAC-SHA-1, HMAC-SHA-256, and HMAC-SHA-512, such as 94287082 for SHA-1 at Unix time 59 with 8 digits. Verified erratum 2866 notes that the secrets differ per hash: 20 bytes for SHA-1, 32 for SHA-256, and 64 for SHA-512, while the RFC text names only the 20-byte secret. The RFC 6238 example chips load the corrected secrets.
Standards
Scope
What It Checks
- +Computes TOTP codes (RFC 6238) and HOTP codes (RFC 4226) with HMAC-SHA-1, HMAC-SHA-256, or HMAC-SHA-512 and 6, 7, or 8 digits.
- +Reads a Base32 secret or an otpauth://totp or otpauth://hotp link.
- +Shows the previous and next codes and the seconds left in the current time step.
- +Computes codes for a fixed Unix time or with a clock adjustment.
- +Checks a code against 10 time steps either side and against other algorithms and periods.
- +Creates a random test secret with an otpauth:// link and a QR code.
- +Names the problem when a secret or a link is rejected, such as a character outside the Base32 alphabet or a length that cannot be complete.
What It Does Not Check
- -It does not store the secret, put it in the page address, or send it anywhere.
- -It does not support a start time (T0) other than the Unix epoch.
- -It does not decode QR images, Google Authenticator export links, or Steam Guard codes.
- -It does not verify codes for a sign-in, track used codes, or limit attempts, as a verifier must.
Defensive Use
Reproduce the codes an authenticator should show while testing a verifier's TOTP settings: algorithm, digits, period, and how many time steps of clock drift it accepts. RFC 6238 recommends allowing at most one time step of network delay, and NIST SP 800-63B-4 requires verifiers to accept each OTP only once.
Frequently Asked Questions
What is a TOTP Generator?→
The TOTP generator computes the one-time codes an authenticator app shows for a shared secret. Paste a Base32 secret or an otpauth:// link and it shows the current code, the previous and next codes, and the seconds left in the time step. It also computes HOTP codes for a counter, checks a code from another device against nearby time steps and other settings, and creates test secrets with an otpauth:// link and a QR code. The page computes the codes with the Web Crypto API.
What is the TOTP Generator used for?→
Testing two-factor sign-in during development: reproducing the codes a server expects, finding out why an authenticator app and a server disagree, and creating secrets and otpauth:// links for test accounts.
Is my data sent anywhere?→
No. The TOTP Generator runs in your browser. What you enter stays on this page and is not sent to ImmunitySec or anyone else.
How is the TOTP Generator used defensively?→
Reproduce the codes an authenticator should show while testing a verifier's TOTP settings: algorithm, digits, period, and how many time steps of clock drift it accepts. RFC 6238 recommends allowing at most one time step of network delay, and NIST SP 800-63B-4 requires verifiers to accept each OTP only once.
Should I paste a real secret into this page?→
Use a test secret where you can. The page keeps nothing and sends nothing, but RFC 6238 recommends storing keys securely and exposing them only when required. The Create a test secret panel makes a random secret for test accounts.
Why does my code not match my authenticator app?→
Codes differ when the clocks differ or when the time step, algorithm, or number of digits differ. TOTP codes depend on the current time step, so a device clock that is wrong by more than a few seconds gives a different code. The Key Uri Format page states that Google Authenticator ignores the algorithm and period parameters. Enter the app's code under Check a code to see whether it matches a nearby time step or other settings.
What is the difference between TOTP and HOTP?→
HOTP (RFC 4226) computes a code from a counter that goes up by one for each code. TOTP (RFC 6238) uses the same algorithm with a counter derived from the current time, the number of time steps since the Unix epoch, so codes change every 30 seconds by default.
Which algorithm, digits, and period should I use?→
The Key Uri Format defaults are SHA1, 6 digits, and 30 seconds, and RFC 6238 recommends a 30 second time step. RFC 4226 requires shared secrets of at least 128 bits and recommends 160 bits, and RFC 6238 says keys should be as long as the HMAC output. Before choosing other values, check that the authenticator apps your users rely on accept them.
Is TOTP phishing-resistant?→
No. NIST SP 800-63B-4 states that OTP authentication is not phishing-resistant. A phishing attack tricks a person into presenting an authenticator, such as a one-time code, to a fake verifier.
Why do the RFC 6238 SHA-256 and SHA-512 test values not match my secret?→
RFC 6238 erratum 2866, which is verified, explains that the test values use a different secret per hash: the 20-byte ASCII string 12345678901234567890 for SHA-1, a 32-byte string for SHA-256, and a 64-byte string for SHA-512. With the 20-byte secret, SHA-256 and SHA-512 give other codes.