search

Found

info Aperçu

Calculez des codes HOTP HMAC-SHA-1 de 6, 7 ou 8 chiffres depuis un secret Base32 et un compteur, puis vérifiez si un code reçu tombe dans la fenêtre ±N.

📘 Mode d'emploi

  1. Saisissez le secret partagé en Base32 et la valeur du compteur
  2. Choisissez le nombre de chiffres (6/7/8) et la fenêtre de validation ±N
  3. Saisissez un code reçu pour vérifier la correspondance dans la fenêtre

Validateur de compteur HOTP (RFC 4226)

Base32 RFC 4648 (A-Z et 2-7). Les espaces et tirets sont ignorés.

Valeur C de RFC 4226 §5.3. Entier ≥ 0 ; HOTP avance par compteur, pas par tranche de temps.

Longueur du code. Google Authenticator utilise 6 chiffres, Yubico souvent 8.

Plage ±N (0-10) autour du compteur. RFC §7.4 : le serveur ne doit pas accepter C ≤ à un C déjà validé.

Si vous saisissez le code reçu, une correspondance dans la fenêtre est mise en vert.

HOTP au compteur courant

Codes dans la fenêtre

Décalage Compteur Code
Copié !

※ HOTP(K, C) = Truncate(HMAC-SHA-1(K, C)) mod 10^d. C est big-endian sur 8 octets ; les 4 bits finaux donnent un offset dont 4 octets (bit de poids fort à 0) servent au modulo.

※ Les serveurs tolèrent une dérive ±N et avancent C à la valeur correspondante + 1 après une authentification valide (RFC §7.4).

Article

Validateur de compteur HOTP (RFC 4226)|Testez les fenêtres de dérive ±N dans le navigateur

Calculez des codes HOTP HMAC-SHA-1 à partir d'un secret Base32 et d'un compteur, puis vérifiez si un code reçu tombe dans la fenêtre ±N. Reproduisez le comportement de la RFC 4226 à partir de vos seules saisies, sans serveur.

💡 À propos de cet outil

HOTP (RFC 4226) est un schéma de mot de passe à usage unique dont le facteur mobile est un compteur, et non l'horloge. Il équipe les jetons matériels comme la fente OATH-HOTP de Yubico ainsi que les codes par compteur qui complètent le SMS. Comme il ne réclame aucune synchronisation d'horloge, il convient aux appareils hors ligne et aux environnements où l'heure n'est pas fiable.

L'écueil récurrent de l'OTP par compteur est la dérive. Le compteur du jeton avance à chaque appui sur le bouton, mais celui du serveur n'avance qu'après une authentification réussie. Un utilisateur qui actionne le jeton à vide désaligne les deux et les codes ne passent plus. La RFC 4226 absorbe ce décalage par une fenêtre d'anticipation : le serveur recalcule les valeurs HOTP suivantes, les compare au code reçu et, en cas de correspondance, cale son compteur sur la valeur trouvée + 1.

Cet outil affiche d'un coup tous les codes de la fenêtre. La ligne du compteur courant est mise en évidence et la ligne correspondant au code reçu apparaît dans une autre couleur, ce qui permet de raisonner sur le décalage maximal qu'un serveur devrait accepter, ou de déboguer un jeton, sans lancer de backend. Il est volontairement distinct du TOTP fondé sur le temps : recourez à un outil TOTP lorsque le facteur mobile est l'horloge.

🧐 Questions fréquentes

En quoi HOTP diffère-t-il de TOTP ? Par le facteur mobile. HOTP utilise un compteur d'événements ; TOTP utilise le temps. Un code HOTP reste valable jusqu'à son utilisation, alors qu'un code TOTP expire seul après 30 à 60 secondes. Cet outil ne traite que HOTP.

Quel format pour le secret partagé ? Base32 selon RFC 4648 (A–Z et 2–7). Les espaces et tirets sont ignorés et le remplissage = final est facultatif. Tout caractère non valide en Base32 déclenche une erreur.

Que représente la fenêtre ±N ? La plage de codes vérifiée de part et d'autre du compteur courant. Un N plus grand tolère davantage de dérive mais élargit la surface d'attaque par force brute. La RFC §7.4 recommande de rejeter tout compteur inférieur ou égal à un compteur déjà accepté.

Quel nombre de chiffres choisir ? La longueur de l'OTP. Google Authenticator utilise 6 chiffres ; les jetons Yubico souvent 8. Alignez-vous sur la spécification de votre jeton.

Où s'effectue le calcul ? Entièrement dans votre navigateur via la Web Crypto API ; le secret partagé saisi n'est jamais envoyé à un serveur.

📚 Pourquoi la troncature dynamique existe

Le cœur de HOTP est la troncature dynamique. Les 4 derniers bits de la sortie HMAC-SHA-1 (20 octets) se lisent comme un décalage ; quatre octets sont prélevés à partir de là et le bit de poids fort est mis à 0 pour former un entier de 31 bits avant le modulo. Ce masquage du bit fort n'est pas cosmétique : il évite que certaines implémentations traitent la tranche comme un entier signé et divergent sur le résultat. La RFC 4226, annexe D, fige des vecteurs de test — le secret 12345678901234567890 donne 755224 au compteur 0 et 287082 au compteur 1 — qui permettent de vérifier chaque étape. Parce que la procédure est figée à ce point, un jeton et un serveur de fabricants différents aboutissent au même code, et le TOTP ultérieur a simplement réemployé la même troncature au-dessus d'un compteur dérivé du temps.