HOTP

HOTP (HMAC-based One-Time Password, RFC 4226) est la variante basée sur compteur de TOTP. Là où TOTP avance sur une horloge, HOTP avance sur un compteur partagé que le token et le serveur incrémentent à chaque code utilisé. HOTP est le mode canonique pour YubiKey OATH, les tokens matériels hérités et quelques flux bancaires où le serveur ne peut pas compter sur la synchronisation d'horloge.

Ce que c'est

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, quand utiliser lequel

Vecteurs de test canoniques

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

Minimal QR payload for enrolment at counter 0:

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

Validateur de secret Base32 en direct

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.

Pièges courants

• Désynchronisation du compteur. Si l'utilisateur appuie sur le bouton du token mais que le serveur n'enregistre pas le code (coupure réseau, double-clic), le compteur du token dépasse celui du serveur. Les serveurs gèrent cela avec une "fenêtre de resynchronisation", ils essaient les N prochaines valeurs de compteur avant de rejeter. La fenêtre par défaut de YubiKey est ~3 ; les déploiements haute sécurité la réduisent à 1.
• La réutilisation du compteur est catastrophique. N'acceptez jamais deux fois la même valeur de compteur. Si le serveur le fait, un attaquant qui a intercepté un code peut le rejouer plus tard. RFC 4226 §7.3 impose que le serveur refuse tout code égal ou inférieur au dernier compteur accepté.
• Export du compteur lors de la sauvegarde. Les apps d'authentification qui exportent les entrées HOTP exportent parfois le secret mais pas le compteur actuel. L'import dans un nouvel appareil repart du compteur à 0, désynchronisé du serveur, enrôlement effectivement cassé. TOTP est immunisé ; HOTP est fragile ici.
• Base32 n'est pas Base64. Même règle que TOTP : les secrets avec 0, 1, 8, 9, lettres minuscules, + ou / sont en Base64 et seront rejetés par tout authentificateur conforme RFC.
• SHA1 uniquement, en pratique. RFC 4226 définit SHA1 comme la fonction HMAC. SHA256/SHA512 sont des extensions de l'ère TOTP RFC 6238 ; la plupart des tokens matériels HOTP (dont YubiKey OATH) ne les implémentent pas.
• Le paramètre digits souvent ignoré. Beaucoup de tokens matériels sont fixés à 6 chiffres et tronquent silencieusement si vous demandez 8. Vérifiez avec votre matériel cible avant que le QR n'atteigne les cartes imprimées.
• Ne mélangez pas HOTP et TOTP dans le même QR. Le schéma URI utilise le segment TYPE (hotp vs totp) pour changer de mode. Un unique secret peut alimenter les deux, mais cela signifie que les deux flux partagent le secret, si l'un est compromis, les deux échouent.

Compatibilité des apps d'authentification

Voir aussi

• /hotp-qr-code/, le générateur HOTP avec validation compteur + Base32 en direct.
• /standards/totp/, le sibling basé sur le temps (RFC 6238).
• /totp-2fa-qr-code/, le générateur TOTP.
• /standards/, retour à l'index des standards.

Spec references verified Références de spec vérifiées le