Zusammenfassung

  • Bei den Angriffen aus RFC 10027 authentifiziert sich der Nutzer korrekt, genehmigt aber einen Ablauf, den das Gerät des Angreifers gestartet hat. Es fehlt der Nachweis, dass Anfrage und sichtbarer Kontext zusammengehören.
  • Ein gültiger QR- oder Nutzercode kann einen offenen Vorgang bezeichnen. Er beweist nicht, wer ihn präsentiert hat, ob der Nutzer ihn erwartet und welcher Client die Token erhält.
  • Daniel Fett ist neben Pieter Kasselman und Filip Skokan Mitautor der BCP. Ihre Anleitung verbindet Protokollwahl, Nähe, vertrauenswürdige Geräte, begrenzte Rechte, Erkennung und Wiederherstellung, ohne eine Einzelmaßnahme zur Garantie zu erklären.

Geräteübergreifende Abläufe verlagern eine schwierige Anmeldung von Fernseher, Terminal oder Konferenzdisplay auf das persönliche Telefon. Das ist praktisch und kann verhindern, dass Anmeldedaten auf einem gemeinsam genutzten Gerät eingegeben werden. Die Oberfläche macht aus zwei Geräten eine scheinbar zusammenhängende Handlung: Code anzeigen, scannen, zustimmen.

Technisch bleiben es zwei Rollen. Das Consumption Device startet die Anfrage und soll eine Fähigkeit erhalten. Das Authorization Device authentifiziert den Nutzer und sammelt die Entscheidung. Dazwischen transportiert der Mensch einen QR-Code, einen kurzen Code oder die Bedeutung einer Push-Nachricht. Genau dieser Kontextkanal ist häufig nicht authentifiziert.

Ein Angreifer kann auf dem eigenen Rechner eine Anfrage starten, den vom echten Server ausgegebenen Code nehmen und ihn mit einer plausiblen Supportgeschichte an das Opfer senden. Das Opfer scannt, erreicht den echten Anbieter, schließt die MFA ab und genehmigt. Der Server kennt nun die Person. Er weiß nicht zwingend, vor welchem Initiator sie zu stehen glaubt.

Erfolgreiche Identität, falsche Zuordnung

„MFA umgangen“ wäre die falsche Diagnose. Die Faktoren können die Kontoinhaberin oder den Kontoinhaber korrekt bestätigt haben. Nicht gebunden wurden Initiator, Zweck, menschliche Erwartung und Empfänger der Berechtigung.

RFC 10027 nennt die Autorisierungsvariante Cross-Device Consent Phishing. Bei Cross-Device Session Phishing wird ein Artefakt weitergegeben, das eine bereits authentifizierte Sitzung verschiebt. Der Angreifer benötigt daher nicht unbedingt das Passwort. Er kann Access- und Refresh-Token oder eine nutzbare Sitzung erhalten. Ein Passwortwechsel allein belegt keine Bereinigung.

Der Code ist dennoch Evidenz — nur keine umfassende. Er kann gültig, einmalig und nicht abgelaufen sein. Das sagt nichts Sicheres über den Präsentierenden, die erwartete Aufgabe, die Nähe beider Geräte, den Umfang oder den begünstigten Client. Eine authentische Serverreferenz kann Teil eines erfundenen menschlichen Zusammenhangs sein.

Was Daniel Fetts Arbeit hier sichtbar macht

Fett beschreibt sich auf seiner Website als Sicherheitsberater für Identität und Webprotokolle und als Mitwirkenden an OAuth und OpenID Connect in OpenID Foundation und IETF. Der IETF-Eintrag verbindet ihn mit RFCs zu Issuer Identification, Proof of Possession und OAuth-Sicherheit. RFC 10027 ist Gemeinschaftsarbeit dreier Autoren; daraus folgt weder Alleinautorschaft noch Kontrolle über ein Produkt.

Die relevante Methode lautet, Eigenschaften nicht zu vermischen. Formale Analyse kann Angriffe innerhalb eines Modells ausschließen, das Protokollschichten, Angreiferfähigkeiten und Ziele festlegt. Sie zertifiziert keine ausgelassenen Implementierungsdetails. Ein erfolgreicher kryptografischer Schritt kann keine Beziehung beweisen, die im Schritt nicht vorkommt.

