Zusammenfassung

  • RFC 2069 ersetzte Basics übertragbares Klartextpasswort durch eine Challenge-Response-Berechnung; das serverseitige H(A1) blieb jedoch ein auf den Realm begrenztes Passwortäquivalent.
  • Die Grundantwort band dieses Material an Nonce, HTTP-Methode und Request-URI. Sie verschlüsselte keine Inhalte und bewies weder die Integrität aller Felder noch Absicht, Autorisierung oder Wirkung.
  • Ein Nonce mit Clientadresse und Zeitstempel konnte ohne Transaktionszustand räumlich und zeitlich begrenzen. Erst ein Speicher bereits verwendeter Antworten erlaubte eine belastbare Einmal-Aussage.

Kompartimentierung ist keine Entwaffnung

Die Basic-Anmeldung des RFC 1945 stellte Benutzername und Passwort in Base64 dar. Eine Darstellung schützt nicht vor einem Beobachter: Er konnte das Passwort gewinnen und anderswo wiederverwenden. Der RFC 2069 führte im Januar 1997 Digest Access Authentication ein. Der Server stellte eine Nonce-Challenge, der Client berechnete eine Antwort, das Passwort selbst lief nicht mehr als Klartext über die Leitung. Der zeitgleiche RFC 2068 lieferte den HTTP/1.1-Rahmen.

Der Entwurf begrenzte seinen Anspruch ausdrücklich. Digest sei eine schwache Zugriffsauthentisierung, verschlüssele den Inhalt nicht und regele nicht, wie das anfängliche Passwort sicher vereinbart werde. Auch Man-in-the-Middle, falsche Server, Wörterbuchsuche und Replay blieben relevant. Der RFC-Editor-Eintrag belegt Dokumentstatus und Nachfolge, nicht Implementierung oder Einsatz.

Die Gleichung als Beweisverzeichnis

Das konkret beschriebene H war MD5 aus RFC 1321:

A1 = username : realm : password
A2 = Method : request-URI
response = KD(H(A1), nonce : H(A2))

Der Realm steht in A1, Methode und URI stehen in A2, und die Nonce verbindet die Antwort mit einer Server-Challenge. Ein Treffer belegt daher, dass jemand Material besitzt, das für diesen Benutzer in diesem Realm und für diese ausgewählten Request-Werte eine gültige Antwort erzeugt.

Der Server muss zusätzlich prüfen, ob die in Authorization wiederholte uri tatsächlich die bediente Ressource bezeichnet. Ein Proxy kann die Request-Line verändern; ein mathematisch passender Wert darf nicht an ein anderes Ziel umgehängt werden.

Was nicht in der Gleichung steht, wird durch sie nicht automatisch bewiesen. Andere Header, Transportweg und Antwort fehlen. Inhalt wird nicht verschlüsselt. Menschliche Absicht, Kontozuordnung, Berechtigung, Geschäftskorrektheit und einmaliger Commit sind keine Hash-Eingaben. Für POST und PUT bot RFC 2069 ein getrenntes optionales Entity-digest über Body und ausgewählte Metadaten. Schon diese Option widerlegt die Vorstellung einer vollständigen Nachrichtensignatur durch die Grundantwort.

Die Verifier-Datei trug ausführbare Macht

Zur Prüfung genügte dem Server H(A1); er brauchte das Passwort nicht im Klartext. Die Speicherungsanalyse des RFC formuliert die Konsequenz ohne Euphemismus: Wird die Datei gestohlen, kann der Angreifer sofort auf Dokumente des zugehörigen Realms zugreifen. Eine Entschlüsselung ist dafür nicht nötig. Die Datei ist zu schützen, als enthielte sie unverschlüsselte Passwörter.

Das Wort Passwortäquivalent bleibt auf den Realm beschränkt. Da der Realm in A1 steckt, lässt sich ein Verifier nicht automatisch in einem anderen Realm einsetzen. Innerhalb seines Bereichs ist er jedoch kein ungefährlicher Hash, sondern der geheime Schlüssel der Response-Berechnung. Schwache Passwörter können außerdem offline geraten werden.

