TOTP, HOTP & OCRA One-Time Password Calculator

Work out a TOTP, HOTP or OCRA one-time password from a shared secret, with the algorithm, digits, counter and challenge the token uses. The secret never leaves the tab.

How it works

TOTP, HOTP and OCRA are one computation: an HMAC over an eight-byte counter, cut down to a number of digits by RFC 4226's dynamic truncation. HOTP counts uses, TOTP counts periods of 30 seconds (by default) since 1970, and OCRA hashes a challenge, and whatever else its suite names, into a longer message. The code is recomputed as the fields change, in the tab; the secret is not sent anywhere.

The secret is read as Base32 by default, which is what authenticators print and otpauth:// URIs carry; spaces, lower case and missing padding are accepted. Hex is how the RFCs write their keys, and Text takes the characters as typed. The icon in the box generates 20 bytes for SHA-1, 32 for SHA-256 and 64 for SHA-512.

Leave Time empty and TOTP follows the clock, with a bar for the seconds left; type epoch seconds, which the time converter works out from a date, to pin a moment. Under the code the page prints the counter, or the time step in decimal and hex, to check against a server's log. For TOTP and HOTP the URI box holds the otpauth:// line an authenticator enrols from, in step with the fields both ways, with a QR icon to scan it.

Examples

RFC 6238's SHA-1 vectors, and RFC 4226's

Secret:  GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ   (Base32 of 12345678901234567890)

TOTP, 8 digits, Time 59          → 94287082   Time step 1 · 0x1
TOTP, 8 digits, Time 1111111109  → 07081804   Time step 37037036 · 0x23523EC
HOTP, 6 digits, Counter 0, 1, 2  → 755224, 287082, 359152

SHA-1 and a 30-second period throughout. The same secret as Hex, 3132333435363738393031323334353637383930, or as Text, 12345678901234567890, gives the same codes.

An OCRA challenge

Suite:    OCRA-1:HOTP-SHA1-6:QN08
Secret:   3132333435363738393031323334353637383930   (Hex)

Question 00000000  → 237653
Question 11111111  → 243178

Both are in RFC 6287's one-way challenge-response table. The suite is hashed as part of the message, so the same suite typed as ocra-1:hotp-sha1-6:qn08 gives 827128 for the first question instead.

The enrolment URI

otpauth://totp/Example%20Co:ada@example.com?secret=GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ&issuer=Example%20Co&algorithm=SHA1&digits=8&period=30

Issuer Example Co, Label ada@example.com, 8 digits. The issuer is written twice, as the prefix and as a parameter, as the format recommends, and algorithm is written even at its default. Pasting a URI into the box sets the fields from it.

Common problems

The code looks right but is rejected

TOTP depends on the clock of whatever shows the code. RFC 6238 recommends a server accept at most one step of delay, so a clock 30 seconds out is already at the edge; compare the time step under the code with the one the server logged. An HOTP server that has fallen behind or run ahead of the counter rejects codes until the two meet.

"1" is not a Base32 character

Base32 is A–Z and 2–7, so a 0, 1, 8 or 9 means the secret is hex or text, or an O or I was read as a digit. Set Secret Format to what the secret is. A wrong format that happens to decode gives a wrong code with no error at all.

RFC 6238's SHA-256 and SHA-512 codes do not match

The appendix says every row uses the 20-byte seed 12345678901234567890, but the reference code keys SHA-256 with a 32-byte seed and SHA-512 with a 64-byte one, and the table comes from the code. At 59 seconds SHA-256 gives 32247374 with the 20-byte key and the table's 46119246 with 12345678901234567890123456789012.

An authenticator shows the wrong code for a SHA-256 or 60-second account

Google's Key Uri Format page says Google Authenticator ignores the algorithm and period parameters, and digits on some platforms. An app that does enrols the account and then shows SHA-1, 30-second, 6-digit codes. Those are the format's defaults, and the safe choice when the app is not known.

Frequently asked questions

Why does the share link carry the secret?

Because the secret is the input the code is computed from; a link without it would open on the settings and no code. The part of an address after # is never sent to a server, but it does sit in browser history and in anything the link is pasted into, so do not share a link to a live account.

What is OCRA for?

Challenge and response. A server sends a question and the token answers with an HMAC over the suite, the question and, if the suite names them, a counter, a hashed PIN, session information and a time step. The page takes the PIN as typed and hashes it as the suite asks.

How long should the secret be?

RFC 4226 requires at least 128 bits and recommends 160, which is the 20 bytes the page generates for SHA-1, or 32 Base32 characters. For SHA-256 and SHA-512 it generates 32 and 64 bytes, the width of each hash. A Base32 secret of any size up to 512 bytes can also be drawn on Keygen.

Related tools

References