TOTP signifie Time-based One-Time Password (mot de passe à usage unique basé sur le temps). C'est l'algorithme qui se cache derrière les codes à 6 chiffres que vous saisissez lors de la double authentification (2FA).
Défini dans la RFC 6238 (publiée en 2011), TOTP est une extension de HOTP (RFC 4226, basé sur un compteur) où le compteur est remplacé par le temps.
Le principe est simple :
L'algorithme TOTP se décompose en trois étapes principales. Voici une vue simplifiée du calcul que votre application effectue plusieurs fois par minute :
// Étape 1 : Obtenir l'intervalle de temps actuel
T = floor(timestamp_unix / 30)
// Exemple : le 11 février 2026 à 14:30:00 UTC
// timestamp = 1770843000
// T = 1770843000 / 30 = 59028100
// Étape 2 : Calculer le HMAC
hmac = HMAC-SHA1(secret, T)
// Étape 3 : Tronquer pour obtenir 6 chiffres
offset = hmac[dernier_octet] & 0x0F
code = (hmac[offset..offset+3] & 0x7FFFFFFF) % 1000000
// Résultat : un code à 6 chiffres, par ex. 482937Le point crucial est l'étape 1 : le calcul repose entièrement sur le timestamp UNIX, c'est-à-dire le nombre de secondes écoulées depuis le 1er janvier 1970 00:00:00 UTC. La division par 30 crée des "intervalles" de 30 secondes.
T, et donc pas le même code. C'est là que NTP entre en jeu.
Pour que TOTP fonctionne, il faut que deux appareils qui ne communiquent pas directement entre eux arrivent au même résultat. La seule variable commune est le temps.
NTP est le garant de cette synchronisation. Votre téléphone se synchronise via les serveurs NTP de votre opérateur ou du fabricant (Google, Apple). Le serveur d'authentification se synchronise via ses propres sources NTP. Les deux parties obtiennent ainsi une heure cohérente à quelques millisecondes près — largement suffisant pour les intervalles de 30 secondes de TOTP.
Pour comprendre en détail comment fonctionne le protocole NTP, consultez notre guide dédié.
Toutes ces applications utilisent le même algorithme TOTP (RFC 6238). Elles sont donc interchangeables pour la plupart des services :
La plus connue. Simple, pas de sauvegarde cloud (par défaut).
Sauvegarde cloud, notifications push, compatibilité Microsoft 365.
Sauvegarde chiffrée, multi-appareils, application desktop.
Open source (Red Hat). Aucune dépendance cloud.
Stocke les secrets sur une YubiKey physique. Utilise l'horloge de l'appareil hôte.
Open source, sauvegarde chiffrée, interface moderne.
Un quartz d'appareil mobile dérive typiquement de 0,5 à 2 secondes par jour. Sans synchronisation NTP régulière, cette dérive s'accumule et finit par poser problème.
| Décalage | Impact sur TOTP | Conséquence |
|---|---|---|
| 0 - 15 s | Aucun | Le code est dans l'intervalle actuel, tout fonctionne normalement. |
| 15 - 30 s | Limite | Le code est en fin d'intervalle. Peut fonctionner grâce à la tolérance du serveur. |
| 30 - 60 s | Dégradé | Fonctionne uniquement si le serveur accepte T-1 ou T+1. Comportement aléatoire. |
| 60 - 90 s | Échec quasi-total | Le code tombe rarement dans la fenêtre de tolérance. Échecs fréquents. |
| > 90 s | Échec total | Les codes sont systématiquement rejetés. Nécessite une resynchronisation de l'horloge ou un code de secours. |
Par défaut, TOTP utilise un pas de temps (timestep) de 30 secondes.
Mais la plupart des serveurs d'authentification implémentent une fenêtre de tolérance
pour compenser de légères dérives :
La configuration la plus courante est d'accepter T-1, T, et T+1, ce qui offre une fenêtre effective d'environ 90 secondes (3 intervalles de 30 secondes). Ce paramètre est configurable côté serveur :
Pour garantir que vos codes 2FA fonctionnent en permanence, suivez ces recommandations selon votre contexte :
Si vos codes 2FA sont systématiquement rejetés, c'est très probablement un problème d'horloge. Vérifiez que la synchronisation automatique de l'heure est activée sur votre appareil.
Oui, une fois le secret configuré, l'application génère les codes hors-ligne. Elle n'a besoin que de l'heure système. Cependant, sans Internet pendant une longue période, l'horloge ne sera plus synchronisée par NTP et finira par dériver suffisamment pour causer des échecs d'authentification.
NTP garantit que votre téléphone et le serveur d'authentification partagent la même heure. Sans cette synchronisation, les codes TOTP générés ne correspondent pas à ceux attendus par le serveur, et la connexion échoue. C'est un maillon invisible mais critique de la chaîne de sécurité.
Les YubiKey utilisent principalement FIDO2/WebAuthn qui ne dépend pas du temps, ou HOTP (basé sur un compteur). Cependant, quand une YubiKey génère des codes TOTP (via Yubico Authenticator), elle dépend de l'horloge de l'appareil hôte, car la clé elle-même n'a pas d'horloge interne.
Un attaquant qui manipulerait votre horloge pourrait invalider vos codes 2FA ou exploiter des fenêtres de temps. Utilisez NTS (Network Time Security) pour authentifier cryptographiquement votre source de temps et empêcher ce type d'attaque.
L'intervalle de 30 secondes est un compromis entre sécurité (un code valide moins longtemps est plus difficile à exploiter) et utilisabilité (l'utilisateur a suffisamment de temps pour lire et saisir le code). Certains services utilisent 60 secondes pour plus de confort, au prix d'une fenêtre d'attaque plus large.
Votre horloge est-elle suffisamment précise pour vos codes 2FA ? Testez-le maintenant.
Vérifier mon horlogeInfrastructure NTP Stratum 1 | Sécuriser avec NTS | Comprendre NTP | FAQ
Vérifiez que votre NTP fonctionne pour vos codes 2FA | Désynchronisation : quand Kerberos, 2FA et logs deviennent incohérents
Vérifiez que vos systèmes 2FA sont correctement synchronisés