Résumé

  • Le formulaire actuel de WHOIS Crypt chez AFRINIC déclare une requête POST vers la même origine et un champ de type texte appelé plaintextpassword. Aucun mot de passe n’a été saisi et aucune requête n’a été envoyée pendant cette enquête.
  • Le fait qu’une empreinte BCRYPT soit renvoyée ne décrit pas la garde du secret avant le calcul. AFRINIC devrait rendre cette étape observable, d’autant que son guide affirme que seule l’empreinte doit lui être communiquée.

La phrase la plus exigeante du guide des membres d’AFRINIC n’est pas une formule cryptographique. Elle répartit les responsabilités. Le membre doit produire une empreinte BCRYPT, ne transmettre que cette empreinte à AFRINIC et garder en sécurité son mot de passe en clair. Cette répartition paraît simple : le secret reste chez son détenteur, le registre reçoit un vérificateur qui peut être placé dans l’attribut auth: d’un objet mainteneur.

Or le chemin recommandé comporte une étape que cette phrase ne nomme pas. La page des utilitaires WHOIS d’AFRINIC renvoie vers l’application WHOIS Crypt. Dans la copie du code HTML observée le 14 septembre 2026, cette application affiche un formulaire myForm. Son action relative est ?lang=en#cli et sa méthode est POST. Le contrôle étiqueté « Password » est déclaré type="text". Son identifiant et son nom de soumission sont identiques : plaintextpassword. Le bouton propose de « Generate hash ».

Cette lecture repose sur le document publié, pas sur une opération intrusive. Nous n’avons rempli aucun champ, utilisé aucun identifiant, envoyé aucune requête de formulaire et modifié aucun objet WHOIS. La syntaxe indique ce que le navigateur est invité à faire si l’utilisateur valide : résoudre l’action relative sur l’origine whois-web.afrinic.net et inclure la valeur applicative du champ nommé dans une requête POST. La norme HTML décrit justement les formulaires comme des contrôles dont les données peuvent être envoyées à un serveur pour traitement ; elle illustre le traitement serveur par des paramètres placés dans le corps d’une requête HTTP POST.

Il faut donc distinguer l’instruction du résultat observé. Nous possédons la première, pas le second. Rien dans les éléments collectés ne prouve qu’un utilisateur réel a soumis un secret, qu’un serveur l’a enregistré ou qu’une fuite a eu lieu. Mais le formulaire suffit à identifier un destinataire déclaré. L’outil n’est pas seulement une machine qui donne une empreinte ; il est aussi une surface qui demande le matériau dont l’empreinte sera tirée.

Le HTTPS de l’adresse est une contre-preuve importante. TLS vise à empêcher l’écoute et la modification des échanges entre les extrémités. Parler d’un mot de passe « en clair » dans cet article ne signifie donc pas qu’il circule lisiblement sur le réseau. Il s’agit de sa valeur applicative avant hachage. Un tunnel chiffré peut transporter cette valeur jusqu’au serveur qui la traite. Le chiffrement du transport protège le trajet ; il ne transforme pas un traitement distant en calcul local.

La nature du champ forme une autre couche. La norme HTML réserve à type="password" un contrôle qui masque la saisie. Le formulaire capturé utilise type="text". Cela n’établit ni qu’une personne a vu l’écran, ni que le secret est faible, ni que BCRYPT est mal paramétré. Le choix indique seulement que la page ne demande pas au navigateur son comportement de masquage dédié. Exposition visuelle, transport, traitement par l’extrémité et conservation dans les journaux sont quatre contrôles distincts.

Le contraste avec le guide ne doit pas être exagéré. « Seule l’empreinte doit être partagée avec AFRINIC » peut désigner la valeur finale insérée dans la base WHOIS, non chaque étape de l’outil auxiliaire. Le guide peut vouloir dire : ne placez jamais le mot de passe source dans l’attribut auth:. Cette interprétation rendrait compatibles un générateur distant et une base qui ne conserve que l’empreinte. Mais elle ne répondrait toujours pas à la question de garde pendant la génération. L’utilisateur ne devrait pas avoir à deviner la portée du mot « partager ».

Le code chargé par la page ajoute une frontière de navigateur. Le HTML appelle le script Turnstile depuis challenges.cloudflare.com, puis des ressources jQuery, Mustache et main.js. Un script tiers exécuté dans un document peut disposer de capacités sur ce document ; c’est pourquoi le guide OWASP consacré au JavaScript tiers le traite comme un risque de contrôle des changements et de divulgation de données sensibles. Ce modèle de risque n’est pas une accusation. La présence de Turnstile ne démontre pas que Cloudflare lit ou reçoit le mot de passe.

