TOTP

TOTP (Time-based One-Time Password) est l’algorithme derrière Google Authenticator, Authy, la fonctionnalité TOTP de 1Password et la plupart des 2FA basés sur logiciel. Défini dans RFC 6238 (2011).

Son fonctionnement : lors de l’inscription, le serveur et l’application d’authentification échangent un secret partagé (typiquement une valeur de 160 bits encodée comme une chaîne base32 ou un code QR). Pour générer l’OTP actuel, les deux côtés :

1. Prennent le temps Unix actuel, divisé par la période (30 secondes par défaut), arrondi à l’inférieur.
2. Calculent HMAC-SHA1 de ce compteur en utilisant le secret partagé.
3. Tronquent à 6 chiffres.

Les deux côtés produisent le même code sans communiquer. La fenêtre de 30 secondes plus une tolérance de ±1 fenêtre gère la dérive de l’horloge. Le secret partagé ne quitte jamais l’appareil après l’inscription.

TOTP est bien meilleur que l’OTP par SMS (pas d’exposition au SIM-swap) mais ne défait pas le phishing à lui seul — un attaquant qui phishe le code actuel peut le rejouer dans la fenêtre. WebAuthn / passkeys sont la réponse de nouvelle génération.

Le format de provisionnement du secret partagé : les codes QR affichés par Google Authenticator, GitHub, AWS IAM et autres encodent un URI otpauth://totp/Émetteur:label?secret=BASE32SECRET&algorithm=SHA1&digits=6&period=30. Ce schéma est une convention Google de 2011 plutôt qu’une spécification IETF formelle, mais toutes les grandes applications d’authentification le prennent en charge. Certains services (Microsoft, Steam) étendent les chiffres à 7-8 ou raccourcissent la période à 15 secondes pour une entropie plus élevée. Lisez le code QR avec une application de lecture générique une fois pour capturer le secret, puis sauvegardez-le hors ligne — perdre l’accès à l’authentificateur sans cette sauvegarde signifie passer par la récupération de compte.

SHA-1 dans une spécification de 2026 — est-ce sûr ? Oui, dans ce contexte. L’utilisation de HMAC-SHA1 par TOTP n’est pas vulnérable aux attaques de collision SHA-1 qui ont mis SHA-1 à la retraite pour les certificats TLS ; HMAC dépend de la résistance aux préimages de SHA-1, qui reste intacte. RFC 6238 autorise également SHA-256 et SHA-512, mais pratiquement toutes les applications d’authentification utilisent par défaut SHA-1 pour la compatibilité entre fournisseurs. Liens connexes : OTP, SHA-256, JWT.

Exemple concret : dériver un code

Secret partagé (base32) JBSWY3DPEHPK3PXP. Supposons que le temps Unix actuel est 1700000000. Compteur = floor(1700000000 / 30) = 56666666. Empaquetez le compteur comme un entier big-endian de 8 octets, calculez HMAC-SHA1(secret, compteur) produisant un condensé de 20 octets, prenez le nibble de faible ordre du dernier octet comme décalage o, lisez 4 octets à partir de o, masquez le bit de poids fort et prenez modulo 10⁶. Le résultat est un code à 6 chiffres tel que 359152. À t = 1700000030 le compteur avance de 1 et le code tourne. Douze secondes de décalage d’horloge entre le serveur et le téléphone sont inoffensives ; soixante secondes échouent généralement à la vérification à moins que le serveur n’élargisse la fenêtre de tolérance.

Quand TOTP est le bon choix

TOTP a du sens comme second facteur partout où un attaquant qui dispose déjà du mot de passe devrait être bloqué : connexions bancaires, hébergement de code, consoles cloud, e-mail. Il ne remplace pas un mot de passe (le secret est symétrique — une compromission du serveur révèle le seed de chaque utilisateur) et il n’arrête pas les kits de phishing en temps réel comme evilginx qui proxifient le flux de connexion. Pour une authentification résistante au phishing, préférez WebAuthn / passkeys, qui lient cryptographiquement le credential à l’origine légitime. Référence : NIST SP 800-63B — Directives d’identité numérique (Authentification).