Pourquoi les codes TOTP échouent quand l’horloge de l’appareil dérive

Les codes à usage unique peuvent être parfaitement corrects sur votre téléphone et être rejetés par le serveur à la même seconde. Les deux côtés calculent la même fonction à partir d’un secret partagé et du pas de temps courant, si bien qu’un désaccord sur l’heure produit un désaccord sur le code. Cela fait de la dérive d’horloge un défaut important pour la sécurité, et non une simple gêne.

Deux horloges comptent ici, et corriger la visible est la partie que les gens font en premier. Celle qui demande généralement attention est l’autre.

Le code est une fonction du temps, pas un mot de passe

TOTP prend le secret partagé et un compteur dérivé de l’heure courante, fait passer les deux dans un hachage à clé et tronque le résultat en une courte chaîne décimale, comme spécifié dans la RFC 6238. Le compteur avance à chaque pas de temps, conventionnellement trente secondes, si bien que le même secret produit une nouvelle valeur quand le pas change. Le vérificateur recalcule la valeur attendue pour le pas courant et compare, ce qui exige le même secret et la même idée du moment présent. Un mot de passe reste réutilisable jusqu’à ce qu’il soit changé, alors que cette valeur expire sur une frontière que le client ne voit pas.

C’est pourquoi un code fonctionne et le suivant échoue quelques instants plus tard. Cela explique aussi pourquoi copier un code depuis un message de discussion est une habitude si peu fiable.

Deux horloges doivent s’accorder, pas une

Le matériel d’enrôlement est la première chose partagée, et le temps la seconde. Si le secret est correct alors que les horloges diffèrent de plus que la fenêtre tolérée, chaque valeur générée tombe sur le mauvais pas et est rejetée. Si les horloges s’accordent alors que le secret est faux, chaque valeur est rejetée aussi, et les deux échecs paraissent identiques sur l’écran de connexion. Les distinguer suppose de vérifier l’entrée de compte et le temps séparément, dans cet ordre.

L’horloge du vérificateur mérite le même examen que celle de l’appareil. Un serveur dont la source de temps est défaillante rejette les codes corrects de tous les utilisateurs à la fois, et les rapports décriront une panne soudaine plutôt qu’une dérive. Ce schéma mérite d’être reconnu, car son correctif appartient au serveur et non à cent téléphones.

Ce que coûte l’élargissement de la fenêtre

Les implémentations peuvent accepter un code d’un pas adjacent pour absorber de petits écarts, et cette tolérance est une décision de conception, non un réglage gratuit. Chaque pas supplémentaire multiplie le nombre de valeurs valides à un instant donné, ce qui est exactement ce que préfère un attaquant qui devine. La règle anti-rejeu compte pour la même raison, car un code accepté deux fois est un code qui a fuité utilement. Un administrateur qui élargit la fenêtre pour faire taire les plaintes échange une propriété réelle contre une amélioration cosmétique.

Corriger l’horloge est la réparation, tandis qu’élargir la fenêtre est un sédatif. La première supprime la cause et la seconde la cache.

Vérifiez les deux horloges avant de réessayer

Lisez l’heure sur l’appareil et sur le serveur, et comparez les décalages plutôt que les heures locales affichées. Les commandes ci-dessous montrent l’état de synchronisation et l’instant UTC brut sur un hôte ou un serveur Linux. Exécutez-les aux deux extrémités avant de modifier un quelconque réglage d’authentification.

timedatectl
date -u +'%Y-%m-%dT%H:%M:%SZ'
chronyc tracking
timedatectl timesync-status

Un décalage mesuré en secondes est inoffensif, un décalage en minutes explique un rejet, et un système qui ne signale aucune source de synchronisation est candidat aux deux. Comparez directement les deux horodatages UTC, car l’heure locale inclut un fuseau horaire que l’algorithme ne voit jamais. Si les décalages sont faibles et que les codes échouent encore, cessez d’ajuster les horloges et inspectez plutôt l’entrée d’enrôlement. Des tentatives répétées contre un compte verrouillé rendent le défaut d’origine plus difficile à observer.

Notez l’heure du rejet, le décalage et le texte de l’erreur, et laissez le secret partagé en dehors de cela. Le support peut travailler avec les trois premiers et ne devrait jamais voir le quatrième.