Compte d’authentification à deux facteurs
Générez un secret et son QR code pour activer la validation en deux étapes, affichez le code TOTP ou HOTP que montrerait Google Authenticator, Microsoft Authenticator ou Authy, et vérifiez si un code est valide. Les codes sont calculés dans votre navigateur et le secret n’est pas partagé dans le lien.
Code

Saisissez un secret valide pour afficher le code.

QR code pour l’application
Vérifier un code

Vérifiez un code comme le ferait le serveur : le code actuel est accepté, ainsi que jusqu’à 2 pas avant ou après, pour tolérer les horloges décalées.

Comment ça marche

TOTP (Time-based One-Time Password, RFC 6238) est l’algorithme derrière les codes à six chiffres de Google Authenticator, Microsoft Authenticator, Authy ou 1Password. Le service et votre téléphone partagent un secret ; toutes les 30 secondes, les deux calculent un HMAC du secret avec l’heure actuelle divisée en pas, le tronquent à six chiffres et comparent le résultat. Comme personne ne transmet le code avant que vous le saisissiez, cela fonctionne même si le téléphone n’a pas de connexion.

HOTP (RFC 4226) est l’algorithme de base : au lieu de l’heure, il utilise un compteur qui avance chaque fois qu’un code est demandé. TOTP est HOTP dont le compteur est remplacé par le nombre de périodes écoulées depuis 1970. Le secret est écrit en Base32 et transmis dans une URI otpauth:// affichée sous forme de QR code lors de l’activation de la validation en deux étapes.

L’outil génère des secrets avec le générateur cryptographique du navigateur, calcule le code actuel, le précédent et le suivant, construit l’URI et son QR code, lit une URI existante et vérifie un code avec la même tolérance d’horloge que les serveurs. Le secret ne quitte jamais votre navigateur et n’est pas inclus dans le lien de partage.

Exemples

GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ · SHA1 · 8 · T = 59 s94287082Vecteur de test de la RFC 6238. Le secret est le texte ASCII 12345678901234567890 encodé en Base32 ; à 59 secondes après l’époque Unix, le pas vaut 1 et le code à huit chiffres doit être exactement celui-ci.
GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ · SHA1 · 8 · T = 1111111109 s07081804Un autre vecteur de la RFC 6238, utile pour vérifier que votre implémentation ne perd pas les zéros initiaux : le code est une suite de chiffres de longueur fixe, pas un entier.
HOTP · GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ · contador 0755224Premier vecteur de la RFC 4226 à six chiffres. Avec le compteur à 1, le code devient 287082.
otpauth://totp/Ejemplo:ana%40example.com?secret=JBSWY3DPEHPK3PXP&issuer=EjemploTOTP · SHA1 · 6 · 30 sLe format Key URI défini par Google Authenticator et adopté par les autres applications. Si algorithm, digits et period sont absents, SHA1, 6 et 30 sont supposés ; c’est pourquoi la plupart des QR codes ne contiennent que le secret et l’émetteur.

Cas d'usage

  • Tester l’activation de la 2FA de votre application : générer un secret, scanner le QR code avec le téléphone et vérifier que le serveur accepte le même code que celui affiché par l’application.
  • Déboguer pourquoi un serveur rejette des codes valides : voir s’ils correspondent au pas précédent ou suivant révèle une horloge décalée.
  • Valider votre propre implémentation de TOTP ou HOTP avec les vecteurs de test des RFC 6238 et 4226.
  • Lire une URI otpauth:// exportée d’une autre application pour vérifier quel algorithme, combien de chiffres et quelle période le compte utilise.
  • Charger dans une deuxième application ou un gestionnaire de mots de passe un compte de test dont vous avez déjà le secret en Base32.

Questions fréquentes

Pourquoi le serveur rejette-t-il un code que l’application affiche comme valide ?

C’est presque toujours l’horloge. TOTP exige que le téléphone et le serveur soient d’accord sur l’heure : avec 30 secondes d’écart, ils calculent déjà des pas différents. C’est pourquoi les serveurs acceptent un ou deux pas de chaque côté. Si le code correspond au pas précédent ou suivant, synchronisez l’heure du serveur avec NTP et activez l’heure automatique sur le téléphone.

Est-il sûr de générer ici le secret d’un vrai compte ?

Le secret est généré avec crypto.getRandomValues et ne quitte pas votre navigateur, mais en production il doit être généré et stocké par le serveur qui vérifiera les codes. Cet outil sert à tester et à déboguer. Traitez tout secret réel comme un mot de passe : quiconque le possède peut générer vos codes pour toujours.

Faut-il utiliser SHA-256, 8 chiffres ou 60 secondes ?

En théorie, ils sont plus robustes, mais plusieurs applications, dont certaines versions de Google Authenticator, ignorent ces paramètres et calculent toujours SHA-1 avec 6 chiffres toutes les 30 secondes, si bien que l’utilisateur voit des codes que le serveur rejette. SHA-1 reste sûr en tant que HMAC. Par souci de compatibilité, presque tous les services utilisent les valeurs par défaut.

Quelle longueur doit avoir le secret ?

La RFC 4226 exige au moins 128 bits et en recommande 160, soit 32 caractères en Base32. De nombreux services utilisent 80 bits (16 caractères) et les applications les acceptent quand même. Cet outil génère 160 bits.

TOTP protège-t-il contre le phishing ?

Pas entièrement. C’est bien mieux que les SMS, qui peuvent être interceptés ou volés par un échange de carte SIM, mais un faux site peut vous demander le code et l’utiliser sur le vrai dans les mêmes 30 secondes. Les clés de sécurité FIDO2 et les passkeys sont liées au domaine et résistent à cette attaque.

Que se passe-t-il si je perds mon téléphone ?

Sans le secret, il est impossible de calculer les codes. C’est pourquoi les services fournissent des codes de récupération lors de l’activation de la 2FA : conservez-les ailleurs que sur le téléphone. Certaines applications permettent de sauvegarder les comptes chiffrés dans le cloud ou de les exporter en QR code pour les transférer vers un autre appareil.