Le TOTP, expliqué : Comment votre téléphone connaît la poignée de main secrète

En une phrase

Le TOTP est un algorithme qui génère un code numérique temporaire et en constante évolution à partir d'un secret partagé et de l'heure actuelle, utilisé comme deuxième facteur pour se connecter.

Le problème que ça résout

On va pas se mentir : les mots de passe sont un mal nécessaire. On les oublie, on les réutilise, et les attaquants sont d'une efficacité déprimante pour les voler par phishing, via des brèches de bases de données, ou tout simplement en devinant. Se fier uniquement à un mot de passe, c'est comme fermer sa porte à clé mais laisser la clé sous le paillassson.

C'est là qu'interviennent l'authentification multifacteur (MFA), et sa variante la plus courante, l'authentification à deux facteurs (2FA). L'idée est de prouver votre identité avec plus que quelque chose que vous savez (un mot de passe). Vous avez aussi besoin de quelque chose que vous possédez (comme votre téléphone) ou quelque chose que vous êtes (comme votre empreinte digitale).

Au début, la 2FA consistait souvent à recevoir un code par SMS. C'était mieux que rien, mais c'est vulnérable aux attaques de type « SIM swapping », où un escroc convainc votre opérateur de transférer votre numéro sur son téléphone. Soudain, c'est lui qui reçoit vos codes 2FA. Pas top.

Place aux applications d'authentification. Au lieu de s'appuyer sur la sécurité chancelante du réseau téléphonique, une application sur votre appareil peut générer des codes localement. Mais comment votre appli Google Authenticator sait-elle générer un code pour votre compte GitHub ? Et comment votre Microsoft Authenticator sait-il comment parler à votre Dropbox ?

Elles parlent toutes le même langage, un standard ouvert : le TOTP, le mot de passe à usage unique basé sur le temps (Time-Based One-Time Password). Le TOTP est le héros méconnu qui découple votre second facteur de n'importe quelle entreprise. C'est un standard ouvert et interopérable qui permet à n'importe quelle application compatible de fonctionner avec n'importe quel service compatible. C'est l'évolution d'un standard plus ancien appelé HOTP (qui était basé sur un simple compteur), mais en utilisant le temps comme partie mobile, le TOTP est devenu beaucoup plus simple d'utilisation.

Comment ça marche sous le capot

Le TOTP a l'air magique. Vous scannez un code QR une seule fois, et pour le restant de vos jours, votre téléphone et un serveur à l'autre bout du monde peuvent se mettre d'accord sur le même numéro à six chiffres toutes les 30 secondes, sans jamais avoir à se reparler. Ce n'est pas de la magie, juste de la crypto sacrément intelligente.

Décortiquons la recette.

Le Secret Partagé : La Clé du Royaume

Tout commence par un secret. Quand vous activez la 2FA sur un service, le serveur génère une clé secrète aléatoire (par ex., 160 bits de pur hasard). Ce secret est la seule et unique chose que vous et le serveur devez connaître. Toute la sécurité du système repose sur le fait de le garder secret.

Bien sûr, une chaîne de 160 bits aléatoires n'est pas très pratique pour un humain. Alors pour nous, elle est encodée dans un format appelé Base32. Contrairement à son cousin le Base64, le Base32 utilise un alphabet plus petit, insensible à la casse et qui évite les caractères ambigus comme 1 et l, ou 0 et O. Ça rend possible (même si ça reste une tannée) de le taper à la main si vous ne pouvez pas scanner le code QR.

Un secret Base32 typique ressemble à ça : JBSWY3DPEHPK3PXPJBSWY3DPEHPK3PXP

Le moyen le plus courant de faire entrer ce secret dans votre application d'authentification est via un code QR qui encode une URI spéciale :

otpauth://totp/FlowingDev:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=FlowingDev

Votre application scanne ce code, enregistre l'émetteur (issuer, ici FlowingDev), le nom du compte (user@example.com), et surtout, le secret. La poignée de main est effectuée.

La Partie Mobile : Le Temps

Le "T" dans TOTP signifie "Time-Based" (basé sur le temps). C'est l'ingrédient crucial qui fait changer le code. Mais le système n'utilise pas l'heure exacte à la milliseconde près — ce serait impossible à synchroniser. À la place, il utilise un pas de temps discret.

La formule est simple :

TimeStep = floor(CurrentUnixTime / 30)

