Générateur de Code TOTP / 2FA

Générateur de Code TOTP / 2FA (RFC 6238)

Générez des mots de passe à usage unique basés sur le temps (TOTP) entièrement dans votre navigateur. Collez n'importe quel secret Base32 — celui qu'importent Google Authenticator, Authy, Microsoft Authenticator et 1Password — et voyez en direct le code à 6 chiffres, le code suivant, un anneau de compte à rebours, l'URI otpauth:// et un QR à scanner avec n'importe quelle app authenticator. Implémente RFC 6238 fidèlement, vérifié contre les six vecteurs officiels de test. Utile pour déboguer une configuration 2FA, valider la génération côté serveur ou disposer d'un authenticator entièrement hors-ligne.

Qu'est-ce que TOTP et en quoi diffère-t-il de HOTP ?

TOTP (Time-based One-Time Password, RFC 6238) génère un code de 6 à 8 chiffres qui change toutes les 30 secondes. C'est l'algorithme derrière Google Authenticator, Microsoft Authenticator, Authy, l'OTP intégré de 1Password, FreeOTP et des dizaines d'autres apps.

Il s'appuie sur HOTP (HMAC-based One-Time Password, RFC 4226) :
- HOTP utilise un compteur qui s'incrémente de 1 à chaque pression ou utilisation.
- TOTP utilise le temps Unix courant divisé par une période (30 s par défaut) comme compteur. À T = floor(time / 30), le code est identique pour toute personne partageant le même secret.

Les deux produisent un code en calculant HMAC(secret, compteur) puis en tronquant. TOTP est plus pratique car il n'exige pas de synchronisation entre client et serveur au-delà d'horloges raisonnablement précises (niveau NTP suffit).

Que calcule réellement cet outil ?

Exactement ce que spécifie RFC 6238 — vérifié contre les vecteurs officiels de l'Annexe B :

1. Décodage du secret Base32 en octets.
2. compteur = floor(unix_time / period), empaqueté en 8 octets big-endian.
3. HMAC sur ces 8 octets avec l'algorithme choisi (SHA-1, SHA-256 ou SHA-512) et le secret.
4. Troncature dynamique : les 4 bits finaux du HMAC servent d'offset, on lit 4 octets à partir de cet offset, on masque le bit haut.
5. Sortie : (bin % 10^digits), rempli de zéros à la largeur choisie.

Le HMAC utilise Web Crypto SubtleCrypto du navigateur — donc la cryptographie est native et auditée ; l'outil ne fait que câbler le protocole autour. Les six vecteurs RFC (T = 59, 1111111109, 1111111111, 1234567890, 2000000000, 20000000000) correspondent tous à la sortie attendue.

Comment ajouter un nouveau compte à Google Authenticator avec cet outil ?

Deux voies, selon le côté que vous contrôlez :

1. Vous avez un service qui a produit le secret (chaîne ou QR). Collez le secret Base32 dans le champ Secret, remplissez éventuellement 'Étiquette du compte' (ex. [email protected]) et 'Émetteur' (nom du site) pour que votre authenticator affiche un libellé clair. L'outil montre le code actuel pour comparer à l'étape de vérification du service.

2. Vous construisez un service et devez enrôler un utilisateur. Cliquez sur le dé pour générer un secret Base32 aléatoire de 20 octets, remplissez 'Étiquette du compte' et 'Émetteur'. Le QR encode une URI otpauth:// standard — l'utilisateur la scanne dans son app et produit immédiatement les codes correspondants. Copiez l'URI otpauth:// pour l'intégrer dans votre propre QR, ou téléchargez le PNG.

Dans les deux cas, les codes sont produits localement — jamais transmis — donc sûr même avec des secrets de production.

Est-il sûr de coller ici mon vrai secret 2FA ?

Techniquement oui — tout s'exécute dans le navigateur — mais un secret TOTP Base32 est l'identifiant maître de votre 2FA. Quiconque le connaît produit les mêmes codes. Traitez-le comme un mot de passe :

- Ne le collez pas dans des navigateurs non fiables (kiosques, postes partagés, navigateurs avec extensions douteuses).
- Inspectez DevTools → Réseau pour vérifier que le secret n'est jamais POST. C'est le cas — mais l'option de vérifier est là.
- Ne laissez pas la page ouverte là où quelqu'un peut lire la valeur.
- Pour la plupart des usages, l'intérêt est de tester ou récupérer depuis une sauvegarde (vous aviez noté le secret depuis l'écran de configuration et avez perdu l'app) ; pas comme remplacement quotidien d'une clé matérielle.

Un secret généré avec le dé est sans risque à partager — mais tout secret lié à un compte réel mérite la protection d'un mot de passe.

Quel est le format de l'URI otpauth:// ?

URI au style RFC utilisée par toutes les grandes apps authenticator :

otpauth://totp/Émetteur:[email protected]?secret=BASE32SECRET&issuer=Émetteur&algorithm=SHA1&digits=6&period=30

