Comment fonctionnent les secrets TOTP (et pourquoi il ne faut pas les partager)

Ce qu’est un secret TOTP, les endroits où ses copies s’accumulent en silence, et l’ordre exact pour réinitialiser un compte dont il a déjà circulé.

Un secret TOTP est une chaîne aléatoire, de 16 à 32 caractères base32, que le fournisseur génère une fois et ne change jamais. Il n’est pas dérivé de votre mot de passe, il n’est lié à aucun appareil, et il n’a pas d’expiration. Toute copie produit des codes valides pour toujours, et rien dans le compte ne peut vous dire combien de copies existent.

Voilà tout le dossier contre son partage. Chacune de ces propositions mérite son détail, et il faut y ajouter ce qu’on fait d’un compte dont le secret a déjà circulé, puisque la question arrive presque toujours trop tard.

Ce qu’est un secret, précisément

La mécanique qui transforme un secret en six chiffres est traitée dans le guide complet du TOTP en équipe. Ce qui compte ici, c’est ce qu’est le secret en tant qu’objet.

Il est symétrique. Les deux côtés détiennent la même valeur. Il n’y a pas de moitié publique : il n’y a donc rien que vous puissiez distribuer sans risque.

Il a beaucoup d’entropie et ne se devine pas. De 80 à 160 bits d’aléa. Aucune attaque pratique ne consiste à le calculer, et c’est précisément pour ça que tout incident réel est une copie.

Il n’a pas de cycle de vie. Pas d’expiration, pas de version, pas de liste de révocation, pas de rotation. Le protocole n’a aucun vocabulaire pour « cette copie n’est plus valide », seulement pour « ce secret n’est plus configuré sur le compte ».

Il est indépendant du mot de passe. Réinitialiser l’un ne fait rien à l’autre. Les équipes changent les mots de passe après un départ et laissent le second facteur en place, ce qui est la mauvaise moitié si le secret a voyagé.

Les endroits où finit une copie

Cette liste mérite d’être lue lentement. L’argument contre le partage n’est pas qu’une copie soit dangereuse, c’est que les copies s’accumulent là où personne ne regarde.

  • La base de données du fournisseur, à sa place.
  • L’application d’authentification de tous ceux qui ont scanné le QR code.
  • La sauvegarde de l’appareil de chacun de ces téléphones, où qu’elle vive.
  • La synchronisation dans le cloud des applications qui la proposent, c’est-à-dire la plupart aujourd’hui.
  • La capture d’écran prise pendant la configuration, dans une pellicule photo, elle-même synchronisée.
  • Le message de conversation où il a été publié, plus l’index de recherche et la rétention de cette plateforme.
  • L’entrée de coffre partagée, exportée un jour dans un fichier que personne n’a supprimé.
  • La variable d’environnement sur un exécuteur de CI ou un serveur, si un automate se connecte.

Deux choses sont vraies de tous les éléments après le premier. Aucun n’apparaît où que ce soit dans les réglages de sécurité du compte, et aucun n’est supprimé par une action que vous pouvez faire à l’intérieur du compte.

Pourquoi « on ne l’a partagé qu’une fois » n’est jamais une fois

Un secret partagé une fois ne reste pas à un seul endroit, parce que les systèmes où il atterrit sont conçus pour copier les choses.

Un téléphone est sauvegardé puis restauré sur son remplaçant. Une application d’authentification ajoute la synchronisation dans le cloud lors d’une mise à jour, et le secret est désormais dans un compte auquel vous n’aviez pas pensé. Un coffre est exporté avant une migration. Une plateforme de discussion conserve l’historique et le rend cherchable par tous ceux qui arrivent ensuite, y compris ceux qui n’étaient pas dans l’équipe au moment du message. Le portable d’un prestataire repart avec le prestataire.

Rien de tout cela ne suppose que quiconque se comporte mal. C’est le fonctionnement ordinaire des logiciels grand public, et c’est pour ça que le nombre de copies d’un secret partagé ne fait jamais que croître.

Ce que son partage vous coûte

Décompte. Vous ne pouvez pas savoir combien de copies existent.

Révocation. Vous ne pouvez pas en retirer une. Vous ne pouvez que toutes les invalider en reconfigurant le compte.

Indépendance. Un secret rangé à côté du mot de passe fait qu’une seule compromission livre les deux facteurs, ce qui revient à un facteur unique avec des étapes en plus.

Attribution. N’importe laquelle des copies a pu produire le code utilisé à 03 h 12. Aucun journal, nulle part, ne dira laquelle.

