Comment fonctionne TOTP : les calculs derrière votre code à 6 chiffres

Ce qu'est réellement un code TOTP

Ouvrez votre application d'authentification et vous verrez un nombre à 6 chiffres dont la durée de vie de 30 secondes s'écoule. Ce nombre est un code TOTP : un mot de passe à usage unique basé sur le temps, standardisé dans la RFC 6238 comme extension du schéma antérieur basé sur HMAC, HOTP.

L'idée clé : le code n'est pas un mot de passe. C'est la preuve que vous détenez un secret partagé — une valeur installée sur votre appareil lors de la configuration initiale de la 2FA. Comme le code est dérivé de ce secret plus l'heure actuelle, il change toutes les 30 secondes et devient inutile pour quiconque l'aperçoit après que vous l'avez saisi.

Rien ne circule pour que cela fonctionne. Pas de SMS, pas de connexion au serveur de connexion, aucun réseau du tout. Votre application et le serveur effectuent le même calcul indépendamment, sur leurs propres horloges. Mêmes entrées, mêmes calculs, même code — voilà toute l'astuce.

Le secret partagé : là où tout commence

Lorsque vous activez l'authentification à deux facteurs (2FA) sur un compte, le serveur génère une clé secrète aléatoire — généralement 20 octets de hasard cryptographique. Cette unique chaîne de caractères est la racine de tout ce qui suit.

Le serveur vous la remet une seule fois, généralement sous forme de QR code. Ce qui ressemble à un motif de pixels n'est en réalité que du texte encodé : le secret lui-même, écrit en Base32 (lettres A–Z et chiffres 2–7), ainsi que le nom du compte et l'émetteur. Votre application d'authentification le scanne, le décode et stocke le secret localement.

À partir de ce moment, deux copies du même secret existent : une sur le serveur, une dans votre application. Aucune des deux n'est plus jamais envoyée sur le réseau. Chaque code futur est dérivé de cette valeur partagée — c'est pourquoi sa protection compte.

Une capture d'écran de ce QR code est une copie permanente de votre clé. Quiconque la voit peut générer des codes valides pour toujours. Scannez-le, puis supprimez-le.

Le pas de temps : un compteur mobile

TOTP n'utilise jamais l'horloge brute directement. À la place, votre application et le serveur prennent l'horodatage Unix actuel (secondes depuis 1970) et le divisent par 30, en ignorant le reste :

counter = floor(unix_time / 30)

Le résultat est un simple entier qui s'incrémente d'une unité toutes les 30 secondes. Au moment où j'écris ces lignes, ce compteur est un nombre énorme — mais l'application se soucie seulement que les deux côtés calculent la même valeur. Un compteur identique plus un secret identique donne le même code.

Pourquoi la dérive d'horloge casse les codes

Tout le mécanisme repose sur un accord. Si l'horloge de votre téléphone a 40 secondes de décalage, vous calculez le compteur N alors que le serveur est déjà sur N+1 — codes différents, erreur « code invalide », même si vous l'avez tapé parfaitement.

Les serveurs savent que les horloges dérivent, donc la plupart acceptent le code du pas de temps précédent ou suivant comme fenêtre de tolérance. Au-delà, resynchronisez l'horloge de votre appareil (réglez-la sur automatique).

HMAC : Mélanger le secret et le compteur

Au cœur de chaque code TOTP se trouve une seule fonction : HMAC-SHA1. HMAC signifie Hash-based Message Authentication Code, et son rôle ici est simple — mélanger deux entrées en une sortie imprévisible.

Les deux entrées :

• Le secret partagé — la clé, connue uniquement de votre téléphone et du serveur
• Le compteur temporel — le nombre qui change toutes les 30 secondes

Considérez HMAC comme un hash à clé. Un hash simple brouille les données de la même manière à chaque fois. HMAC les brouille différemment selon la clé. Donnez-lui le même secret avec le compteur 48291 et vous obtenez toujours le même résultat de 20 octets. Changez le compteur d'une unité, et la sortie se transforme en quelque chose de totalement sans rapport.

Fait crucial : le processus ne va que dans un sens. Voir des millions de sorties ne révèle à un attaquant rien d'utilisable sur le secret — c'est la propriété qui rend tout le schéma sûr.

Troncature : de 20 octets à 6 chiffres

HMAC-SHA-1 produit 20 octets — bien plus qu'un affichage ne peut raisonnablement montrer. TOTP les compresse grâce à la troncature dynamique :

1. Prenez le dernier quartet (les 4 bits de poids faible) de la sortie HMAC. Cela donne un nombre de 0 à 15.
2. Utilisez-le comme décalage : récupérez les 4 octets commençant à cette position dans la sortie.
3. Masquez le bit de poids fort de ces 4 octets, ce qui laisse un entier de 31 bits.

Cet entier est toujours trop grand pour être affiché, on le réduit donc modulo 1 000 000. Le reste — de 0 à 999 999 — devient le code, complété par des zéros jusqu'à 6 chiffres. Un reste de 4 207 s'affiche 042207.

On parle de troncature dynamique car le décalage provient des données elles-mêmes : chaque code échantillonne une tranche différente de la sortie HMAC.

