- La différence fondamentale d'entrée : HOTP calcule les condensats cryptographiques à partir d'un compteur d'événements strictement croissant C, tandis que TOTP remplace C par un pas temporel T (TempsUnixActuel / 30).
- Héritage direct : TOTP est mathématiquement une spécialisation directe de HOTP :
TOTP(K, Temps) = HOTP(K, T). Les deux algorithmes emploient rigoureusement la même fonction de troncature dynamique (Dynamic Truncation). - Le facteur décisif d'architecture : HOTP conserve un état côté serveur (les serveurs doivent verrouiller et persister un compteur en base de données à chaque validation). TOTP est sans état (stateless), permettant aux microservices cloud modernes de valider les jetons sur des grappes distribuées sans écriture concurrente.
Origines historiques : Des jetons matériels propriétaires aux standards ouverts du Web
Au début des années 2000, l'authentification forte en entreprise était monopolisée par des boîtiers physiques propriétaires, tels que les porte-clés RSA SecurID. Ces équipements coûteux et fermés intégraient des oscillateurs à quartz scellés, synchronisés avec des serveurs propriétaires d'entreprise. Pour une organisation souhaitant équiper des dizaines de milliers d'employés, les coûts d'acquisition de matériel et de licences logicielles étaient exorbitants.
Afin d'émanciper la sécurité des solutions propriétaires, le consortium OATH (Initiative for Open Authentication) a été fondé par les leaders de l'industrie pour élaborer des standards IETF ouverts et libres de droits, audités et implémentables par n'importe quel ingénieur logiciel :
HMAC-Based One-Time Password Algorithm. Conçu pour des microcontrôleurs basse consommation munis d'un bouton-poussoir. Chaque appui physique incrémente un compteur interne et affiche un code à 6 chiffres sur un écran LCD.
Time-Based One-Time Password Algorithm. Élaboré avec l'avènement massif des smartphones. En exploitant la synchronisation temporelle automatique par le protocole réseau NTP, TOTP s'affranchit totalement du compteur physique.
Architecture HOTP (RFC 4226) & Fonctionnement de la troncature dynamique
La définition mathématique fondamentale de HOTP est remarquablement concise :
Décomposition des paramètres :
K: Clé secrète symétrique partagée (généralement une séquence binaire de 160 bits / 20 octets décodée depuis du Base32).C: Entier non signé de 8 octets (64 bits) encodé en grand-boutiste (Big-Endian).HMAC-SHA-1: Code d'authentification de message à clé produisant une empreinte cryptographique de 20 octets (160 bits).
🔍 Comment la Troncature Dynamique (DT) convertit 20 octets en 6 chiffres :
Une empreinte HMAC-SHA1 contient 160 bits (20 octets). L'extraction uniforme et déterministe de 6 chiffres décimaux répond aux spécifications rigoureuses de la Section 5.3 de la RFC 4226 :
0x0F isole les 4 bits de poids faible, produisant un entier strictement compris entre 0 et 15 (0x0 à 0xF). Cela garantit mathématiquement que la lecture des 4 octets suivants ne dépassera jamais la mémoire tampon de 20 octets (puisque 15 + 4 = 19).
0x7F met à zéro le bit de signe le plus significatif afin d'éviter tout dépassement d'entier signé selon l'architecture du processeur (assurant un entier positif propre sur 31 bits).
Considérons la clé secrète en chaîne ASCII "12345678901234567890" et un compteur C = 0. L'empreinte hexadécimale HMAC-SHA1 résultante est :
1. Le dernier octet est 0x71. On applique 0x71 & 0x0F = 0x01, donc Offset = 1.
2. Les octets 1 à 4 sont : 93 cf 18 50. En annulant le bit de signe (MSB), on obtient 0x13cf1850, ce qui correspond en décimal à 332 339 280.
3. 332339280 mod 1000000 = 339280. Le code OTP à 6 chiffres produit est donc exactement 339280 !
Évolution vers TOTP (RFC 6238) : La magie du pas de temps
HOTP imposait de maintenir le compteur du client rigoureusement synchrone avec celui du serveur. Sur des logiciels pour téléphones ou ordinateurs, le comptage d'événements était une source permanente d'erreurs et de frustrations pour les utilisateurs.
La RFC 6238 a remplacé le compteur C par un pas de temps discret T calculé directement à partir de l'horloge Unix universelle :
- TempsUnixActuel : Nombre de secondes écoulées depuis l'époque POSIX (1er janvier 1970 à 00:00:00 UTC).
- T0 : Point de référence temporel initial (égal à 0 dans toutes les implémentations modernes).
- X (Fenêtre temporelle) : Intervalle standard universel fixé à 30 secondes.
- Fonction partie entière ⌊ ⌋ : Pendant n'importe quelle tranche de 30 secondes, T demeure strictement invariant. Par exemple, entre les secondes 1728211200 et 1728211229, la valeur de T sera identique.
Sérialisation binaire : Une fois T calculé, il est converti en un tampon binaire de 8 octets en grand-boutiste (Big-Endian), strictement identique à la structure du compteur C de HOTP. Par conséquent, la formule unifiée devient tout simplement :
TOTP(K, Temps) = HOTP(K, T)
Cette pureté conceptuelle explique pourquoi les applications d'authentification renouvellent leurs codes de façon synchrone toutes les 30 secondes sans jamais nécessiter de connexion réseau avec le serveur.
HS[31] & 0x0F) ; pour SHA-512 (64 octets), de l'octet 63 (HS[63] & 0x0F). Cependant, sur 99,9 % des services grand public (Google, Microsoft, GitHub, AWS), SHA-1 demeure le choix par défaut universel pour assurer une compatibilité absolue avec tous les terminaux mobiles.
Matrice comparative détaillée (HOTP vs TOTP)
| Critère | HOTP (RFC 4226) | TOTP (RFC 6238) |
|---|---|---|
| Variable d'entrée | Compteur événementiel C (croissant) | Pas temporel T (fenêtre Unix de 30 secondes) |
| Durée de vie du jeton | Indéfinie (valide jusqu'à son utilisation) | Stricte de 30 secondes (invalidation auto) |
| Architecture serveur | Avec état (Stateful : écriture atomique en BDD) | Sans état (Stateless : horloge NTP indépendante) |
| Exposition au rejeu (Replay Attack) | Modérée (un jeton intercepté reste utilisable) | Minimale (limité aux secondes restantes du pas T) |
| Cause principale d'erreur | Désynchronisation de compteur (appuis involontaires) | Dérive d'horloge (décalage de l'heure du client) |
| Algorithmes de hachage | HMAC-SHA-1 exclusivement | HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512 |
| Adoption actuelle | Anciens terminaux bancaires, badges d'accès | 99,9 % des applications web modernes |
Désynchronisation de compteur vs Dérive temporelle : Solutions d'ingénierie
Dans un environnement distribué en production, les horloges ou les compteurs dérivent inévitablement. Les cryptographes ont conçu des mécanismes de tolérance pour garantir une fiabilité irréprochable :
Si un utilisateur appuie par erreur 5 fois sur son boîtier sans se connecter, le compteur de son jeton passe à C+5 alors que le serveur en est toujours à C.
La RFC 4226 stipule que le serveur doit tester une fenêtre prospective allant de [C+1, C+s] (généralement s=20). En cas de correspondance trouvée, le serveur avance instantanément son compteur pour rattraper le jeton.
En raison de la latence réseau ou d'un smartphone accusant quelques secondes de retard, un jeton peut parvenir au serveur dans un intervalle adjacent.
Les serveurs de production évaluent couramment une séquence de 3 fenêtres temporelles : [T-1, T, T+1], offrant une tolérance pratique de 90 secondes.
Lorsqu'un serveur valide un code saisi par l'utilisateur, une simple comparaison de chaînes (telle que codeUtilisateur === codeServeur) s'arrête dès le premier caractère erroné. Un cybercriminel mesurant avec précision les microsecondes de temps de réponse pourrait théoriquement reconstituer le code chiffre par chiffre. Les architectures professionnelles imposent donc des comparaisons en temps constant (ex. crypto.timingSafeEqual sous Node.js).
Pourquoi TOTP a conquis l'Internet moderne
Le triomphe incontesté de TOTP sur HOTP à travers l'écosystème numérique s'explique par trois impératifs d'ingénierie logicielle majeurs :
Dans les infrastructures distribuées et multi-régions, n'importe quel conteneur synchronisé par NTP valide les jetons TOTP sans verrouiller de base de données.
Les smartphones calibrent leur horloge interne en continu via les réseaux cellulaires et le GPS, supprimant ainsi tout risque de dérive temporelle pour l'usager.
Les codes HOTP restent valables indéfiniment. Les jetons TOTP expirent au bout de 30 secondes, neutralisant d'office les fuites d'historique ou l'écoute passive.
Visualisez les calculs TOTP en temps réel dans 2FA-Tool
Découvrez en direct comment votre clé secrète Base32 est transformée en jetons dynamiques à 6 chiffres via HMAC-SHA1 et troncature dynamique. Fonctionne hors ligne dans votre navigateur.
📚 Guides de sécurité recommandés
Comment migrer vos comptes 2FA entre smartphones via QR code hors ligne et synchronisation cloud.
Règles de conformité, sauvegarde des codes de secours, clés SSH et procédures de déblocage.
Récupération d'urgence sur Google, Microsoft, Steam, Binance, Apple et Discord.