Résumé

  • Le RFC 2069 empêchait l’envoi du mot de passe en clair, mais le serveur pouvait vérifier avec H(A1), une valeur capable d’ouvrir directement le realm correspondant si elle était volée.
  • La réponse de base liait ce secret au nonce, à la méthode HTTP et à l’URI ; elle ne chiffrait pas le contenu et ne prouvait ni toutes les données du message, ni l’intention, ni l’autorisation, ni l’effet final.
  • Un nonce contenant adresse et horodatage pouvait borner un rejeu sans conserver d’état. Garantir l’usage unique exigeait au contraire de retenir les réponses déjà vues jusqu’à leur expiration.

Le journal ne contient pas encore le verdict

L’amélioration apportée en janvier 1997 était substantielle. Dans l’authentification Basic décrite par le RFC 1945, l’identifiant et le mot de passe étaient seulement représentés en Base64. Un observateur pouvait donc récupérer un secret réutilisable. Le RFC 2069 remplaça cet envoi par un défi-réponse : le serveur proposait un nonce, le client calculait une valeur et le mot de passe ne traversait plus la liaison en clair.

Le texte ne prétendait pourtant pas résoudre la sécurité du Web. Il qualifiait Digest de mécanisme faible, ne chiffrait aucun contenu et ne définissait pas l’établissement initial du mot de passe. Le RFC 2068 fournit le contexte HTTP/1.1 de la même période ; leur publication ne constitue pas un relevé des logiciels qui les adoptèrent.

Cette modestie aide à lire une trace correctement. Une égalité cryptographique est un constat sur les entrées du calcul et sur l’état consulté par le vérificateur. Elle n’est pas encore une histoire complète de la commande.

Ce que le calcul rassemble

Dans le RFC 2069, l’algorithme concret est MD5, défini par le RFC 1321. La construction essentielle est la suivante :

A1 = nom-utilisateur : realm : mot-de-passe
A2 = méthode : URI-demandée
réponse = KD(H(A1), nonce : H(A2))

Une réponse correcte associe donc un secret propre au realm, un défi émis par le serveur et deux éléments de la requête : la méthode et l’URI. Le serveur doit en outre vérifier que l’URI répétée dans l’en-tête désigne bien la ressource effectivement servie, car un intermédiaire peut transformer la ligne de requête.

La liste des entrées dessine aussi les absences. Les autres en-têtes ne sont pas couverts automatiquement. Le contenu n’est pas chiffré. La réponse de base ne prouve pas l’identité d’un humain, son consentement, le droit d’exécuter l’action, l’unicité d’une transaction ou la réussite de son résultat. Le RFC proposait un champ digest séparé et facultatif pour le corps et certaines métadonnées, notamment pour POST et PUT. Cette option confirme que la réponse ordinaire n’était pas une signature de tout le message.

H(A1) n’était pas un déchet inoffensif

Le serveur pouvait vérifier sans connaître le mot de passe en clair : conserver le nom et H(A1) suffisait. Mais la section consacrée au stockage retire toute ambiguïté rassurante. Si le fichier était compromis, l’attaquant pouvait accéder immédiatement aux documents du realm sans retrouver d’abord le mot de passe. Le fichier devait donc être protégé comme s’il contenait des mots de passe non chiffrés.

Le mot « équivalent » doit rester précis. Le realm entre dans A1. Le même couple utilisateur/mot de passe produit une autre valeur dans un autre realm, ce qui limite la réutilisation directe. En revanche, dans le realm concerné, posséder H(A1) donne la capacité de fabriquer une réponse acceptée. Le nom technique « hash » ne réduit pas cette puissance exécutable.

La distinction compte dans toute cartographie de secrets. Classer les données selon leur apparence — clair ou condensé — masque la question décisive : que peut faire le détenteur ? Une sauvegarde de vérificateurs, une réplique de haute disponibilité ou un service d’authentification partagé multiplie les lieux où cette capacité existe.

La fraîcheur n’est pas l’unicité

Le RFC recommandait un nonce contenant le condensé de l’adresse IP du client, d’un horodatage et d’une clé privée du serveur. Le serveur pouvait le recalculer, limiter sa durée et son origine apparente, sans mémoriser chaque défi. C’était une économie d’état utile.

Cependant, un nonce encore dans sa fenêtre reste susceptible d’être présenté plusieurs fois. Le calcul dit qu’il est bien formé et non expiré ; il ne dit pas qu’il est neuf. Pour un simple GET, le texte estimait le rejeu souvent peu profitable, puisque l’URI était liée et que l’espion avait déjà vu le document. Il signalait néanmoins les GET déclenchant une action et insistait sur POST et PUT, où un rejeu pouvait soumettre de fausses données ou un faux fichier.

L’option forte consistait à utiliser une réponse à usage unique et à mémoriser les condensés déjà acceptés jusqu’à l’expiration du nonce. Cette solution ajoute stockage, recherche, purge et cohérence. Dans une grappe, il faut encore que tous les nœuds consultent un état compatible. L’absence de ce coût laisse une preuve de validité, pas une preuve de premier passage.

Les successeurs ont rendu la dette visible

Le RFC 2617 remplaça le RFC 2069 ; sa notice RFC Editor l’indique explicitement. Il ajouta le chemin qop, un nonce choisi par le client (cnonce) et un compteur nc. Lorsque le serveur conserve son propre compteur, revoir la même valeur permet de détecter un rejeu. Avec auth-int, le corps entre dans A2. Sans qop, la formule de compatibilité reste celle du RFC 2069 : la correction ultérieure ne doit pas être projetée dans le passé.

Le RFC 7616, avec sa notice historique, introduisit SHA-256 et SHA-512/256 et déconseilla MD5. Il conserva pourtant l’avertissement sur H(A1) : un fichier volé donne toujours un accès direct au realm. Il précise aussi que l’agilité algorithmique ne corrige pas les mots de passe humains faibles et recommande HTTPS.

Le cadre moderne du RFC 9110 permet de maintenir une autre séparation : authentifier des informations d’identification peut alimenter une décision d’autorisation, mais ne réalise pas cette décision ni son effet applicatif.

Lire la preuve par couches

Lorsqu’un opérateur voit un Digest valide, il doit demander : quelle formule ? quel realm ? quel algorithme ? quel mode de protection ? quel nœud ? quel état anti-rejeu ? quel corps couvert ? quelle décision d’autorisation ? quel identifiant de transaction ? Sans ces réponses, le journal donne une pièce utile, pas un reçu total.

La primauté du code en fonctionnement de Lu Heng invite à distinguer la règle localement vérifiable de la réalité déployée. Sa spécification initiale minimale sépare les invariants communs des décisions futures de chaque participant. Appliqué ici, le calcul est commun ; la durée du nonce, le budget d’état et l’autorisation restent locaux.

La note sur les couches de réalité empêche enfin de transformer un symbole valide en pouvoir imaginaire. Le Digest atteste une relation mathématique. Seuls les systèmes qui conservent l’état et exécutent l’action peuvent prouver les étapes suivantes.

Sources