Zusammenfassung

  • RFC 1938 akzeptierte x, wenn H(x) dem gespeicherten Prüfwert entsprach, und speicherte danach x selbst: Der Erfolg schob eine absteigende Einwegkette weiter.
  • „Einmal“ setzte deshalb eine atomare Aktualisierung, Schutz vor gleichzeitigen Sitzungen sowie geplante Erschöpfung und Neuinitialisierung voraus.
  • Die geheime Passphrase lief nicht über das Netz; die Sitzung wurde dadurch aber weder verschlüsselt noch allgemein gegen aktive Angriffe geschützt. HOTP und TOTP verwendeten andere bewegliche Zustände.

Erfolg vernichtete seine eigene Voraussetzung

Zwei identische Antworten können nacheinander unterschiedliche Wahrheitswerte haben. Nach RFC 1938 berechnet der Server für die eingereichte Antwort x den Wert H(x). Stimmt er mit dem gespeicherten Verifikator überein, wird x akzeptiert und anschließend selbst zum neuen Verifikator. Ein späteres Replay von x führt nur noch zum alten Bezugspunkt.

Der aktuelle RFC-Editor-Eintrag datiert den Proposed Standard von N. Haller und C. Metz auf Mai 1996 und verweist auf RFC 2289 als Ablösung. Normativ ist die Sache damit geordnet. Historisch interessant bleibt, dass der Erfolg kein bloßes Lesen, sondern eine gemeinsam sichtbare Zustandsänderung war.

Der Generator verbindet eine geheime Passphrase mit einem öffentlichen Seed und wendet eine Einwegfunktion wiederholt an. Bei Kettentiefe N wird zuerst H^N(S), dann H^(N-1)(S) vorgelegt. Der Server benötigt nicht die Passphrase, sondern den zuletzt akzeptierten 64-Bit-Wert und die aktuelle Sequenzposition. Von einem Glied aus lässt sich in Richtung bereits verbrauchter Werte rechnen, nicht zur nächsten erwarteten Antwort.

Die Konstruktion entwickelte das in RFC 1760 beschriebene Bellcore-System S/KEY weiter. Sein enger Zweck war der Schutz vor passiv mitgelesenen, wiederverwendbaren Login-Passwörtern. Eine beobachtete Antwort verlor nach dem legitimen Zustandsfortschritt ihren künftigen Wert.

Der Server speichert also kein Ausgangsgeheimnis, aber sehr wohl maßgeblichen Zustand. Ein altes Backup, eine verspätete Replik oder zwei ungeordnete Schreibvorgänge verändern, welche Antwort als gültig gilt.

Sechs Wörter waren eine Kodierung

Die Challenge nannte Algorithmus, Sequenz und Seed, etwa otp-md5 487 dog2. MD5 musste, SHA sollte und MD4 durfte unterstützt werden. Beide Seiten mussten denselben Algorithmus wählen; die schwächste zugelassene Variante konnte die Belastbarkeit des Systems bestimmen.

Für Menschen waren 64 Bit unbequem. Deshalb kodierte ein Wörterbuch mit 2.048 Einträgen den Wert in sechs Wörtern zu je 11 Bit. Die insgesamt 66 Bit enthielten zwei Prüfbits gegen bestimmte Eingabe- und Dekodierfehler. Diese waren kein zweiter Faktor, und die Bedeutung der Wörter fügte kein Geheimnis hinzu.

Ein Server musste die Standardwortform und Hexadezimaldarstellung akzeptieren und sollte auch alternative Wörterbücher verstehen. Groß- und Kleinschreibung, Segmentierung und Normalisierung lagen somit auf dem Interoperabilitätspfad. Oberflächenbehandlung konnte eine mathematisch richtige Antwort verändern.

Das Rennen entscheidet die Transaktion

RFC 1938 beschreibt einen Angreifer, der fast alle sechs Wörter hört, den Rest errät und vor dem legitimen Benutzer eintreffen will. Konforme Server müssen sich dagegen schützen. Als Möglichkeit nennt das Dokument, parallele Authentifizierungssitzungen eines Kontos zu sperren; ein Timeout soll verhindern, dass daraus ein dauerhafter Denial of Service wird.

