Tester une intégration 2FA
Vous développez l’activation de la double authentification : générez un secret, importez l’URI dans votre application d’authentification et vérifiez que votre serveur accepte les mêmes codes.
Saisissez ou générez un secret Base32 de 160 bits, choisissez SHA-1, SHA-256 ou SHA-512, 6 ou 8 chiffres et la période : le code TOTP courant s’actualise avec un compte à rebours, l’URI otpauth:// est prête pour une application d’authentification et un code peut être vérifié avec une tolérance d’une période.
La clé partagée affichée sous le QR code d’activation (lettres A-Z et chiffres 2-7).
À encoder dans un QR code pour Google Authenticator, Microsoft Authenticator, Aegis ou 1Password.
Cet outil calcule les codes à usage unique TOTP, ceux qu’affichent Google Authenticator, Microsoft Authenticator ou 1Password, à partir d’un secret Base32. Il aide les développeurs qui intègrent la double authentification à tester leur implémentation, et les administrateurs qui doivent vérifier un secret ou préparer une URI d’enrôlement.
TOTP (RFC 6238) est une variante temporelle de HOTP (RFC 4226). On calcule un compteur T = floor(heure Unix / période), soit 30 secondes par défaut, puis HMAC(secret, T) avec SHA-1, SHA-256 ou SHA-512. Une « troncature dynamique » extrait 4 octets du HMAC à partir d’un décalage donné par les 4 derniers bits, et le résultat modulo 10^6 (ou 10^8) donne le code. Exemple de la RFC : avec le secret ASCII `12345678901234567890` (Base32 `GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ`), SHA-1 et l’instant 59 s, le code à 8 chiffres est 94287082.
L’outil décode le secret Base32 (ou en génère un de 160 bits, soit 32 caractères, avec crypto.getRandomValues), calcule le code courant via Web Crypto et l’actualise avec un compte à rebours jusqu’à la période suivante. Il construit l’URI `otpauth://totp/Émetteur:compte?secret=…&issuer=Émetteur&algorithm=SHA1&digits=6&period=30` que les applications importent, en général via un QR code. Pour la vérification, il compare le code saisi à ceux de la période précédente, courante et suivante, ce qui absorbe un léger décalage d’horloge.
Collez un secret Base32 ou générez-en un de 160 bits, puis choisissez l’algorithme (SHA-1, SHA-256, SHA-512), le nombre de chiffres (6 ou 8) et la période (30 s par défaut).
Le code courant s’affiche avec son compte à rebours ; indiquez l’émetteur et le nom du compte pour obtenir l’URI otpauth:// à importer dans une application.
Saisissez un code reçu : l’outil indique s’il correspond à la période courante, précédente ou suivante.
Vous développez l’activation de la double authentification : générez un secret, importez l’URI dans votre application d’authentification et vérifiez que votre serveur accepte les mêmes codes.
Comparez le code attendu pour un secret avec celui de l’application de l’utilisateur afin de distinguer un mauvais secret, un mauvais algorithme ou une horloge décalée.
Construisez l’URI otpauth:// avec le bon émetteur et le bon nom de compte, puis transformez-la en QR code pour l’équipe qui doit enregistrer le compte.
La cause la plus fréquente est une horloge décalée sur le téléphone ou le serveur : quelques dizaines de secondes suffisent à changer de période. Viennent ensuite un secret mal recopié et un algorithme, un nombre de chiffres ou une période différents de ceux attendus par le service. Activez l’heure automatique puis comparez le code de cet outil avec celui de l’application.
HOTP (RFC 4226) calcule le code à partir d’un compteur incrémenté à chaque utilisation, qui doit rester synchronisé entre client et serveur. TOTP (RFC 6238) remplace ce compteur par le temps divisé en périodes de 30 secondes, si bien que le code expire tout seul. La quasi-totalité des applications 2FA grand public utilisent TOTP.
Le service l’affiche au moment de l’activation de la 2FA, sous le QR code, souvent libellée « clé de configuration » ou « saisir le code manuellement ». Le QR code lui-même contient une URI otpauth:// dont le paramètre secret est cette clé en Base32. Une fois l’activation terminée, la plupart des services ne la montrent plus.
Ce n’est pas garanti : la documentation historique du format d’URI indique que Google Authenticator ignorait algorithm, digits et period, et générait alors des codes SHA-1 à 6 chiffres qui ne correspondent pas. Des applications comme 1Password ou Authy acceptent SHA-256 et SHA-512. Pour un service public, SHA-1 à 6 chiffres reste le choix compatible, et il est sûr dans le cadre HMAC.
Un code correspond à une période, 30 secondes par défaut. Beaucoup de serveurs, comme cet outil en vérification, acceptent aussi la période précédente et la suivante pour compenser la latence et le décalage d’horloge, soit une fenêtre effective d’environ 90 secondes.
Le secret permet de générer tous vos codes futurs : quiconque le possède dispose de votre second facteur. Ici, le calcul se fait uniquement dans votre navigateur avec Web Crypto et rien n’est transmis. Évitez néanmoins d’y coller le secret d’un compte de production réel sur un appareil partagé ; utilisez de préférence un secret de test.
Outils associés
Des outils similaires ou complémentaires à celui-ci.
Générez des jetons aléatoires sûrs de 8 à 256 octets en hexadécimal, Base64 ou Base64URL, avec préfixe optionnel.
Calculez un HMAC SHA-1, SHA-256, SHA-384 ou SHA-512 en hex ou Base64 et vérifiez une signature de webhook.
Générez des mots de passe forts et aléatoires de 8 à 128 caractères, avec l’entropie affichée.
Distinguez chiffrement, hachage, HMAC et dérivation de clé pour choisir le bon mécanisme selon le besoin : confidentialité, intégrité, authentification ou stockage de mots de passe.
Comprenez comment OAuth 2.0, PKCE, JWT, JWK et JWKS s’articulent sans les confondre : autorisation, jetons, clés publiques et vérification.
Apprenez à construire une CSP progressive, comprendre ses directives et éviter les politiques trop permissives ou cassantes.
Apprenez ce qu’un JWT contient, ce que sa signature prouve réellement et pourquoi décoder un jeton ne revient pas à le vérifier.