Certains services utilisent des codes à 7 ou 8 chiffres, en réduisant modulo 10 000 000 ou 100 000 000 — mêmes calculs, espace de codes plus grand, plus difficile à deviner.

Pourquoi le code est sûr à saisir

Un code à 6 chiffres offre un million de valeurs possibles — modeste sur le papier. Ce qui le rend efficace, c'est que vous n'avez droit qu'à quelques tentatives. Les serveurs limitent le débit des tentatives de connexion et rejettent les échecs répétés, si bien qu'un attaquant ne peut pas énumérer les combinaisons. La limitation de débit, et non la longueur du code, constitue la véritable défense.

Chaque code est également éphémère. Il est lié à une fenêtre de 30 secondes et n'est accepté que brièvement autour de celle-ci, si bien qu'un code volé expire avant de pouvoir être réutilisé.

Enfin, voir un code ne révèle rien sur l'avenir. Le code est le résultat d'un calcul HMAC utilisant votre clé secrète. HMAC est une fonction à sens unique : connaissant la sortie, impossible de reconstituer l'entrée. Un attaquant qui aperçoit le code du jour ne peut pas déduire le secret, ni prédire le code de demain — parce qu'il ignore la valeur d'appariement sous-jacente du compteur.

Questions fréquentes et cas particuliers

Pourquoi les codes échouent

La cause la plus fréquente est la dérive d'horloge. L'horloge de votre téléphone et celle du serveur doivent rester dans la fenêtre autorisée ; un téléphone affichant une heure incorrecte produit donc des codes erronés. Solution : activez la synchronisation automatique de l'heure.

Un secret erroné échoue également en silence — cela se produit généralement lorsque le QR code a été scanné dans la configuration d'un autre compte. Enfin, les QR codes peuvent expirer : de nombreux services invalident le code d'inscription après une courte période ou après que vous avez dépassé l'écran, donc une ancienne capture d'écran ne fonctionnera pas.

Un code peut-il être réutilisé ?

Oui, techniquement — mais la plupart des serveurs rejettent un code déjà accepté au cours de la période temporelle actuelle. Cela bloque les attaquants qui aperçoivent un code et le rejouent quelques secondes plus tard.

Si vous perdez l'appareil

Le secret partagé réside uniquement sur votre appareil ; le perdre signifie donc perdre l'accès — sauf si vous avez enregistré des codes de récupération lors de la configuration de la 2FA. Conservez-les hors ligne. Chacun fonctionne généralement une seule fois.

Mise en pratique : le flux complet

Tout se réduit à un seul pipeline : secret partagé → compteur de temps → HMAC → troncature → 6 chiffres.

Un cycle de 30 secondes, du début à la fin :

• Pendant la configuration, vous scannez un QR code. Votre application stocke le secret partagé.
• À 12:04:30, l'application calcule le pas de temps actuel (environ 24 000 si l'on compte depuis l'époque Unix par tranches de 30 secondes).
• HMAC-SHA1 mélange le secret avec ce compteur, produisant 20 octets.
• La troncature sélectionne 4 de ces octets, les convertit en nombre et conserve les 6 derniers chiffres : disons, 482913.
• Vous le tapez. Le serveur, détenant le même secret, exécute le calcul identique—en tolérant un ou deux pas de décalage pour les différences d'horloge—and les codes correspondent.

Deux habitudes protègent toute la chaîne : traitez le QR code comme un mot de passe, et gardez l'horloge de votre appareil réglée sur automatique. Faites cela, et les mathématiques s'occupent du reste.

Les erreurs qui compromettent vos codes

Le calcul TOTP est solide ; c'est autour de lui que tout se perd. Voici les pièges les plus courants.

Stocker le secret ailleurs que dans l'application. Certains notent le secret Base32 dans un fichier texte ou un email « au cas où ». C'est équivalent à afficher votre mot de passe. Si vous voulez une copie de secours, utilisez une application de gestion de secrets chiffrée, jamais un document en clair.

Scanner un QR code déjà utilisé. Si vous activez la 2FA, désactivez-la, puis la réactivez, le serveur génère un nouveau secret. L'ancien, encore présent dans votre application, produit désormais des codes invalides. Résultat classique : l'app affiche des codes corrects, le serveur les refuse. Supprimez l'ancienne entrée et re-scannez.

Confondre les entrées. Un compte par site, pas deux. Scanner le QR code de votre compte personnel dans l'entrée destinée à votre compte professionnel donne des codes cohérents mais faux. Nommez clairement chaque entrée dans l'application.

Changer de téléphone sans transférer. Réinitialiser ou vendre un appareil efface le secret, sans récupération possible. Avant toute migration, utilisez la fonction d'exportation de l'application d'authentification, ou désactivez puis réactivez la 2FA depuis le nouveau téléphone.

Sauvegarder le QR code dans le cloud. Une capture d'écran synchronisée automatiquement vers un service de photos en ligne échappe à votre contrôle. Scannez, vérifiez que le premier code s'affiche, puis supprimez la capture — localement et dans la corbeille du service de synchronisation.

Ignorer les codes de récupération. Ils sont le seul plan B. Imprimez-les ou notez-les sur papier, dans un endroit distinct de l'appareil.