Darum braucht „authentifiziert“ Ergänzungen: Wer wurde gegenüber wem für welche Transaktion geprüft? Nutzeridentität, startendes Gerät, Anfragekontext, Absicht, Freigabe, Tokenempfänger und Ressourcennutzung sind verschiedene Behauptungen. Ein echter Server kann eine vom Angreifer gestartete Anfrage zeigen. Ein sendergebundenes Token kann an den Schlüssel genau des feindlichen Clients gebunden sein.

Maßnahmen mit klaren Restlücken

Kurzlebige, einmalige und eindeutige Codes begrenzen Wiederverwendung. Ein interaktiver Angreifer kann den Code erst erzeugen, wenn das Opfer reagiert. Ratenbegrenzung stört Masse, weniger ein einzelnes Ziel. Schulung hilft, doch ein missbrauchter echter Ablauf ist für gut vorbereitete Nutzer schwer von Routine zu unterscheiden.

Nähe über BLE, NFC, UWB, gemeinsames Netz oder Standort erhöht die Kosten des Fernangriffs. VPN, Standortmanipulation, NAT, Mobilfunk und legitime Fernfreigaben verhindern die Gleichsetzung mit Absicht. Der Server prüft Signale, misst aber nicht eigenständig die physische Entfernung.

Nur verwalteten Geräten oder vertrauenswürdigen Netzen das Startrecht zu geben, schränkt den Angreifer ein. Vertrauen verlangt Registrierung, Attestation, Patches und Widerruf. Ein kompromittiertes vertrauenswürdiges Gerät bleibt gefährlich. Kleine Scopes und kurze Token vermindern Folgen nach einer Fehlfreigabe. Senderbindung erschwert den Export, nicht die Nutzung durch den bösartigen Client mit seinem eigenen Schlüssel.

Protokollwahl ist deshalb Risikogestaltung. RFC 10027 bevorzugt FIDO-Cross-Device-Authentifizierung, wenn fähige Geräte Ursprung und BLE-Nähe verbinden können. CIBA ist eine Alternative, wenn der Server bereits einen Kanal zum Nutzer hat, benötigt aber Schutz vor unerwarteten Anfragen. Der OAuth Device Authorization Grant läuft auf Geräten mit geringsten Fähigkeiten und sollte nur eingesetzt werden, wenn stärkere Verfahren nicht möglich sind; für sensible oder geschäftskritische Ressourcen verlangt er zusätzliche Kontrollen.

Vom grünen Haken zum Betriebsnachweis

Heng Lus Running-Code Primacy liefert einen passenden Auditmaßstab: Die Deklaration „genehmigt“ ist nicht das Ergebnis. Entscheidend ist, welcher Client welche Fähigkeit erhielt und was er anschließend tat.

Ein belastbarer Beleg verbindet Identität und Zustand des Initiators, Authorization Device und Methode, den auf beiden Seiten gezeigten Kontext, Scope, Nähe- oder Gerätebindung, Entscheidung, Tokenempfänger und -beschränkung, Erstnutzung, Anomalien, Widerruf und Wiederherstellung. Datenschutz erfordert Minimierung und Zugangsschutz. Rechenschaft verlangt dennoch mehr als ein Symbol.

Auch Verantwortung folgt den Hebeln. Produktteams entscheiden über den Komfortgewinn. Identitätsteams wählen Protokoll und Rechte. Geräte- und Netzteams verwalten Vertrauen. Fraud-Teams beobachten ungewöhnliche Starts. Resource Server erzwingen Tokenbedingungen. Support und Incident Response widerrufen Grants und Sitzungen. Ein unauthentifizierter Architekturabschnitt darf nicht allein durch die Aufmerksamkeit des Nutzers abgesichert werden.

Die Schlussfolgerung lautet nicht „QR-Codes sind unsicher“. Sie lautet: Ein sichtbarer Übergabeschritt ist noch keine authentifizierte Beziehung.

Quellen