Tout ce qu’une équipe attend de la 2FA sur un compte partagé, de la disponibilité sans goulot d’étranglement à un départ qui fonctionne, en passant par une réponse à « qui s’est connecté », découle du fait de ne pas distribuer le secret. La mécanique pour y arriver est dans partager des codes TOTP sans partager le secret.

S’il a déjà été partagé

La plupart des équipes qui lisent ceci ont déjà partagé un secret quelque part. La question utile n’est pas de savoir si c’était une erreur, mais quels comptes méritent le travail d’une réinitialisation.

1. Décidez ce que vous réinitialisez

Réinitialisez les comptes où un ancien détenteur du secret pourrait faire de vrais dégâts : tout ce qui touche à l’argent, aux domaines, aux données clients, aux droits de publication ou à l’infrastructure cloud. Pour un compte sans enjeu dont vous pouvez changer le mot de passe et dont la liste d’accès est courte, changer le mot de passe et resserrer le partage peut être proportionné. Ce qui compte, c’est de décider délibérément ; décider par inertie est ce qui laisse un compte de paiement exposé pendant deux ans.

2. Réinitialisez dans cet ordre

L’ordre compte, parce que deux de ces étapes peuvent vous enfermer dehors si vous les prenez en premier.

  1. Assurez-vous d’avoir des codes de récupération à jour, ou de pouvoir les obtenir, avant de toucher à quoi que ce soit.
  2. Désactivez la 2FA sur le compte. Toutes les copies existantes du secret meurent ici.
  3. Réactivez-la, et mettez le nouveau secret à exactement un endroit.
  4. Accordez l’accès aux personnes qui ont besoin des codes, sans distribuer le nouveau secret.
  5. Régénérez et rangez les codes de récupération, hors du compte qu’ils récupèrent.

3. Puis nettoyez ce que la réinitialisation n’a pas touché

C’est l’étape qu’on saute. Réinitialiser le second facteur ne met en général fin à rien de ce qui est déjà en cours :

  • Déconnectez tous les appareils et toutes les sessions. Un attaquant avec une session vivante n’a pas besoin de codes.
  • Changez le mot de passe, puisque les deux identifiants ont en général voyagé ensemble.
  • Passez en revue les clés d’API, les jetons et les applications connectées. Ils s’authentifient sans le second facteur par conception, et ils survivent à sa réinitialisation.
  • Regardez l’historique d’accès et de connexion du compte, à la recherche de ce qui viendrait d’une période ou d’un lieu qui ne devraient pas exister.

4. Notez où vit le nouveau secret

Une ligne par compte : où est le secret, qui l’administre, où sont les codes de récupération. C’est l’absence de cette note qui rend les équipes réticentes à réinitialiser quoi que ce soit, parce que personne n’est sûr de ce qui va casser.

Où un secret devrait vivre

À un seul endroit, atteignable par au moins deux administrateurs, séparé des codes de récupération, et séparé du compte qu’il protège. Que ce soit une entrée restreinte de votre gestionnaire de mots de passe ou un outil fait pour ça importe moins que la partie « un seul ».

Share Auth est une réponse : le secret est saisi une fois, chiffré au repos, et plus jamais affiché. Les membres voient des codes et des décomptes, l’accès est accordé par personne et par compte, et chaque consultation est journalisée. Ce qu’il supprime, c’est la raison pour laquelle les équipes distribuent des secrets au départ, à savoir que la personne qui tient le téléphone n’est pas toujours disponible.

En bref

  • Un secret TOTP est permanent, symétrique et irrévocable pris isolément.
  • Le partager vous coûte le décompte, la révocation, l’indépendance des facteurs et l’attribution.
  • Les copies se multiplient par les sauvegardes, la synchronisation, les exports et les historiques de conversation, sans que personne fasse rien de mal.
  • S’il a été partagé, décidez compte par compte, réinitialisez dans l’ordre, et nettoyez les sessions et les jetons que la réinitialisation laisse derrière elle.
  • Puis gardez exactement une copie, et donnez plutôt aux gens l’accès aux codes.

Questions fréquentes

En pratique oui : clé, secret et graine désignent la même chaîne base32. Ce qui diffère, c’est le Key URI, le texte otpauth:// qu’encode le QR code de configuration, qui porte le secret et ses paramètres. Quand un outil demande une clé, il attend en général le secret.

À lire aussi · Comment fonctionne TOTP

12 min de lecture

Le guide complet du TOTP en équipeGuide

Comment fonctionne TOTP, quelles propriétés de l’algorithme causent tous les problèmes de comptes partagés, et ce qu’une équipe doit mettre en place.