Diese Funktionssicht verändert die Inventur. Backup, Hochverfügbarkeitskopie und ausgelagerter Authentisierungsdienst enthalten jeweils eine Fähigkeit, Akzeptanz herzustellen. Unlesbarkeit ist keine Zugriffskontrolle.

Ein gültiges Zeitfenster hat kein Gedächtnis

RFC 2069 empfahl eine Nonce etwa aus:

H(client-IP : timestamp : server-private-key)

Der Server kann sie beim Eingang neu berechnen, an eine scheinbare Adresse binden und verfallen lassen, ohne jede ausgegebene Nonce zu speichern. Das ist eine elegante zustandsarme Lösung. Sie beantwortet aber nur, ob eine Challenge korrekt und noch nicht abgelaufen ist. Sie weiß nicht, ob dieselbe Authorization schon akzeptiert wurde.

Für einen einfachen GET hielt der RFC Replay häufig für wenig nützlich, weil die URI gebunden war und der Lauscher das Dokument schon gesehen hatte. Er warnte dennoch vor GET-Aufrufen mit Wirkung und besonders vor POST/PUT: Wiederholung kann gefälschte Formulardaten oder Dateien erzeugen.

Wenn kein Replay tolerierbar ist, muss der Server Einmalantworten verwenden und bereits genutzte Digests bis zum Nonce-Ablauf merken. Die stärkere Aussage kostet Speicher, Abfrage, Löschung und Kollisionsbehandlung. In einem Cluster kommt Zustandskohärenz hinzu. Der Hash liefert keine dieser Betriebsleistungen von selbst.

Nachfolger machten die fehlenden Zustände explizit

RFC 2617 ersetzte RFC 2069; der offizielle Eintrag nennt diese Beziehung und Probleme mit optionalen Elementen des Vorgängers. Der neue qop-Pfad führte Client-Nonce cnonce und Nonce-Zähler nc ein. Hält der Server einen eigenen Zähler, kann er denselben Wert beim zweiten Auftreten als Replay erkennen. qop=auth-int nimmt den Body-Hash in A2 auf. Ohne qop bleibt aus Kompatibilitätsgründen die alte 2069-Formel bestehen.

RFC 7616 und sein RFC-Editor-Eintrag ergänzten SHA-256 und SHA-512/256 und rieten von MD5 ab. Die H(A1)-Warnung blieb: Ein gestohlener Verifier öffnet den Realm und ist wie Klartext zu schützen. Algorithmusagilität heilt keine schwachen menschlichen Passwörter; zusätzlich wird HTTPS empfohlen.

Die moderne HTTP-Semantik des RFC 9110 hält eine weitere Trennung fest: Credentials können eine Autorisierungsentscheidung informieren, sind aber weder die Entscheidung noch die ausgeführte Wirkung.

Aus einem Treffer keine Biografie bauen

Ein gültiger Digest zu PUT /record zeigt zunächst, dass ein Knoten eine Beziehung zwischen Secret, Nonce, Methode und URI akzeptierte. Für eine belastbare Rekonstruktion fehlen möglicherweise Algorithmus, qop, Body-Abdeckung, Replay-State, Principal-Mapping, geltende Berechtigung, Transaktions-ID und Resultat.

Lu Hengs Running-Code Primacy verlangt Belege aus laufender Validierung statt Autorität durch Veröffentlichung. Seine Minimum Initial Specification trennt die deterministische gemeinsame Regel von späteren lokalen Entscheidungen. Die Digest-Gleichung ist gemeinsam; Realm-Verwaltung, Nonce-Lebensdauer, State-Budget und Autorisierung bleiben lokal.

Die Analyse der Reality Layers verhindert, dass ein gültiges Symbol die Macht über spätere Ausführungsschichten beansprucht. Ein Hash-Treffer ist ein Beleg. Er ist keine Vollmacht, Absicht oder Wirkung zu behaupten.

Quellen