HOTP

HOTP (HMAC-based One-Time Password, RFC 4226) ist die zählerbasierte Variante von TOTP. Wo TOTP auf einer Uhr voranschreitet, schreitet HOTP auf einem gemeinsamen Zähler voran, den sowohl der Token als auch der Server mit jedem verwendeten Code inkrementieren. HOTP ist der kanonische Modus für YubiKey OATH, ältere Hardware-Tokens und einige Banking-Flows, bei denen der Server nicht auf Uhrsynchronisation vertrauen kann.

Canonical spec:RFC 4226, HOTP: An HMAC-Based One-Time Password Algorithm (2005).
URI scheme:Google Authenticator Key URI Format, the otpauth:// scheme every authenticator agrees on.
Sibling spec:TOTP (RFC 6238), time-based variant that builds on HOTP.

Was es ist

An HOTP enrolment QR is a URL in the otpauth:// scheme with hotp as the type. It carries the shared HMAC secret plus a counter value that both sides must keep in sync. Format:

otpauth://hotp/LABEL?secret=SECRET&issuer=ISSUER&counter=N&digits=N&algorithm=ALG

LABEL, Issuer:Account, URL-encoded. Example: YubiKey:alice@example.com.
secret, the shared HMAC key, Base32-encoded (RFC 4648 §6: A-Z, 2-7).
counter, starting counter value. Usually 0, but can be resumed from a known value when re-enrolling a token.
issuer, the service name shown in the authenticator app.
digits, 6 (default) or 8. RFC 4226 §5.3 specifies 6; 8 is a common extension.
algorithm, SHA1 in practice. RFC 4226 only defines SHA1; SHA256/512 variants are RFC 6238 extensions bolted on after-the-fact.

HOTP vs TOTP, wann welches verwenden

Eigenschaft	HOTP (RFC 4226)	TOTP (RFC 6238)
Schreitet fort auf	Zähler	Uhr (alle 30 s)
Erfordert Uhrsynchronisation	Nein	Ja, innerhalb ~30 s Abweichung
Resync bei Drift	Server akzeptiert nächste N Zählerwerte	Server akzeptiert ±1 Fenster
Typisches Deployment	YubiKey, ältere Hardware-Tokens, Offline-Banking	Jede Consumer-2FA, Google, Microsoft, 1Password, Authy
Zählerwiederverwend.	Katastrophal, leckt den Schlüssel mit der Zeit	N/A
Anfälligkeit bei Schlüsselleck	Alle zukünftigen Codes vorhersagbar	Alle vergangenen + zukünftigen Codes vorhersagbar

Kanonische Testvektoren

RFC 4226 Appendix D provides reference HOTP values for the secret 12345678901234567890 (20 bytes, Base32 GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ) with 6-digit output:

Counter	HOTP (6-digit)
`0`	`755224`
`1`	`287082`
`2`	`359152`
`3`	`969429`
`4`	`338314`
`5`	`254676`
`6`	`287922`
`7`	`162583`
`8`	`399871`
`9`	`520489`

Minimal QR payload for enrolment at counter 0:

otpauth://hotp/Example:test?secret=GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ&issuer=Example&counter=0

Live Base32-Schlüssel-Validator

Same validator as the TOTP page, HOTP secrets use the identical Base32 alphabet (RFC 4648 §6: A-Z, 2-7). Runs in your browser, no server round-trip.

Base32 HMAC-Schlüssel

Geben Sie einen Schlüssel zur Validierung ein.

Häufige Fallstricke

Zähler-Drift. Drückt der Nutzer den Token-Knopf, aber der Server erfasst den Code nicht (Netzausfall, Doppelklick), läuft der Token-Zähler dem Server-Zähler voraus. Server handhaben dies mit einem "Resync-Fenster", sie probieren die nächsten N Zählerwerte, bevor sie ablehnen. YubiKeys Standard-Fenster ist ~3; Hochsicherheits-Deployments engen es auf 1 ein.
Zählerwiederverwendung ist katastrophal. Akzeptieren Sie denselben Zählerwert nie zweimal. Tut der Server dies, kann ein Angreifer, der einen Code abgefangen hat, ihn später wiederholen. RFC 4226 §7.3 schreibt vor, dass der Server jeden Code am oder unter dem zuletzt akzeptierten Zähler ablehnt.
Zählerexport beim Backup. Authenticator-Apps, die HOTP-Einträge exportieren, exportieren manchmal den Schlüssel, aber nicht den aktuellen Zähler. Das Importieren in ein neues Gerät startet den Zähler bei 0 neu, nicht mit dem Server synchronisiert, Einschreibung effektiv defekt. TOTP ist immun; HOTP ist hier fragil.
Base32 ist nicht Base64. Gleiche Regel wie TOTP: Schlüssel mit 0, 1, 8, 9, Kleinbuchstaben, + oder / sind Base64 und werden von jedem RFC-konformen Authenticator abgelehnt.
Nur SHA1, in der Praxis. RFC 4226 definiert SHA1 als HMAC-Funktion. SHA256/SHA512 sind RFC-6238-TOTP-Erweiterungen; die meisten HOTP-Hardware-Tokens (einschließlich YubiKey OATH) implementieren sie nicht.
Stellenparameter oft ignoriert. Viele Hardware-Tokens sind auf 6 Stellen fest und kürzen stillschweigend, wenn man 8 verlangt. Vor dem Ausdrucken von QR-Karten mit dem Ziel-Hardware prüfen.
HOTP und TOTP nicht im selben QR mischen. Das URI-Schema verwendet das TYPE-Segment (hotp vs totp), um den Modus zu wechseln. Ein einziger Schlüssel kann beide betreiben, aber dann teilen sich beide Flows den Schlüssel, wird einer kompromittiert, versagen beide.

Authenticator-Kompatibilität

App / Token	HOTP	SHA256/512	8 Stellen	Hinweise
YubiKey Authenticator (iOS/Android/Desktop)	Ja	Ja	Ja	HOTP ist der kanonische YubiKey-OATH-Modus. Volle RFC-4226-Unterstützung.
Google Authenticator	Ja	Ignoriert (nur SHA1)	Ignoriert (nur 6)	Die De-facto-Baseline. Sicher für HOTP, aber nur mit 6-stelligem SHA1.
1Password	Ja	Ja	Ja	Vollständige RFC-Unterstützung. Zähler wird gespeichert und mit dem Eintrag exportiert.
Bitwarden	Ja	Ja	Ja	Vollständige RFC-Unterstützung.
Microsoft Authenticator	Ja	Ja	Ja	Vollständige RFC-Unterstützung.
Authy	Nein	,	,	HOTP in neueren Versionen entfernt. Nur TOTP.
Duo Mobile	Nein	,	,	Verwendet eigenen Push-Flow; nur TOTP als Fallback.
OATH-Hardware-Tokens (Feitian, Token2, etc.)	Ja	Variiert	Variiert	Kanonischer Hardware-HOTP-Markt; immer 6-stellig SHA1, sofern das Datenblatt nichts anderes sagt.

Siehe auch

/hotp-qr-code/, der HOTP-Generator mit Live-Zähler- und Base32-Validierung.
/standards/totp/, die zeitbasierte Variante (RFC 6238).
/totp-2fa-qr-code/, der TOTP-Generator.
/standards/, zurück zum Standards-Index.

Spec references verified Spec-Referenzen verifiziert am