Qu'est-ce que TOTP ?

TOTP en bref#

TOTP (Time-based One-Time Password) est un algorithme qui produit des mots de passe à usage unique à partir de deux ingrédients : un secret partagé entre l’utilisateur et le serveur, et l’heure courante. Toutes les trente secondes, un nouveau code apparaît ; le serveur, qui connaît le même secret et la même heure, calcule le même code et peut donc le vérifier.

C’est le mécanisme des applications d’authentification comme Google Authenticator, Microsoft Authenticator, FreeOTP ou les gestionnaires de mots de passe qui affichent des codes à six chiffres. Quand un site vous demande de « scanner ce QR code avec votre application », puis de recopier le code affiché, vous activez TOTP.

TOTP est décrit par la RFC 6238, publiée en 2011 à l’initiative de l’OATH (Initiative for Open Authentication), un consortium qui a aussi produit son prédécesseur, HOTP.

Pourquoi TOTP existe#

Un mot de passe seul ne suffit pas à protéger un compte : il fuit, se devine ou se réutilise. On ajoute donc un second facteur, quelque chose que l’utilisateur possède. Avant TOTP, ce facteur prenait souvent la forme d’un boîtier propriétaire fourni par un éditeur, ou d’un code envoyé par SMS, qui dépend du réseau mobile et reste exposé au détournement de ligne.

TOTP apporte :

• un standard ouvert : n’importe quelle application conforme fonctionne avec n’importe quel serveur conforme ;
• un fonctionnement hors ligne : le téléphone n’a besoin ni de réseau ni de recevoir un message, seulement d’une horloge juste ;
• un coût nul : une application gratuite remplace le boîtier matériel.

Les acteurs#

Le secret est le seul lien entre les deux côtés. Aucun échange réseau n’a lieu entre l’application et le serveur : chacun calcule de son côté, et l’utilisateur recopie le résultat.

De HOTP à TOTP#

TOTP est une variante de HOTP (HMAC-based One-Time Password, RFC 4226). HOTP calcule un code à partir du secret et d’un compteur incrémenté à chaque utilisation. Le procédé fonctionne, mais le compteur du jeton et celui du serveur se désynchronisent dès que l’utilisateur génère des codes sans les utiliser.

TOTP remplace le compteur par le temps, découpé en intervalles fixes. Il n’y a plus rien à synchroniser, sinon les horloges, ce que les téléphones font déjà automatiquement. Un code TOTP a aussi une durée de vie courte, ce qui limite l’intérêt de le voler.

Le calcul d’un code#

Le calcul tient en quatre étapes.

1. Compter les intervalles. On divise l’heure Unix (secondes écoulées depuis le 1er janvier 1970) par la durée d’un intervalle, 30 secondes par défaut, et on garde la partie entière : c’est la valeur T.
2. Calculer un HMAC. On calcule HMAC-SHA-1(secret, T), où T est codé sur 8 octets. La RFC 6238 autorise aussi HMAC-SHA-256 et HMAC-SHA-512.
3. Tronquer. Les 4 bits de poids faible du dernier octet du HMAC donnent une position ; on lit 4 octets à partir de cette position et on obtient un entier de 31 bits (c’est la « troncature dynamique » de HOTP).
4. Garder les derniers chiffres. On prend ce nombre modulo 10⁶ pour un code à 6 chiffres, ou 10⁸ pour 8 chiffres.

Par exemple, avec le secret de démonstration JBSWY3DPEHPK3PXP (en Base32), le 27 septembre 2026 à 08:00:00 UTC :

heure Unix  = 1790496000
T           = 1790496000 / 30 = 59683200
HMAC-SHA-1  = HMAC(secret, 0x00000000038EB180)
code        = 945618 (6 chiffres)

Tant que l’on reste dans le même intervalle de 30 secondes, l’application et le serveur obtiennent 945618. À 08:00:30, T passe à 59683201 et le code change.

HMAC-SHA-1 peut surprendre, puisque SHA-1 est déconseillé pour les signatures. La sécurité de HMAC ne repose cependant pas sur la résistance aux collisions de la fonction de hachage, et HMAC-SHA-1 reste considéré comme sûr dans cet usage. C’est aussi l’algorithme que toutes les applications prennent en charge.

L’enrôlement#

Avant le premier code, le serveur et l’application doivent partager le secret. C’est l’enrôlement, qui se fait en général par QR code.

Le QR code contient une URI au format otpauth://. Ce format n’est pas défini par une RFC : il a été popularisé par Google Authenticator et repris par la plupart des applications.

otpauth://totp/TOSIAM:claire.martin?secret=JBSWY3DPEHPK3PXP&issuer=TOSIAM&algorithm=SHA1&digits=6&period=30

Demander un premier code avant d’enregistrer le secret confirme que l’application a bien lu le QR code et que son horloge est juste. Sans cette étape, un utilisateur pourrait activer TOTP avec une application mal configurée et se retrouver bloqué à la connexion suivante.

La vérification#

À la connexion, le serveur calcule le code attendu et le compare à celui que saisit l’utilisateur. Deux précautions complètent cette comparaison.

