Résumé

  • RFC 1938 vérifiait une réponse en la hachant une fois, puis, en cas de succès, remplaçait la valeur conservée par cette réponse : l’accès faisait avancer une chaîne à sens unique.
  • La propriété « une seule fois » dépendait donc aussi d’une mise à jour atomique, d’une défense contre les sessions concurrentes et d’une réinitialisation avant épuisement.
  • La phrase secrète ne transitait pas sur le réseau, mais le protocole ne chiffrait pas la session et n’arrêtait pas toutes les attaques actives ; HOTP et TOTP ont ensuite choisi d’autres états mobiles.

Deux réponses identiques, deux vérités successives

La scène décisive ne se déroule pas dans la fonction de hachage, mais entre deux instants. Une réponse x arrive. Selon RFC 1938, le serveur calcule H(x) et le compare au vérificateur enregistré. Si les valeurs coïncident, il accepte x puis enregistre x à la place de l’ancien vérificateur. La même suite de bits, rejouée après cette écriture, ne satisfait plus la condition nouvelle.

La notice actuelle du RFC Editor date ce Proposed Standard de mai 1996, l’attribue à N. Haller et C. Metz et indique qu’il a été rendu obsolète par RFC 2289. Ces métadonnées fixent sa place normative. Elles n’expliquent pas encore son apport : avoir transformé l’authentification en transition d’état partagée.

Le générateur part d’une phrase secrète et d’un germe public, puis applique plusieurs fois une fonction à sens unique. À la profondeur N, la première réponse est H^N(S) ; la suivante remonte la chaîne vers H^(N-1)(S). Le serveur n’a pas besoin de connaître la phrase secrète. Il conserve un résultat de 64 bits et la position courante.

Ce mouvement inverse est astucieux. Connaître une réponse permet de calculer vers les valeurs déjà utilisées, pas vers la prochaine réponse attendue. Une écoute passive livre donc une preuve qui devient périmée au moment où l’utilisateur légitime la consomme. Le principe provenait du système S/KEY de Bellcore, décrit dans RFC 1760, et visait le risque très concret des mots de passe permanents observables sur le réseau.

Il serait pourtant faux de dire que le serveur « ne stocke rien ». Il ne stocke pas le secret initial, mais il détient une vérité mutable sur le compte. Perdre, répliquer en retard ou restaurer cette vérité modifie ce que le protocole acceptera.

Une représentation humaine qui ne doit pas devenir un mythe

Le défi annonce l’algorithme, le numéro de séquence et le germe, par exemple otp-md5 487 dog2. MD5 devait être pris en charge, SHA était recommandé et MD4 permis. Les deux extrémités devaient faire le même choix ; offrir un algorithme faible pour compatibilité pouvait fixer la résistance de l’ensemble.

Pour éviter la saisie pénible de 64 bits, la norme utilisait six mots tirés d’un dictionnaire de 2 048 entrées. Chaque position codait 11 bits. Les 66 bits obtenus comportaient donc deux bits de contrôle destinés à repérer certaines erreurs de saisie ou de décodage. Ce contrôle ne constituait ni un second facteur ni une preuve cryptographique supplémentaire. Les six mots étaient une interface, pas six secrets.

Le serveur devait accepter cette forme et la notation hexadécimale, et devait de préférence comprendre des formes issues d’un autre dictionnaire. Les règles de casse, de découpage et de décodage pouvaient ainsi faire échouer deux représentations d’une même valeur. L’ergonomie touchait directement l’interopérabilité.

La course que le hachage ne peut arbitrer

RFC 1938 envisage un attaquant qui entend une grande partie des six mots, devine le reste et tente d’arriver avant l’utilisateur. Le serveur conforme doit se défendre. Interdire plusieurs sessions simultanées pour un même compte est une solution proposée, à condition d’ajouter un délai d’expiration pour que ce verrou ne permette pas un déni de service indéfini.

