Si tu t'es déjà demandé ce que sont vraiment ces codes à 6 chiffres qui défilent dans ton app d'authentification — et pourquoi quelques tokens matériels se comportent différemment — la réponse tient à deux standards très proches : TOTP et HOTP.
Tu débutes sur le 2FA en général ? Commence par ce qu'est la 2FA et comment elle protège tes comptes.
Réponse courte
TOTP est basé sur le temps : le code est dérivé de l'heure actuelle et change (et expire) toutes les 30 secondes. HOTP est basé sur un compteur : le code est dérivé d'un compteur qui s'incrémente à chaque code utilisé, et il reste valide jusqu'à utilisation. Les deux sont des standards OATH/IETF basés sur HMAC. Ton app d'authentification utilise presque certainement TOTP — c'est ce qu'implémentent Google Authenticator, Authy, Aegis, Bitwarden Authenticator et la plupart des sites. HOTP apparaît surtout sur certains tokens matériels.
HOTP : basé sur un compteur (RFC 4226)
HOTP — HMAC-based One-Time Password — est l'algorithme OATH original, défini dans la RFC 4226 (2005). Chaque code est calculé à partir de deux éléments :
- Un secret partagé (une graine provisionnée une fois, généralement via un QR code)
- Un compteur qui démarre à zéro et s'incrémente de un à chaque code consommé
Le dispositif exécute HMAC-SHA1 (le défaut) sur le secret et le compteur, puis tronque le résultat en un court code numérique — 6 chiffres par défaut, 8 en option.
La propriété qui définit HOTP est que le code n'a pas d'expiration. Il reste valide jusqu'à utilisation effective ; le compteur n'avance que lorsqu'un code est accepté. C'est pratique quand il n'y a pas d'horloge fiable, mais cela a un défaut bien connu : la désynchronisation. Si des codes sont générés côté client sans être soumis (quelqu'un appuie plusieurs fois sur le bouton d'un token), le compteur client prend de l'avance sur celui du serveur et les deux cessent de correspondre. Pour récupérer, les serveurs implémentent une fenêtre de look-ahead : ils testent les quelques valeurs de compteur suivantes, et si l'une correspond, ils avancent leur compteur pour se resynchroniser.
TOTP : basé sur le temps (RFC 6238)
TOTP — Time-based One-Time Password — est défini dans la RFC 6238 (2011), et se comprend le mieux comme un cas particulier de HOTP. Au lieu d'un compteur d'événements, TOTP utilise le temps actuel divisé par un pas de temps (le pas par défaut est de 30 secondes) comme compteur. Injecte ce compteur dérivé du temps dans la même construction HMAC et tu obtiens un code qui change automatiquement toutes les 30 secondes et expire au basculement de la fenêtre.
Comme le compteur est l'horloge et non tes actions, TOTP ne se désynchronise jamais à cause de codes non utilisés — pas de problème du type « j'ai appuyé trop de fois sur le bouton ». La contrepartie : il faut que les horloges du client et du serveur soient à peu près synchronisées. Les serveurs absorbent une légère dérive avec une petite fenêtre de tolérance, en acceptant typiquement le pas de temps précédent et le suivant en plus du pas actuel.
Tout le reste calque HOTP : HMAC-SHA1 par défaut (SHA-256 ou SHA-512 également autorisés), 6 chiffres par défaut (8 en option), et le secret provisionné via un URI otpauth:// dans un QR code. Pour comparer les apps qui génèrent ces codes, voir notre comparatif des meilleures apps d'authentification.
Tableau comparatif
| Propriété | HOTP (RFC 4226) | TOTP (RFC 6238) |
|---|---|---|
| Facteur mobile | Compteur (événement) | Temps (heure actuelle / pas) |
| Le code expire ? | Non — valide jusqu'à utilisation | Oui — toutes les ~30 secondes |
| Pas de temps par défaut | N/A | 30 secondes |
| Défaut principal | Désync du compteur (resync look-ahead) | Dérive d'horloge (fenêtre de tolérance) |
| Algorithme | HMAC-SHA1 (SHA-256/512 en option) | HMAC-SHA1 (SHA-256/512 en option) |
| Chiffres | 6 par défaut (8 en option) | 6 par défaut (8 en option) |
| Besoin du réseau ? | Non | Non |
| Usage typique | Certains tokens matériels, hors-ligne/sans horloge | Apps d'authentification, plupart des sites |
Lequel ton 2FA utilise
En pratique, tu choisis rarement — c'est le service qui décide. Et le service choisit presque toujours TOTP. Le code à 6 chiffres rotatif dans Google Authenticator, Authy, Aegis, Bitwarden Authenticator ou Microsoft Authenticator est du TOTP. Comme l'est le code de quasiment chaque écran de configuration 2FA « scanne ce QR code » que tu croises sur le web.
HOTP est l'exception. Tu le rencontreras surtout sur des tokens matériels — une YubiKey peut par exemple être configurée en OATH-HOTP — ou dans des environnements où une synchronisation de temps fiable ne peut être garantie, soit exactement le scénario où un compteur l'emporte sur une horloge. Une YubiKey sait d'ailleurs faire plusieurs de ces choses : OATH-TOTP, OATH-HOTP, et le bien plus robuste FIDO2. Pour le panorama complet, voir notre guide complet YubiKey et FIDO2.
Sécurité : lequel est le plus sûr
TOTP est généralement préféré pour une raison concrète : ses codes expirent. Un code TOTP capturé par un attaquant n'est exploitable que pendant les secondes restantes avant le basculement de la fenêtre, ce qui garde courte la fenêtre d'interception-et-rejeu. Un code HOTP, lui, reste valide jusqu'à utilisation, donc un code HOTP intercepté mais non utilisé donne à l'attaquant une fenêtre de rejeu plus large.
Mais aucun des deux algorithmes n'est une solution miracle. TOTP comme HOTP sont hameçonnables. Si une fausse page de connexion te pousse à taper un code valide, un attaquant peut relayer ce code vers le vrai service en temps réel avant qu'il n'expire. L'expiration de TOTP raccourcit cette fenêtre mais ne la ferme pas. C'est la limite structurelle de tous les schémas OTP à secret partagé.
Les seuls facteurs largement déployés réellement résistants au phishing sont FIDO2 et les passkeys, parce qu'ils lient l'authentification à l'origine du vrai site : un identifiant relayé ne fonctionne tout simplement pas sur le domaine de l'attaquant. Pour monter dans la hiérarchie de sécurité, lis ce qu'est un passkey.
En résumé
TOTP et HOTP, c'est la même mécanique HMAC avec un facteur mobile différent : HOTP compte des événements, TOTP compte le temps. Les codes HOTP n'expirent jamais mais son compteur peut se désynchroniser ; les codes TOTP expirent toutes les 30 secondes mais son horloge doit rester à peu près alignée. Le monde a tranché pour TOTP sur la 2FA par app parce que des codes qui expirent sont le défaut le plus sûr, et HOTP survit surtout sur les tokens matériels et les scénarios hors-ligne. Quel que soit celui qu'un service te confie, retiens la limite commune : les deux peuvent être hameçonnés. Pour les comptes les plus importants, une clé FIDO2 ou un passkey résistants au phishing constituent la couche la plus solide.
Pour des définitions en langage clair de TOTP, HOTP, 2FA, passkey et clé matérielle, voir le glossaire d'authentification PwdFortress.
PwdFortress explique les standards d'authentification à partir des RFC publiées et de la documentation publique. Nous n'inventons ni résultats de tests ni statistiques.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Un gestionnaire avec 2FA et passkeys intégrés → NordPassStocke TOTP et passkeys · XChaCha20 · offre gratuite→Questions fréquentes
Quelle est la différence entre TOTP et HOTP ?
Les deux sont des standards OATH/IETF de mot de passe à usage unique basés sur HMAC. **HOTP** (RFC 4226) dérive chaque code d'un secret partagé plus un **compteur** qui s'incrémente à chaque code utilisé — le code reste valide jusqu'à utilisation, sans limite de temps. **TOTP** (RFC 6238) est un HOTP où le compteur est le **temps actuel divisé par un pas de temps** (30 secondes par défaut), donc le code change et expire toutes les 30 secondes. En résumé : HOTP = basé sur un compteur/événement, TOTP = basé sur le temps.
Lequel mon app d'authentification utilise, TOTP ou HOTP ?
Presque certainement **TOTP**. Google Authenticator, Authy, Aegis, Bitwarden Authenticator, Microsoft Authenticator et la grande majorité des sites utilisent TOTP — le code à 6 chiffres qui change toutes les 30 secondes. HOTP est bien plus rare ; on le voit surtout sur certains tokens matériels (par exemple une YubiKey configurée en OATH-HOTP) ou dans des contextes où une synchronisation d'horloge fiable n'est pas disponible.
TOTP ou HOTP, lequel est le plus sûr ?
TOTP est généralement préféré parce que ses codes **expirent après ~30 secondes**, ce qui réduit la fenêtre pendant laquelle un code intercepté peut être rejoué. Les codes HOTP restent valides jusqu'à utilisation, donc un code intercepté mais non utilisé a une fenêtre de rejeu plus large. Cela dit, **les deux sont hameçonnables** — un attaquant peut te pousser à saisir un code valide sur un faux site et le relayer en temps réel. Seuls FIDO2/passkeys résistent au phishing.
Pourquoi HOTP se désynchronise-t-il ?
HOTP repose sur un compteur que le client et le serveur incrémentent chacun. Si tu génères des codes côté client sans jamais les soumettre (par exemple en appuyant plusieurs fois sur le bouton d'un token matériel), le compteur client prend de l'avance sur celui du serveur et les codes cessent de correspondre. Pour récupérer, les serveurs utilisent une **fenêtre de look-ahead** : ils testent les quelques valeurs de compteur suivantes, et si l'une correspond ils se resynchronisent. TOTP évite cela car le compteur est l'horloge, pas tes actions.
TOTP a-t-il besoin d'une connexion internet ?
Non. Un code TOTP est calculé localement à partir du secret partagé et de l'heure actuelle, donc la génération fonctionne entièrement hors ligne. Il faut en revanche que les horloges du client et du serveur soient à peu près synchronisées ; les serveurs acceptent généralement une petite fenêtre de tolérance (souvent plus ou moins un pas de temps) pour absorber une légère dérive d'horloge.
Comment le secret OTP est-il partagé au départ ?
Lors de la configuration, le service affiche un QR code qui encode un URI `otpauth://` contenant le secret partagé, l'algorithme (HMAC-SHA1 par défaut, parfois SHA-256/512), le nombre de chiffres (6 par défaut, parfois 8) et le type (`totp` ou `hotp`). Ton app d'authentification le scanne et stocke le secret. À partir de là, les deux côtés calculent le même HMAC et comparent le code obtenu.
