Le TOTP est le second facteur le plus déployé sur les accès distants : VPN, bureau à distance, bastion d'administration. Il apporte un gain réel contre le rejeu de mots de passe fuités et contre le credential stuffing. Il ne protège en revanche ni du relais en temps réel, ni du vol de session — deux scénarios qui constituent aujourd'hui l'essentiel des intrusions par accès distant.
Ce que le TOTP protège sur un accès distant
Un code temporaire dérivé d'un secret partagé et de l'horloge présente trois propriétés utiles :
- Il change toutes les trente secondes, ce qui rend inopérant le rejeu d'un code capté hier.
- Il ne transite pas par le réseau opérateur, contrairement au SMS : ni SIM swapping, ni interception de signalisation.
- Il fonctionne hors ligne, ce qui compte pour les astreintes et les interventions en site isolé.
Sur un concentrateur VPN exposé à Internet, ces propriétés éliminent la classe d'attaques la plus volumineuse : les tentatives automatisées reposant sur des identifiants issus de fuites. C'est un bénéfice concret, et c'est la raison pour laquelle le TOTP reste largement recommandé face au mot de passe seul.
Ce qu'il ne protège pas
Le TOTP produit une valeur que l'utilisateur recopie. Cette valeur n'a aucune connaissance du domaine ni du service auquel elle est destinée.
| Scénario | Le TOTP aide-t-il ? | Explication |
|---|---|---|
| Mot de passe fuité rejoué | Oui | le code manque à l'attaquant |
| Recherche exhaustive du code | Oui, si limitation des tentatives | six chiffres exigent un plafonnement strict |
| Page contrefaite avec relais immédiat | Non | le code est valide plusieurs dizaines de secondes |
| Proxy inverse (AiTM) | Non | l'attaquant récupère la session, pas le code |
| Vol du jeton de session après connexion | Non | l'authentification n'est plus sollicitée |
| Fuite de la base de secrets d'amorçage | Non | l'attaquant génère lui-même les codes |
| Appareil de l'utilisateur compromis | Non | le secret est lisible localement |
Les deux dernières lignes sont sous-estimées. Un secret TOTP est un secret partagé : il existe en double, chez vous et sur le téléphone de l'utilisateur. Contrairement à une clé privée FIDO2, il est extractible, sauvegardable et parfois synchronisé dans un service tiers. Votre base de secrets d'amorçage est donc un actif de la même criticité qu'une base de mots de passe.
Les décisions de configuration qui comptent vraiment
La fenêtre de tolérance. Pour absorber les décalages d'horloge, la plupart des implémentations acceptent le code précédent et le suivant. Chaque pas supplémentaire allonge d'autant la durée pendant laquelle un code capté reste utilisable. Une tolérance de plus ou moins un pas est généralement le maximum défendable.
La limitation des tentatives. Six chiffres offrent un espace réduit. Sans plafonnement strict par compte et par source, associé à un verrouillage temporaire, la recherche exhaustive redevient réaliste sur une fenêtre de validité étendue.
Le stockage des secrets d'amorçage. Ils doivent être chiffrés au repos avec une clé distincte de celle de la base applicative, et ne jamais apparaître dans les journaux ni les sauvegardes en clair.
Le parcours de réenrôlement. C'est le point faible opérationnel : « j'ai changé de téléphone » mène presque toujours au support, et le support devient alors le facteur d'authentification réel.
La liaison à la session. Sur un accès distant, exiger le code une fois puis maintenir une session de plusieurs heures revient à protéger la porte et à laisser la fenêtre ouverte.
Le cas particulier des accès à privilèges
Sur un bastion d'administration, le calcul de risque change : la valeur de la cible justifie un attaquant patient, préparé, capable de monter une infrastructure de relais dédiée. Le TOTP y est alors sous-dimensionné, pour une raison simple : il fournit une valeur relayable à l'utilisateur, qui la saisit sur une page qu'il ne vérifie pas.
Trois évolutions, par ordre de coût croissant :
| Évolution | Ce qu'elle apporte | Coût principal |
|---|---|---|
| Passkey ou clé physique en facteur principal | supprime le relais grâce à la liaison à l'origine | inscription, logistique, parcours de secours |
| Sessions courtes et réauthentification | réduit la valeur d'un jeton volé | friction sur les interventions longues |
| Validation portant sur l'action administrative | preuve fraîche au moment de l'opération critique | intégration applicative |
La troisième ligne relève d'une logique Zero Trust au sens du NIST SP 800-207 : ne jamais faire confiance, toujours vérifier — y compris au sein d'une session déjà ouverte. C'est le terrain de l'authentification cognitive, qui demande une preuve d'intention humaine consciente au moment d'une action à fort impact, plutôt qu'un code au moment de la connexion.
TOTP et SMS-OTP : une nuance à ne pas perdre
Les deux transmettent une valeur relayable, mais ils ne sont pas équivalents. Le NIST SP 800-63B classe l'OTP par SMS ou par voix comme « restricted », c'est-à-dire d'usage déconseillé, en raison de la dépendance au réseau opérateur et des risques de détournement de numéro. Le TOTP échappe à cette catégorie précise. Sur un accès distant, migrer du SMS vers le TOTP est un progrès ; s'y arrêter laisse le relais en temps réel entièrement ouvert.
FAQ
Le TOTP est-il suffisant pour un VPN d'entreprise ?
Pour un accès utilisateur standard, il élève significativement le niveau par rapport au mot de passe seul. Pour un accès administrateur ou un accès à des environnements de production, il faut une méthode liée à l'origine, car c'est la seule qui neutralise le relais.
Faut-il autoriser les applications qui sauvegardent les secrets dans le cloud ?
C'est un arbitrage entre le coût de support et l'exposition. La sauvegarde supprime la plupart des réenrôlements, mais étend le périmètre de confiance au compte de sauvegarde. Pour les comptes à privilèges, la réponse est généralement non.
Comment traiter le changement de téléphone sans surcharger le support ?
En inscrivant un second facteur dès l'enrôlement initial, ou en fournissant des codes de secours à usage unique générés une seule fois. L'objectif est de rendre le parcours de secours rare plutôt que d'essayer de le rendre solide.
Un TOTP ajouté à une passkey renforce-t-il la sécurité ?
Rarement, et parfois il l'affaiblit : si le TOTP est accepté en repli lorsque la passkey échoue, l'attaquant provoquera cet échec. Un facteur de secours définit toujours le plancher réel, jamais le plafond.
Aller plus loin : pilier : authentification cognitive · TOTP face à l'AiTM · TOTP ou SMS-OTP · accès à privilèges avec clé physique