L’examen du main.js lié permet de retirer une conclusion tentante mais fausse. Dans la version capturée, ce fichier ne contient ni myForm, ni plaintextpassword, ni BCRYPT, ni fonction de génération pour ce formulaire. Il initialise une autre interface, repérée par create-container, destinée à charger et sauvegarder des objets WHOIS. Cette interface manipule un autre champ de mot de passe et un autre point de sauvegarde. Elle ne prouve pas un hachage local de WHOIS Crypt. Elle ne prouve pas davantage l’absence de toute intervention d’une bibliothèque, d’une réponse dynamique, d’une extension ou du serveur.

Le bon niveau de certitude est donc étroit. Le formulaire déclare une réception distante. Un fichier local inspecté ne montre pas de transformation préalable pour ce champ. Le reste demeure inconnu. Nous n’avons ni le gestionnaire serveur, ni sa configuration, ni les journaux du mandataire inverse, ni les traces applicatives, ni une politique propre à ce champ. Ce sont précisément les pièces qu’un reçu opérationnel devrait relier.

La politique de confidentialité d’AFRINIC fournit une gouvernance générale réelle. Elle présente AFRINIC comme responsable du traitement, inclut les services WHOIS parmi les surfaces de collecte, limite l’accès aux personnes désignées, impose des garanties aux tiers et rattache la conservation aux finalités de l’organisation et aux obligations légales. Ces engagements comptent. Ils ne précisent pas si le corps d’une requête Crypt est journalisé, si plaintextpassword est filtré avant l’observabilité, combien de temps la valeur existe, ni quel script peut l’atteindre.

Le journal est l’endroit où une ambiguïté architecturale devient un test concret. L’OWASP classe les mots de passe d’authentification parmi les données qui ne devraient généralement pas être enregistrées directement ; il recommande de les retirer, les masquer, les assainir, les hacher ou les chiffrer quand un événement doit être tracé. Cette recommandation ne prouve rien sur les pratiques d’AFRINIC. Elle transforme toutefois le nom public du champ en contrôle testable : la valeur ne devrait apparaître ni dans les journaux applicatifs, ni dans ceux du proxy, ni dans les traces, les erreurs, l’analytique ou les dossiers d’assistance.

Une empreinte correcte ne peut fournir ce renseignement. BCRYPT protège la représentation stockée contre certains modes d’attaque ; il n’efface pas rétrospectivement les systèmes qui ont vu la préimage. On peut obtenir le bon résultat cryptographique au bout d’un chemin dont la garde est mal documentée. C’est pourquoi la sécurité de l’algorithme et la responsabilité du service ne sont pas le même débat.

Deux architectures seraient cohérentes. Dans la première, le navigateur calcule localement l’empreinte au moyen d’un code publiable et auditable. Le secret ne quitte pas l’appareil, et les scripts tiers sont isolés de son contrôle. Il faudrait encore prouver l’intégrité des dépendances et le comportement réel, non afficher simplement la mention « local ».

Dans la seconde, AFRINIC conserve un service distant. La page dit alors clairement que le serveur reçoit un nouveau mot de passe non réutilisé par HTTPS, le hache, exclut sa valeur des journaux et des traces, ne conserve aucune préimage et borne les accès de ses prestataires. Le traitement serveur n’est pas une faute par nature. L’absence d’explication est le problème mesurable.

Changer seulement type="text" en type="password" améliorerait la discrétion visuelle et la sémantique du formulaire, mais ne modifierait pas le destinataire. De même, afficher un cadenas ne documenterait pas la durée de vie au serveur. Chaque contrôle doit répondre à sa propre question : qui voit la saisie, qui reçoit la requête, où se fait le calcul, qui peut lire la mémoire et quelles copies persistent.

Le reçu doit aussi porter une version et une date. Le formulaire, Turnstile, le mandataire inverse, la collecte des erreurs et l’analytique peuvent évoluer séparément. Une vérification ancienne ne certifie pas silencieusement une nouvelle chaîne. Après une modification importante, une valeur synthétique autorisée permet de refaire le parcours, de nommer les composants couverts et de consigner les exceptions. La valeur et la configuration interne peuvent rester secrètes ; la frontière vérifiée, elle, doit être publique.

On relierait ainsi trois niveaux aujourd’hui dispersés. La politique de confidentialité fixe une responsabilité générale, le guide explique le comportement attendu du membre et le reçu d’ingénierie décrit la vie d’un champ précis. Une assurance telle que « nous ne journalisons pas les mots de passe » gagne en poids lorsqu’elle est accompagnée d’une observation contrôlée montrant l’absence du marqueur dans chaque puits nommé. Elle ne devient pas pour autant une garantie éternelle : son horodatage en fixe honnêtement la portée.

Sources