Zusammenfassung

  • Die aktuelle WHOIS-Crypt-Seite von AFRINIC deklariert ein POST-Formular zur eigenen Herkunft. Das als Passwort beschriftete Eingabefeld ist type="text" und wird unter dem Namen plaintextpassword übermittelt. Für diese Recherche wurde kein Wert eingegeben und nichts abgesendet.
  • Das Mitgliedshandbuch sagt, nur der Hash solle mit AFRINIC geteilt und das Klartextpasswort vom Mitglied sicher verwahrt werden. Zwischen dieser Anweisung und dem entfernten Generator fehlt eine überprüfbare Beschreibung des vorübergehenden Gewahrsams.

Eine kleine Zeile HTML legt hier mehr Verantwortung offen als der fertige Hash. Sobald BCRYPT seine Arbeit beendet hat, sieht das Ergebnis wie das eigentliche Sicherheitsobjekt aus. Es kann in einem auth:-Attribut stehen und schützt einen gespeicherten Prüfwert gegen bestimmte Angriffe. Nicht enthalten ist die Geschichte des Passworts, das zuvor irgendwo vorhanden sein musste.

AFRINICs öffentliche WHOIS-Werkzeugseite verweist für BCRYPT-PW auf eine gesonderte Crypt-Anwendung. Deren am 14. September 2026 gesicherter HTML-Quelltext nennt das Formular myForm, setzt method="POST" und verwendet die relative Aktion ?lang=en#cli. Zum sichtbaren Label „Password“ gehört kein HTML-Passwortfeld, sondern ein input type="text". Kennung und Übermittlungsname lauten beide plaintextpassword. Der Knopf verspricht „Generate hash“.

Wir haben dieses Formular nicht benutzt. Weder ein echtes Passwort noch ein synthetischer Testwert wurde eingetragen. Es gab keinen Klick, keine Formularanfrage, keine Verkehrsmessung, keinen Aufruf der serverseitigen Verarbeitung und keine Änderung eines WHOIS-Objekts. Der Befund betrifft die veröffentlichte Anweisung an einen Browser, nicht den beobachteten Ablauf einer Transaktion.

Der HTML-Standard macht die Bedeutung der Anweisung nachvollziehbar. Formulare bestehen aus Steuerelementen, deren eingegebene Daten zur weiteren Verarbeitung an einen Server gesendet werden können. Seine Entwicklerfassung beschreibt Parameter in einem HTTP-POST-Body als gewöhnliches Muster. Da die Aktion relativ ist, wird sie auf derselben Herkunft whois-web.afrinic.net aufgelöst. Bei einer Ausführung gemäß Markup würde der Browser also den Anwendungswert des benannten Felds an einen AFRINIC-Endpunkt liefern.

Das Wort Klartext braucht eine Grenze. Die Werkzeugadresse verwendet HTTPS. TLS soll das Belauschen und Verändern des Transports zwischen Endpunkten verhindern. Keine der gesicherten Quellen zeigt ein auf dem Netz lesbares Passwort. Klartext meint hier den Anwendungswert vor dem Hash, nicht einen unverschlüsselten Draht. Ein verschlüsselter Kanal kann diesen Wert sicher zu einem Empfänger bringen; er macht den Empfänger nicht zu einer lokalen Berechnung im Gerät des Mitglieds.

Empfangen ist wiederum nicht gleich Speichern. Ein sorgfältiger Server kann den Wert nur kurz im Arbeitsspeicher halten, BCRYPT berechnen, ihn aus Protokollen und Traces ausschließen und sofort verwerfen. In anderen Architekturen können allgemeine Proxys, Fehlerdienste oder Beobachtungsplattformen Anfragedaten kopieren, falls keine gezielte Sperre besteht. Wir haben weder Servercode noch Proxy-Konfiguration, Protokolle, Speicher, Laufzeitspuren oder Vorfallakten geprüft. Welche Variante vorliegt, bleibt offen.

Damit ist nur eine Empfangsfläche belegt. Es gibt keinen Beleg für ein Leck, einen Vorfall, eine Übernahme oder auch nur für eine persistente Kopie. Gerade diese Beschränkung macht die Frage brauchbar: AFRINIC kann die fehlenden Eigenschaften benennen und prüfen, ohne erst einen Schaden behaupten zu müssen.

Das eigene Mitgliedshandbuch liefert den entscheidenden Gegenbeleg. Beim Maintainer-Objekt empfiehlt es, einen BCRYPT-Hash aus dem Klartextpasswort zu erzeugen. Danach heißt es, nur der Hashwert solle mit AFRINIC geteilt werden; das Mitglied solle das Klartextpasswort sicher verwahren. Das wirkt wie eine eindeutige Zuständigkeitsverteilung: Der geheime Ausgangswert bleibt beim Mitglied, der prüfbare Hash geht an das Register.