Champs :
- Le 'path' après totp/ est le libellé, en général 'Émetteur:Compte'. Le préfixe Émetteur est optionnel mais recommandé ; les deux occurrences doivent correspondre au paramètre issuer.
- secret : Base32, sans padding, majuscules préférées.
- issuer : nom lisible du service (URL-encoded).
- algorithm : SHA1 (défaut), SHA256 ou SHA512. Beaucoup d'apps ne supportent que SHA1.
- digits : 6 (défaut), 7 ou 8. Beaucoup d'apps ne supportent que 6.
- period : 30 (défaut) secondes. Certaines apps autorisent 60.

L'outil n'ajoute que les paramètres différents des valeurs par défaut pour garder l'URI propre. Les authenticators tolèrent des paramètres supplémentaires, mais la forme avec défauts omis est la plus portable.

Pourquoi le code de l'app authenticator est-il parfois décalé d'un pas ?

TOTP dépend d'horloges suffisamment proches des deux côtés. Si l'horloge de votre appareil dérive de plus de quelques secondes, le code généré utilise un time-step différent du serveur.

Comment services et clients gèrent cela :

- Les serveurs acceptent généralement le code précédent et le suivant en plus de l'actuel. Cela donne une fenêtre de ~±30 s.
- Les clients doivent utiliser NTP. Sous Android, activez 'Heure fournie par le réseau' ; sous iOS, 'Régler automatiquement' dans Date et heure ; sous Linux/macOS, systemd-timesyncd ou chrony maintiennent une précision en millisecondes.
- Authy et Google Authenticator proposent un bouton 'synchroniser l'heure' qui récupère l'heure réseau sans toucher à l'horloge système.

L'outil utilise l'horloge locale du système (Date.now() du navigateur). Si les deux horloges sont correctes, les codes correspondent ; si l'une dérive de plus de 60 s, vous verrez un décalage.

Quel algorithme et quel nombre de chiffres choisir ?

Défauts : SHA-1, 6 chiffres, période 30 s. Raisons d'en changer :

- SHA-1 : défaut universel. Toutes les apps le supportent. Recommandé sauf raison précise.
- SHA-256 / SHA-512 : HMAC plus solide. Utile quand le serveur émetteur et l'app cliente le supportent (Authy et 1Password oui ; certaines anciennes versions de Google Authenticator ne rendent pas SHA-256+ correctement).
- 6 chiffres : support universel, probabilité ~1 sur un million par essai.
- 7 / 8 chiffres : plus fort ; Yubico OATH les supporte ; beaucoup d'apps ne montrent que 6.
- Période 30 s : standard. 60 s réduit la cadence de nouveaux codes et facilite l'anti-replay ; 15 s est rare et casse certaines apps.

Pour la compatibilité, restez sur SHA-1 / 6 / 30. Pour des outils internes maîtrisant les deux côtés, SHA-256 / 6 / 30 est une amélioration raisonnable.

Où vont les données ? Peut-on l'utiliser hors-ligne ?

Votre secret ne quitte jamais le navigateur. Le générateur s'exécute entièrement côté client :

- HMAC est calculé via window.crypto.subtle — les mêmes primitives qu'utilise HTTPS. Aucune implémentation JS de SHA-1 n'est embarquée.
- Le rendu QR utilise la bibliothèque qrcode chargée une seule fois depuis un CDN public (cdn.jsdelivr.net). Ensuite, la page fonctionne hors-ligne — y compris la génération. Coupez le Wi-Fi et voyez-la tourner.
- Aucune analytique n'est faite sur vos entrées. Vérifiez-le via DevTools → Réseau pendant la frappe ; seules les ressources statiques apparaissent.
- 'Copier le code' et 'Copier l'URI' écrivent dans le presse-papiers local. 'Télécharger le QR' crée un PNG en mémoire et ouvre une boîte de dialogue locale.

Pour un usage hors-ligne maximal, chargez la page une fois sur une machine de confiance puis coupez le réseau. HMAC, décodage base32, rendu QR et presse-papiers continuent de fonctionner — utile pour des serveurs isolés ou des scénarios de récupération.

Fonctionnalités Clés

• Conforme à RFC 6238, vérifié contre les six vecteurs officiels
• HMAC via Web Crypto API natif du navigateur (aucune crypto JS embarquée)
• Supporte SHA-1, SHA-256 et SHA-512
• Chiffres configurables (6 / 7 / 8) et période (15 / 30 / 60 secondes)
• Affichage en direct du code courant et du suivant
• Anneau de compte à rebours animé montrant les secondes restantes
• Générateur de secret Base32 aléatoire de 20 octets via crypto.getRandomValues
• URI otpauth:// compatible Google Authenticator, Authy, 1Password, Microsoft Authenticator…
• Génère un QR proprement scanné par toutes les apps authenticator
• Bouton afficher/masquer pour le champ secret
• Copier le code ou l'URI otpauth en un clic
• Télécharger le QR au format PNG
• Champs étiquette de compte et émetteur pour des entrées lisibles
• 100 % côté client — votre secret ne quitte jamais le navigateur
• Fonctionne hors-ligne après le premier chargement