La fenêtre de tolérance. L’horloge du téléphone peut dériver, et l’utilisateur met quelques secondes à recopier le code. Le serveur accepte donc aussi les codes des intervalles voisins. La RFC 6238 recommande de n’accepter au plus qu’un intervalle de décalage en arrière pour absorber le délai de transmission : une fenêtre trop large multiplie les codes valides à un instant donné.

L’usage unique. Un code accepté ne doit plus l’être une seconde fois, même s’il est encore dans sa fenêtre de validité. La RFC 6238 l’impose au vérificateur : c’est ce qui empêche de rejouer un code observé par-dessus l’épaule ou intercepté.

Les limites de TOTP#

• Le secret est partagé. Contrairement à une passkey, le serveur détient une copie du secret : une fuite de la base des secrets permet de générer les codes de tous les utilisateurs.
• L’hameçonnage en temps réel reste possible. Un faux site peut demander le code et le soumettre immédiatement au vrai site, dans les trente secondes. TOTP protège contre la réutilisation d’un mot de passe volé, pas contre un relais actif.
• Le secret peut être copié. Un QR code photographié ou une sauvegarde d’application exportée suffisent à dupliquer le générateur, sans que l’utilisateur perde le sien.
• La perte du téléphone bloque l’accès si aucune solution de secours n’a été prévue.

Bonnes pratiques#

• Générez un secret aléatoire d’au moins 128 bits ; la RFC 4226 recommande 160 bits (20 octets) pour HMAC-SHA-1.
• Protégez les secrets au repos comme des mots de passe en clair, puisque c’en sont : accès restreint à l’annuaire, sauvegardes chiffrées.
• Gardez une fenêtre de tolérance étroite et refusez tout code déjà utilisé.
• Limitez le nombre d’essais : six chiffres ne font qu’un million de combinaisons.
• Faites vérifier un premier code avant d’activer TOTP, et fournissez des codes de récupération à usage unique.
• Pour les comptes sensibles, préférez les passkeys, qui résistent à l’hameçonnage.

TOTP dans TOSIAM#

Dans un graphe d’authentification, TOSIAM met en œuvre TOTP par une série de nœuds, décrits dans Nœuds : MFA TOTP. Le calcul suit la RFC 6238 et utilise par défaut les valeurs les plus compatibles : 6 chiffres, intervalle de 30 secondes, HMAC-SHA-1. HMAC-SHA-256, HMAC-SHA-512 et une longueur jusqu’à 8 chiffres sont aussi configurables.

Enrôlement. Le parcours type enchaîne quatre nœuds :

1. TotpSecretGeneratorNode génère un secret aléatoire de 20 octets et l’URI otpauth:// correspondante, avec TOSIAM comme émetteur par défaut ;
2. TotpQrCodeDisplayNode transmet cette URI à l’interface de connexion, qui l’affiche sous forme de QR code ;
3. TotpVerifierNode, réglé pour lire le secret en cours d’enrôlement (secretSource à sharedState), vérifie le premier code saisi ;
4. TotpEnrollCommitNode enregistre alors le secret dans le profil LDAP de l’utilisateur (attribut oathDeviceProfiles par défaut) et crée dix codes de récupération.

TotpRecoveryCodesDisplayNode affiche ensuite ces codes à l’utilisateur, puis les efface de l’état du graphe. TOSIAM n’en conserve qu’une empreinte salée (PBKDF2 avec HMAC-SHA-256) : un code perdu ne peut pas être réaffiché.

Vérification. TotpVerifierNode lit le secret dans le profil et compare le code saisi à ceux de l’intervalle courant et des intervalles voisins. Sa propriété stepsInWindow vaut 1 par défaut : un intervalle de part et d’autre, soit 30 secondes de tolérance. Chaque code accepté est réservé dans le stockage de jetons partagé par les serveurs (CTS, Core Token Service), si bien qu’il ne peut pas servir deux fois. Après trois échecs par défaut (retryLimit), le nœud prend la sortie exceeded, que le graphe peut relier à un verrouillage du compte. Ces échecs sont comptés par utilisateur, et non par session, sur une fenêtre de 15 minutes.

Secours et choix de la méthode. RecoveryCodeVerifyNode accepte un code de récupération à la place du code TOTP ; il distingue un code invalide (false) d’un code déjà utilisé (consumed). MfaEnrollmentCheckNode et MfaChoiceNode permettent de proposer à l’utilisateur les méthodes auxquelles il est inscrit : TOTP, code par SMS ou e-mail, passkey.

Chaînes legacy. Les chaînes d’authentification antérieures aux graphes disposent de modules OATH, qui prennent en charge HOTP et TOTP. Les appareils OATH d’un utilisateur sont exposés par l’API REST sur /realms/{realm}/users/{user}/devices/2fa/oath.

Pour aller plus loin#

• RFC 6238, TOTP: Time-Based One-Time Password Algorithm
• RFC 4226, HOTP: An HMAC-Based One-Time Password Algorithm
• RFC 4648, l’encodage Base32 utilisé pour transmettre le secret