Eine faire Lesart kann diese Aussage mit einem Servergenerator vereinbaren. „Nur den Hash teilen“ könnte ausschließlich den endgültigen Inhalt des WHOIS-Objekts betreffen. Der Generator nähme das Passwort kurz entgegen, schriebe aber nur den Hash in die nachfolgende Arbeitsweise. Dann widerspricht das Formular der Anleitung nicht zwangsläufig. Doch es führt eine vorangehende Übermittlung ein, deren Reichweite das Wort „teilen“ nicht erklärt.

Ein Mitglied kann denselben Satz ebenso als Zusage verstehen, der Ausgangswert verlasse sein Gerät nie. Dann wäre ein entfernter POST ein anderes Modell. Die Quellen beweisen nicht, welche Reichweite AFRINIC beabsichtigt. Daher wäre es falsch, sofort einen Rechtsverstoß, eine gebrochene Datenschutzgarantie oder eine Täuschung zu erklären. Bewiesen ist ein unaufgelöster Umfang der öffentlichen Anweisung.

Auch die Feldart ist ein enger, sichtbarer Befund. Im HTML-Standard ist type="password" der Zustand für vertrauliche Eingaben, dessen Steuerelement die Zeichen verdeckt. type="text" ist ein gewöhnliches Textfeld. Die gesicherte Seite verwendet letzteres. Das beweist weder einen Schulterblick noch eine Offenlegung und sagt nichts über Kostenparameter, Salt oder Korrektheit von BCRYPT. Es zeigt lediglich, dass der Browser keine Passwortmaskierung angefordert bekommt.

Eine Umstellung auf type="password" wäre sinnvoll, aber nicht hinreichend. Sie verbessert die Anzeige und die semantische Kennzeichnung des Felds. Das POST-Ziel bliebe gleich, ebenso die unbeantworteten Fragen zu Logs, Arbeitsspeicher und Skriptzugriff. Eine Oberfläche kann die Architektur nicht durch Maskierung ersetzen.

Die Seite lädt zudem ausführbaren Code in denselben Dokumentkontext. Cloudflare Turnstile kommt von challenges.cloudflare.com; jQuery, Mustache und main.js werden über lokale Pfade eingebunden. OWASPs Leitfaden zu JavaScript von Dritten beschreibt solchen Code als Grenze für Änderungskontrolle und sensible Daten, weil im Dokument ausgeführte Skripte grundsätzlich mit dessen Kontext interagieren können und sich die gelieferte Fassung ändern kann.

Das ist ein Risikomodell, keine Feststellung über Cloudflare. Der Turnstile-Verweis beweist nicht, dass der Anbieter plaintextpassword gelesen, empfangen, behalten oder weitergeleitet hat. Die tatsächliche Browserausführung wurde nicht beobachtet. Der angemessene Schluss lautet nur: Skriptfähigkeiten und Isolation gehören zum Nachweis für ein Feld dieser Art.

Der verlinkte lokale main.js schränkt eine weitere naheliegende Behauptung ein. In der gesicherten Fassung kommen myForm, plaintextpassword, BCRYPT und ein Crypt-Generator nicht vor. Das Skript initialisiert stattdessen eine andere Ansicht, wenn ein create-container vorhanden ist. Dort lädt und bearbeitet es WHOIS-Objektvorlagen und sendet ein Objekt mit einem eigenen Editor-Passwort an eine Speicherfunktion.

Diese andere Oberfläche ist kein Beleg dafür, dass das Crypt-Passwort im Browser gehasht wird. Umgekehrt kann das Schweigen einer Datei nicht sämtliche Bibliotheken, Browser-Erweiterungen, dynamischen Antworten, späteren Versionen oder den Server ausschließen. Statische Evidenz darf nur das Gewicht der untersuchten Datei tragen.

AFRINICs aktuelle Datenschutzrichtlinie ist eine positive institutionelle Quelle. Sie bezeichnet AFRINIC als Verantwortlichen, nennt WHOIS-Dienste unter den Erhebungsflächen, begrenzt den Zugriff auf beauftragte Beschäftigte, verlangt Schutzpflichten von Dritten und knüpft Aufbewahrung an organisatorische oder gesetzliche Zwecke. Es wäre unzutreffend, daraus ein regelloses Umfeld zu machen.

Eine allgemeine Richtlinie ist jedoch kein feldbezogener Verarbeitungsbeleg. Sie verrät nicht, ob der POST-Body im Reverse Proxy ausgefiltert wird, ob Fehlerberichte Parameter übernehmen, ob ein Trace Stichproben zieht, ob Support-Pakete den Wert enthalten oder wie lange die Vorstufe im Speicher lebt. Governance und technische Lebenszyklusbeobachtung ergänzen einander; die erste beweist die zweite nicht automatisch.