Une course plus silencieuse peut apparaître à l’intérieur du service. Deux processus lisent l’ancien vérificateur, valident chacun x, puis écrivent chacun le nouvel état. Le calcul est exact, mais une preuve consommable a ouvert deux sessions. La comparaison et l’avancement doivent donc former une opération atomique, ou être sérialisés d’une manière équivalente. La base de données est ici une partie de la cryptographie appliquée.

La chaîne possède aussi une fin. Le numéro de séquence compte un stock de réponses. La réinitialisation doit changer le germe ou la phrase secrète ; reprendre les deux recréerait des valeurs potentiellement déjà vues. Envoyer la phrase secrète en clair pour réparer le compte annulerait la protection recherchée.

Le cas du compte arrivé à un est révélateur. Une procédure conseillée pouvait demander un ancien OTP avant d’installer la nouvelle chaîne. Si le dernier OTP sert à entrer, il n’en reste plus pour autoriser l’opération. Attendre zéro n’est donc pas une simple maladresse d’exploitation : c’est méconnaître l’état de sécurité du protocole.

Le successeur a précisé la frontière

La fiche de RFC 2289 le présente comme le Proposed Standard de février 1998 qui remplace RFC 1938. Son texte complet conserve la chaîne descendante, ajoute notamment des vecteurs d’essai et renforce les recommandations. L’emploi d’IPsec contre le détournement d’une connexion TCP y est conseillé : preuve utile que réussir l’OTP ne protège pas automatiquement la session qui suit.

D’autres systèmes ont placé le mouvement ailleurs. HOTP associe un secret partagé à un compteur croissant ; le validateur peut chercher dans une fenêtre d’avance pour se resynchroniser, puis incrémente après le succès. TOTP prend une tranche de temps comme facteur mobile de HOTP et interdit de réaccepter, dans la même tranche, un OTP déjà validé avec succès. Cette comparaison n’établit aucune filiation avec S/KEY. Les secrets conservés, le sens du mouvement et les risques de synchronisation diffèrent.

La constante est ailleurs : un validateur ne peut pas se contenter de demander « le code correspond-il ? ». Il doit décider quel état fait foi, quelle tolérance est admise, ce que le succès consomme et comment plusieurs instances partagent la chronologie.

Enfin, une réussite ne doit pas être gonflée en preuve universelle. RFC 1938 n’offre ni confidentialité ni défense générale contre l’attaque active ou l’ingénierie sociale. Il relie une réponse à l’état d’un compte configuré. Il ne prouve pas à lui seul l’autorisation d’une commande, le résultat d’une opération, la persistance d’un accès ou l’identité civile de la personne présente.

Ce que signifie vraiment « une seule fois »

Le principe de primauté du code en fonctionnement formulé par Heng Lu éclaire la fragilité de la promesse. Un texte peut exiger un avancement unique ; seul le comportement en production révèle si une panne, une réplication ou une restauration permet en réalité deux histoires.

Une spécification initiale minimale suffit à fixer l’invariant : chaîne, défi, formes acceptées, test et mutation. Les implantations locales peuvent différer, mais elles ne peuvent pas appeler « une fois » une réponse qui crée deux transitions acceptées.

La lecture par couches de réalité sépare enfin le nom du mécanisme. « Mot de passe à usage unique » est une affirmation symbolique. Sa réalité opérationnelle tient dans un vérificateur, une écriture atomique, une politique de concurrence, une réserve finie et un droit de réinitialiser. La clarté consiste à ne pas attribuer au nom les garanties que ces couches n’ont pas produites.

RFC 1938 rappelle ainsi qu’une preuve peut modifier le monde où sera jugée la preuve suivante. À cet instant, authentifier n’est plus lire un fait. C’est écrire une chronologie.

Sources

  1. RFC Editor — état actuel de RFC 1938
  2. RFC 1938 — A One-Time Password System
  3. RFC 1760 — The S/KEY One-Time Password System
  4. RFC Editor — état actuel de RFC 2289
  5. RFC 2289 — A One-Time Password System
  6. RFC 4226 — HOTP
  7. RFC 6238 — TOTP
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile