Comment une application d'authentification TOTP génère-t-elle ces codes à 6 chiffres ?
Réponse courte
TOTP (mot de passe à usage unique basé sur le temps) combine un secret partagé, établi à l'enrôlement, avec l'heure courante divisée en fenêtres fixes (généralement 30 secondes). Il exécute HMAC sur le compteur de pas de temps avec le secret, puis tronque le résultat en un code à 6 chiffres. L'application et le serveur détiennent tous deux le même secret et la même horloge, donc ils calculent indépendamment le même code — aucun appel réseau nécessaire. Le code change à chaque fenêtre.
Cette question vérifie si vous comprenez que les codes d'authentification sont calculés, pas livrés — il n'y a aucun message en transit à intercepter, ce qui rend TOTP plus fort que le SMS.
La configuration
Lors de l'enrôlement, le serveur génère un secret partagé aléatoire et le montre à votre application, généralement sous forme de QR code (l'URI otpauth://). Le serveur et votre application d'authentification détiennent maintenant le même secret. Rien de ce secret ne voyage plus jamais sur le réseau.
Générer un code
TOTP est construit directement sur HMAC (c'est HOTP avec un compteur basé sur le temps). L'heure Unix courante est divisée par une taille de pas — typiquement 30 secondes — pour produire une valeur de compteur. L'application calcule HMAC(secret, pas_de_temps), puis applique une troncature dynamique définie pour réduire ce condensé en un nombre à 6 chiffres. Comme l'entrée est la fenêtre temporelle, le code change toutes les 30 secondes. Le serveur, détenant le même secret et lisant la même horloge, calcule le code identique et compare. Pas d'aller-retour, pas de SMS, pas d'e-mail — ce qui élimine les risques de SIM-swap et d'interception qui affligent l'OTP par SMS.
Gérer la dérive d'horloge
Les téléphones et les serveurs n'ont pas d'horloges parfaitement synchronisées, donc les serveurs acceptent généralement le code des fenêtres temporelles adjacentes (un pas avant/après) pour tolérer une petite dérive, équilibrant l'utilisabilité et la fenêtre de devinette légèrement plus grande.
La limitation
TOTP n'est pas résistant à l'hameçonnage. Un proxy d'hameçonnage en temps réel peut présenter une fausse page de connexion, capturer à la fois le mot de passe et le code à 6 chiffres en direct, et les rejouer sur le vrai site dans la fenêtre de 30 secondes. C'est pourquoi FIDO2/passkeys — qui lient cryptographiquement l'identifiant à l'origine légitime — sont la référence absolue. TOTP reste bien meilleur que le SMS et un second facteur solide pour la plupart des applications.
Ce que recherchent les recruteurs
Le calcul HMAC secret-partagé-plus-temps, « calculé hors ligne, pas transmis », la rotation de 30 secondes et la tolérance à la dérive d'horloge, et l'honnêteté que TOTP peut quand même être hameçonné en temps réel tandis que le SMS est encore plus faible.
Questions de suivi probables
- Pourquoi le TOTP peut-il quand même être hameçonné en temps réel, et qu'est-ce qui corrige cela ?
- Comment les serveurs gèrent-ils la dérive d'horloge entre l'application et le serveur ?
- Pourquoi le secret partagé doit-il être protégé au repos des deux côtés ?