Bei Protokollen lässt sich die Lücke am klarsten testen. OWASP zählt Authentifizierungspasswörter zu den Daten, die normalerweise nicht unmittelbar aufgezeichnet werden sollten. Falls ein Ereignis gespeichert werden muss, sollen sensible Werte entfernt, maskiert, bereinigt, gehasht oder verschlüsselt werden. Wir haben kein einziges AFRINIC-Protokoll gesehen und behaupten daher keine tatsächliche Aufzeichnung.

Der öffentlich sichtbare Feldname bietet stattdessen eine prüfbare Bedingung. Der Wert von plaintextpassword sollte in Anwendungs- und Proxy-Logs, verteilten Traces, Analyseereignissen, Fehlerberichten und Support-Aufzeichnungen fehlen. „Die Verbindung ist HTTPS“ beantwortet diese Bedingung nicht, denn TLS kontrolliert den Weg zum Endpunkt, nicht dessen interne Kopien.

Auch Fehlerpfade gehören in die Prüfung. Ein erfolgreicher Handler kann den Wert sauber verwerfen, während ein Timeout, eine ungültige Eingabe, eine abgewiesene Turnstile-Prüfung oder eine Ausnahme einen allgemeinen Diagnosedienst aktiviert. Es gibt keinen Beleg, dass AFRINIC sich so verhält. Der Punkt ist methodisch: Ein Nachweis nur für die ideale Antwort deckt die Stellen nicht ab, an denen sensible Daten gewöhnlich überraschend sichtbar werden.

Ein korrekter BCRYPT-Ausgabewert ist ebenfalls kein Gewahrsamsbeleg. Er bestätigt einen Teil der Berechnung. Er bestätigt nicht, dass Analysewerkzeuge nichts kopierten, ein Wiederholungsmechanismus keinen Request behielt, Skripte nicht zugreifen konnten oder Diagnoseinformationen für Supportkräfte unlesbar blieben. Kryptografische Richtigkeit und Minimierung des Eingabepfads sind getrennte Eigenschaften.

Zwei Architekturen können das Problem schlüssig lösen. In der ersten wird der Hash im Browser berechnet. Dafür braucht es überprüfbaren Code, kontrollierte Abhängigkeiten, Integritätsnachweise, eine Trennung vom Drittcode und den Beleg, dass ausgehende Anfragen den Ausgangswert nicht enthalten. Das Wort „lokal“ allein wäre kein Nachweis.

In der zweiten bleibt die Berechnung serverseitig. Dann sollte die Seite vor der Eingabe erklären, dass ein AFRINIC-Endpunkt ein neues, nicht wiederverwendetes Passwort über HTTPS empfängt, nur für den Hash verarbeitet, aus Logs und Traces ausschließt, keinen Klarwert behält und den Zugriff weiterer Verarbeiter begrenzt. Fernverarbeitung ist nicht von Natur aus unzulässig. Unbenannter Empfänger, unklare Dauer und unbelegte Löschung sind die kontrollierbaren Fragen.

Das Handbuch muss die gewählte Architektur widerspiegeln. Meint „nur der Hash“ lediglich das WHOIS-Objekt, sollte dieser Umfang dort stehen. Meint es den gesamten Erzeugungsweg, passt das entfernte POST-Formular nicht dazu. In beiden Fällen sollte niemand ein bestehendes oder anderswo wiederverwendetes Passwort eingeben, nur um den Generator zu prüfen. Diese Recherche hat das nicht getan.

Der Nachweis braucht außerdem Version und Datum. Formular, Turnstile-Einbindung, Reverse Proxy, Fehlersammlung und Analyseplattform können sich unabhängig ändern. Eine Prüfung der alten Kombination darf die nächste nicht stillschweigend zertifizieren. Nach einer wesentlichen Änderung lässt sich ein autorisierter synthetischer Marker erneut verfolgen; erfasst werden die betroffenen Komponenten und bekannte Ausnahmen. Marker und interne Konfiguration müssen nicht öffentlich sein, wohl aber Grenze und Geltungszeit.

So treffen drei Ebenen zusammen. Die Datenschutzrichtlinie ordnet allgemeine Verantwortung zu. Das Mitgliedshandbuch beschreibt den Umgang mit einem Maintainer. Der technische Nachweis zeichnet den Lebenszyklus eines benannten Felds. Eine Zusicherung wie „Wir protokollieren keine Passwörter“ gewinnt durch die kontrollierte Beobachtung, dass der Marker in jedem benannten Speicher fehlt. Beides ist keine ewige Garantie, doch die Datierung verhindert, dass eine begrenzte Prüfung zu einer unbegrenzten Behauptung anwächst.

Quellen