• CurrentUnixTime : Le nombre de secondes écoulées depuis le 1er janvier 1970 (l'Epoch Unix).
• / 30 : Le pas de temps est quasi universellement de 30 secondes.

Ce calcul produit un entier qui ne change que toutes les 30 secondes. À 10:00:00, le TimeStep vaut une certaine valeur T. À 10:00:29, il vaut toujours T. Mais à 10:00:30, il s'incrémente à T+1. Ce TimeStep est le « message » que nous allons authentifier.

La Magie Crypto : HMAC-SHA1

Maintenant, on combine le secret statique avec le pas de temps qui évolue. On fait ça en utilisant une primitive cryptographique appelée HMAC (Hash-based Message Authentication Code).

HMAC_Result = HMAC-SHA1(SecretKey, TimeStep)

Voyez le HMAC comme un moyen de créer une signature sécurisée. Il prend notre clé secrète et les données qu'on veut signer (le TimeStep) et les mouline ensemble en utilisant une fonction de hachage — dans ce cas, le vénérable SHA-1.

Le résultat est un hash de 20 octets (160 bits). C'est une longue chaîne hexadécimale qui est complètement unique à ce secret et ce pas de temps spécifiques. Changez un seul bit du secret ou attendez 30 secondes que le pas de temps change, et vous obtiendrez un hash radicalement différent.

Bien que SHA-1 ait des faiblesses connues pour d'autres usages comme la signature de certificats, il est toujours considéré comme parfaitement sûr lorsqu'il est utilisé dans la construction HMAC. De nombreuses implémentations modernes passent à HMAC-SHA256 ou HMAC-SHA512 par précaution.

La Troncation : Obtenir Six Chiffres

Une chaîne hexa de 20 octets n'est pas un code à six chiffres facile à utiliser. La dernière étape consiste à « tronquer dynamiquement » ce hash pour en faire un nombre qu'on peut réellement utiliser.

1. Trouver l'Offset : Regardez les 4 derniers bits (le quartet) du résultat HMAC de 20 octets. Cela nous donne un nombre entre 0 et 15. C'est notre offset.
2. Prendre 4 octets : En partant de cette position offset dans le hash de 20 octets, prenez les 4 octets (32 bits) suivants.
3. Supprimer le bit de poids fort : Prenez ce bloc de 32 bits et faites un ET logique (bitwise) avec 0x7FFFFFFF. Cela a pour effet de se débarrasser du tout premier bit, ce qui résout certains problèmes potentiels d'entiers signés vs. non signés et garantit que le résultat est toujours positif.
4. L'heure du Modulo ! Vous avez maintenant un grand entier de 31 bits. Pour le réduire à 6 chiffres, on lui applique un modulo 1 000 000 (10^6).
5. Compléter avec des zéros : Le résultat est votre code ! Si le nombre est, disons, 4521, on le complète avec des zéros au début pour obtenir 004521.

Et voilà ! Votre téléphone et le serveur effectuent exactement le même calcul. Lorsque vous entrez le code, le serveur compare son résultat avec le vôtre. Pour tenir compte d'un léger décalage d'horloge entre votre téléphone et le serveur, ce dernier va généralement vérifier le code pour le pas de temps actuel, celui d'avant, et celui d'après. Si l'un d'eux correspond, vous êtes connecté.

Histoires vécues

La prise de contrôle d'un compte GitHub qui n'a pas eu lieu

Un développeur, en pleine concentration, reçoit un e-mail qui ressemble exactement à un e-mail de GitHub, l'alertant d'un problème de sécurité. Dans un moment de distraction, il clique sur le lien, atterrit sur un clone au pixel près de la page de connexion de GitHub, et entre son nom d'utilisateur et son mot de passe. L'attaquant a maintenant ses identifiants. Le phisher essaie immédiatement de se connecter au vrai GitHub. Il entre le mot de passe volé... et se heurte à une demande : « Veuillez entrer votre code d'authentification à deux facteurs. » L'attaquant est complètement bloqué. Il n'a pas le téléphone du développeur et n'a aucun moyen de générer le code TOTP. Le développeur, pendant ce temps, reçoit un vrai e-mail de GitHub à propos d'une nouvelle connexion, réalise son erreur et change immédiatement son mot de passe.

Leçon : Le TOTP agit comme un pare-feu critique. Il transforme une faille de mot de passe potentiellement catastrophique en une tentative de connexion échouée et inoffensive.

L'urgence d'un accès hors ligne

Un ingénieur réseau est dans un avion pour une conférence. Trente minutes après le décollage, il doit vérifier un système critique en production. Il n'y a pas de Wi-Fi à bord et zéro réseau mobile. Une 2FA par SMS ou par notification push serait inutile. Mais son tableau de bord est sécurisé par TOTP. Il ouvre son ordinateur portable, affiche la page de connexion, ouvre l'application d'authentification sur son téléphone, et tape le code à six chiffres. L'application n'a besoin d'aucune connexion internet ; ses calculs sont autonomes, ne reposant que sur le secret partagé et l'horloge interne du téléphone. Il se connecte et résout le problème avant même que le personnel de bord ne commence le service des boissons.

Leçon : La capacité du TOTP à fonctionner complètement hors ligne le rend incroyablement robuste et fiable pour les accès critiques, où que vous soyez.

Le casse-tête de la migration multiplateforme... résolu

Un utilisateur Android de longue date décide de passer à un iPhone. Il ouvre Google Authenticator et est horrifié de constater qu'il n'y a pas de simple bouton « synchroniser sur mon nouveau téléphone ». Il a plus de 30 comptes configurés, et l'idée de devoir réinitialiser la 2FA pour chacun d'eux est un cauchemar. Mais il se souvient alors de sa politique de sécurité personnelle : pour chaque nouveau service, il a sauvegardé le code QR initial en tant que capture d'écran dans son gestionnaire de mots de passe chiffré. Il installe une nouvelle application d'authentification sur son iPhone, ouvre son gestionnaire de mots de passe, et un par un, re-scanne les codes QR sauvegardés. En dix minutes, les 30 comptes sont migrés et fonctionnent parfaitement.

Leçon : Le secret TOTP (sous forme de chaîne Base32 ou de code QR) est la vraie clé. Le fait d'être indépendant de toute application d'authentification en sauvegardant de manière sécurisée vos secrets vous en donne la pleine propriété et la portabilité.

Erreurs et pièges courants

• Traiter le secret à la légère. Le code QR ou la chaîne Base32 que l'on vous donne à la configuration est la clé secrète. Si un attaquant met la main dessus, il peut générer des codes valides pour toujours. Ne le capturez pas en image pour le laisser sur votre bureau, ne vous l'envoyez pas par e-mail et ne le stockez pas dans un fichier texte. Traitez-le comme un mot de passe maître.
• Oublier de sauvegarder les codes de récupération. Lorsque vous activez la 2FA, presque tous les services vous fourniront un jeu de codes de récupération à usage unique. IMPRIMEZ-LES. Gardez-les en lieu sûr (un vrai coffre-fort, ou au minimum, votre gestionnaire de mots de passe). Si vous perdez votre téléphone, ces codes sont votre seule porte de sortie pour récupérer votre compte sans passer par un processus de support pénible.
• Supposer que votre application d'authentification est sauvegardée. De nombreuses applications d'authentification simples (comme l'application Google Authenticator originale) ne stockent les secrets que sur cet unique appareil. Si le téléphone est perdu ou effacé, les secrets sont partis pour toujours. Utilisez une application qui offre une synchronisation cloud sécurisée et chiffrée (comme Authy ou 1Password) ou soyez rigoureux dans la sauvegarde manuelle de vos secrets.
• Ignorer la dérive de l'horloge. Le TOTP est basé sur le temps. Si l'horloge de votre téléphone a plus d'une minute ou deux d'écart avec l'heure réelle, les codes qu'il génère seront rejetés. Réglez toujours votre téléphone et votre ordinateur sur « Régler l'heure automatiquement ». C'est presque toujours le coupable lorsque des codes valides cessent soudainement de fonctionner.

Pourquoi vous devriez vous y intéresser

Si vous êtes un développeur qui construit un système avec des comptes utilisateurs, vous devriez implémenter la MFA, et le TOTP est la meilleure option, basée sur un standard ouvert, pour la 2FA via application. C'est plus sûr que le SMS et plus ouvert que les systèmes de notification push propriétaires. Comprendre comment générer un secret, créer une URI otpauth:// et valider un token entrant est une compétence fondamentale pour construire des applications sécurisées.

Même si vous n'implémentez jamais vous-même un système TOTP, vous en êtes un utilisateur sur des plateformes comme AWS, Cloudflare, GitHub et npm. Savoir comment la magie opère sous le capot vous donne les moyens de l'utiliser de manière plus sûre. Ça vous aide à comprendre l'importance de protéger le secret initial, de sauvegarder vos codes de récupération et de choisir la bonne application d'authentification pour vos besoins. Ça démystifie ce petit nombre à six chiffres qui se dresse entre vos données et les méchants.

Pour aller plus loin

• RFC 6238: Time-Based One-Time Password Algorithm — La spécification officielle pour le TOTP.
• RFC 4226: HMAC-Based One-Time Password Algorithm — La spécification pour le HOTP, la fondation sur laquelle le TOTP est construit.
• RFC 4648: The Base16, Base32, and Base64 Data Encodings — La spec qui définit l'encodage Base32 utilisé pour partager les secrets.
• Key URI Format · google/google-authenticator Wiki — Le standard de-facto pour l'URI otpauth:// utilisé dans les codes QR.
• Time-based One-time Password - Wikipedia — Un aperçu de haut niveau et historique de l'algorithme.