Utilisez un secret Base32 de test pour comparer réglages et codes. TOTP utilise l’horloge ; HOTP utilise le compteur indiqué.
Fonctionne localement dans votre navigateurComparez la valeur générée avec votre implémentation à l'aide d'un secret de test jetable. La dérive d'horloge, le stockage secret, les codes de récupération, les limites de débit et la récupération de compte nécessitent toujours des contrôles côté serveur.
Cet atelier transforme un secret Base32 en code à usage unique tel qu’une application d’authentification l’afficherait, avec l’algorithme, le nombre de chiffres et la période ou le compteur choisis. Il produit aussi l’URI de configuration otpauth:// que porterait un QR code.
Le HMAC est calculé dans l’onglet avec Web Crypto. L’outil n’envoie aucune requête pendant le calcul : le secret et le code généré restent dans le navigateur.
Le code est un HMAC sur le compteur utilisé : le compteur est signé avec le secret, le dernier octet de la signature sélectionne une fenêtre de 4 octets (troncature dynamique), et cette valeur est réduite modulo 10^chiffres. TOTP est la même fonction avec un compteur dérivé du temps Unix divisé par la période ; c’est pourquoi un code TOTP change seul, tandis qu’un code HOTP attend le compteur suivant.
L’outil correspond aux vecteurs de test publiés. Avec le secret du RFC, les compteurs HOTP 0 à 5 renvoient 755224, 287082, 359152, 969429, 338314 et 254676. Une horloge placée dans le pas de temps du RFC qui contient T=59 renvoie 94287082 avec SHA-1 et 8 chiffres, et les vecteurs plus tardifs (T=1111111109 et T=20000000000) renvoient 07081804 et 65353130.
L’examen rappelle les paramètres utilisés et deux obligations côté serveur : le compteur HOTP doit être incrémenté et enregistré de façon atomique par le vérificateur, et un secret de moins de 20 octets décodés est trop court pour la production. Une période différente de 30 secondes et SHA-256 ou SHA-512 sont valides, mais moins d’applications et de serveurs les acceptent.
Rien ici ne valide un code saisi à la main, ne mesure la dérive d’horloge du serveur et ne prouve que le secret est celui de votre compte. Comparez un code généré avec l’implémentation qui doit le vérifier, et considérez le parcours d’enrôlement de l’application d’authentification comme la référence.
L’URI suit le format de clé otpauth:// — secret, émetteur, algorithme (SHA1, SHA256 ou SHA512), chiffres, et période ou compteur — soit la chaîne qu’encode un QR code. Le secret est réécrit en Base32 sans espaces ni remplissage, et le libellé réunit l’émetteur et le nom du compte.
Le HMAC et l’URI sont produits dans l’onglet et l’outil n’envoie aucune requête : le secret et le code obtenu ne quittent pas le navigateur. Utilisez un secret de test jetable pour comparer les implémentations et conservez les graines de production dans les systèmes autorisés à les stocker.