Ein ähnliches Rennen entsteht intern. Lesen zwei Prozesse denselben alten Verifikator, akzeptieren beide x und erzeugen Sitzungen, bevor der neue Zustand festgeschrieben ist, hat ein verbrauchbarer Nachweis zwei Erfolge erzeugt. Der Hash stimmt, die Transaktion nicht. Vergleich und Fortschritt müssen atomar oder gleichwertig serialisiert sein.

Auch die Kette endet. Die Sequenznummer misst verbleibende Antworten. Bei der Neuinitialisierung muss sich Seed oder Passphrase ändern; dieselbe Kombination würde bereits beobachtbare Werte reproduzieren. Eine Klartextübertragung der Passphrase zur Reparatur widerspricht dem Schutzziel.

Eine empfohlene Erneuerung konnte ein altes OTP als Autorisierung verlangen. Bei Sequenz eins lässt sich die letzte Antwort noch zum Login verbrauchen, danach fehlt aber eine weitere für die Erneuerung. Vor null zu handeln gehört zur Protokollverfügbarkeit.

Ein Nachfolger, keine universelle Sitzungssicherheit

Der Datensatz zu RFC 2289 nennt Februar 1998 und die Ablösung von RFC 1938. Der Nachfolgetext behält die absteigende Kette bei, ergänzt Testvektoren und präzisiert Betriebshinweise. Die Empfehlung von IPsec gegen TCP-Verbindungsübernahme zeigt die Grenze: Ein gültiges OTP verschlüsselt die anschließende Sitzung nicht.

Spätere Verfahren bewegten anderen Zustand. HOTP verwendet ein gemeinsames Geheimnis und einen aufsteigenden Zähler; der Prüfer kann in einem Vorwärtsfenster resynchronisieren und schreitet nach Erfolg weiter. TOTP nutzt ein Zeitintervall als beweglichen HOTP-Faktor und darf ein im selben Intervall erfolgreich geprüftes OTP nicht erneut akzeptieren. Der Vergleich belegt keine Abstammung von S/KEY.

Gemeinsam ist die Einsicht, dass „stimmt der Code?“ nicht genügt. Der gültige Zustand, tolerierte Nachbarschaft, Verbrauch durch Erfolg und Konsens mehrerer Prüfer müssen feststehen.

Der Nachweis bleibt begrenzt. RFC 1938 bot weder Vertraulichkeit noch allgemeinen Schutz vor aktiven Angriffen oder Social Engineering. Die Annahme bindet eine Antwort an den konfigurierten Kontozustand. Sie beweist nicht allein Befugnis, Sitzungsschutz, Ausführung, dauerhaften Zugriff oder die bürgerliche Identität der Person.

Der Mechanismus unter dem Etikett

Heng Lus Gedanke vom Vorrang laufenden Codes verschärft die Prüfung: Eine Spezifikation kann einmaligen Fortschritt fordern; erst Absturz, Replikation und Wiederherstellung zeigen, ob die Implementierung tatsächlich nur eine Geschichte zulässt.

Eine minimale Anfangsspezifikation kann den gemeinsamen Kern knapp halten: Kette, Challenge, Darstellung, Prüfung und Zustandswechsel. Lokale Freiheit endet dort, wo eine konsumierbare Antwort zwei Sitzungen öffnet.

Die Trennung von Realitätsebenen hält den Namen ehrlich. „Einmalpasswort“ ist eine symbolische Behauptung. Operativ besteht sie aus gespeichertem Verifikator, atomarem Schreiben, Konkurrenzregel, endlicher Kette und kontrollierter Neuinitialisierung. Driften diese Ebenen auseinander, kann eine Antwort rechnerisch richtig und historisch falsch sein.

RFC 1938 zeigt damit: Ein Beweis kann die Welt verändern, in der der nächste Beweis beurteilt wird. Authentifizierung ist dann kein Lesen einer Wahrheit, sondern eine geordnete, verantwortete und erinnerte Schreiboperation.

Quellen

  1. RFC Editor — aktueller Eintrag zu RFC 1938
  2. RFC 1938 — A One-Time Password System
  3. RFC 1760 — The S/KEY One-Time Password System
  4. RFC Editor — aktueller Eintrag zu 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