Anmeldeverfahren und Phishing-Resistenz

Nicht das Kennwort ist das Problem, sondern die Weiterleitbarkeit

Die übliche Erzählung lautet, Kennwörter seien zu kurz, zu häufig wiederverwendet und zu leicht zu erraten. Das stimmt, erklärt aber nicht, warum ein starkes, einmaliges Kennwort mit zusätzlicher Bestätigung trotzdem gestohlen wird. Der Grund liegt woanders: Ein Kennwort ist ein weiterleitbarer Nachweis.

Weiterleitbar heißt, dass der Nachweis seinen Wert behält, wenn ihn jemand anderes an anderer Stelle vorzeigt. Wer ein Kennwort auf einer nachgebauten Anmeldeseite eingibt, hat es dem Angreifer übergeben; der gibt es beim echten Dienst ein und ist drin. Genau dasselbe gilt für eine SMS-Ziffernfolge, für einen Einmalcode aus einer App und — das überrascht die meisten — für eine Zustimmung per Benachrichtigung.

Die Dokumentation benennt diesen Angriffsweg direkt: Die Angriffe zielen darauf, Identitätsnachweise wie Kennwörter, SMS-Codes oder Einmalcodes per E-Mail zu stehlen oder weiterzureichen, ohne physischen Zugriff auf das Gerät der betroffenen Person. Zusätzliche Faktoren erhöhen dabei nur den Aufwand, sie schließen den Weg nicht.

Was ein Verfahren weiterleitbar macht

Der Unterschied liegt nicht in der Stärke des Geheimnisses, sondern darin, ob der Nachweis an den Ort seiner Verwendung gebunden ist.

Kennwort

Eine Zeichenfolge. Überall vorzeigbar, wo sie jemand eingibt — weiterleitbar.

SMS oder Sprachanruf

Eine Ziffernfolge auf einem zweiten Kanal. Der Kanal ist schwerer abzufangen, die Ziffernfolge bleibt weiterleitbar.

Einmalcode aus einer App

Zeitbasiert und kurzlebig, aber ebenfalls nur eine Zeichenfolge — innerhalb ihrer Gültigkeit weiterleitbar.

Zustimmung per Benachrichtigung

Kein Code wandert, aber die Zustimmung gilt für irgendeine laufende Anmeldung — sie lässt sich also erschleichen.

Weiterleitbarer Nachweis — Ein Nachweis, dessen Gültigkeit nicht davon abhängt, wem er vorgezeigt wird. Er kann zwischen der echten Gegenstelle und einer vorgetäuschten hin- und hergereicht werden, ohne seinen Wert zu verlieren.

Daraus folgt der Maßstab für den Rest des Moduls: Ein Verfahren ist phishing-resistent, wenn der Nachweis den Empfänger prüft — nicht, wenn er besonders schwer zu erraten ist.

Diese Unterscheidung erklärt auch, warum der verbreitete Reflex nicht hilft. Ein längeres Kennwort, ein kürzeres Gültigkeitsfenster für Einmalcodes oder ein erzwungener Wechselrhythmus verändern alle nur, wie schwer ein Nachweis zu erlangen ist. Keiner davon verändert, wofür er gilt, wenn er einmal erlangt ist. Gegen eine zwischengeschaltete Anmeldeseite, die den Nachweis in Echtzeit weiterreicht, wirkt keine dieser Maßnahmen — das Zeitfenster der Weitergabe beträgt Sekunden.

Origin-Bindung: warum ein Passkey nicht weitergereicht werden kann

Passkeys nach dem FIDO2-Standard lösen das Problem an der Wurzel. Die Dokumentation nennt die Eigenschaft origin-gebundene Public-Key-Kryptografie: Beim Registrieren entsteht ein Schlüsselpaar. Der private Schlüssel bleibt auf dem Gerät, der öffentliche liegt beim Dienst — und das Paar ist an genau die Gegenstelle gebunden, für die es angelegt wurde.

Ein nachgebautes Anmeldeportal hat eine andere Herkunft. Der Authenticator findet für diese Herkunft schlicht kein Schlüsselpaar und antwortet nicht. Es gibt nichts, was die betroffene Person falsch machen könnte — die Prüfung passiert vor jeder menschlichen Entscheidung.

Verifier Impersonation Resistance — Die dokumentierte Eigenschaft, dass ein Authenticator sein Geheimnis nur an die Gegenstelle herausgibt, für die der Passkey registriert wurde — und nicht an einen Angreifer, der sich als diese Gegenstelle ausgibt.

Technisch stehen dahinter zwei Standards, die man kennen sollte, weil sie in Fehlermeldungen auftauchen: WebAuthn regelt das Zusammenspiel mit dem Browser, CTAP die Kommunikation mit dem Authenticator selbst.

Der Anmeldeablauf, Schritt für Schritt

Die Schrittfolge erklärt, warum an keiner Stelle ein weiterleitbares Geheimnis entsteht.

Zwei Dinge fallen daran auf. Erstens wandert kein Geheimnis über die Leitung, sondern nur eine Unterschrift unter eine Aufgabe, die kein zweites Mal gilt. Zweitens ist die biometrische Geste kein Faktor, der an Entra ID übermittelt wird — sie entsperrt lokal den Schlüssel. Wer glaubt, sein Fingerabdruck werde geprüft, hat das Modell falsch verstanden; geprüft wird die Signatur.

Gerätegebunden oder synchronisiert

Passkeys gibt es in zwei Bauformen, und der Unterschied hat betriebliche Folgen.

Gerätegebunden

Der private Schlüssel entsteht auf einem physischen Gerät und verlässt es nie. Beispiele: ein FIDO2-Sicherheitsschlüssel oder Microsoft Authenticator.

Synchronisiert

Der Schlüssel wird verschlüsselt beim Anbieter des Passkey-Dienstes abgelegt und steht auf weiteren Geräten derselben Person zur Verfügung.

Synchronisierte Passkeys sind bequemer und lösen das Problem des verlorenen Geräts fast von selbst. Dafür geben sie etwas auf, das die Dokumentation ausdrücklich nennt: Sie unterstützen keine Attestierung. Damit lässt sich nicht mehr nachweisen, von welcher Art Gerät ein Schlüssel stammt — wer vorschreiben muss, dass nur geprüfte Hardware zum Einsatz kommt, kann sich auf synchronisierte Passkeys nicht stützen.

Die drei eingebauten Anmeldestärken

In einer Zugriffsregel wird nicht ein einzelnes Verfahren verlangt, sondern eine Anmeldestärke — eine benannte Menge zulässiger Kombinationen. Microsoft liefert drei davon mit; sie sind immer verfügbar und lassen sich nicht verändern.

Multifactor authentication strength

Dieselben Kombinationen, die auch die einfache Forderung nach mehrstufiger Authentifizierung erfüllen.

Passwordless MFA strength

Verfahren, die mehrstufig sind und ohne Kennwort auskommen.

Phishing-resistant MFA strength

Windows Hello for Business beziehungsweise eine Plattform-Anmeldeinformation, ein FIDO2-Sicherheitsschlüssel oder zertifikatsbasierte Anmeldung mit zwei Faktoren.

Die Dokumentation beschreibt die dritte Gruppe über ihr gemeinsames Merkmal: Sie enthält Verfahren, die eine Interaktion zwischen dem Anmeldeverfahren und der Anmeldeoberfläche verlangen. Das ist genau die Origin-Bindung aus dem dritten Abschnitt, in einem Satz.

Die Stärke wird in einer Zugriffsregel über das Steuerelement Require authentication strength verlangt. Sie baut dabei auf der Richtlinie für Anmeldeverfahren auf: Dort wird festgelegt, welche Verfahren im Tenant überhaupt zur Verfügung stehen und für wen. Eine Regel kann also nur fordern, was die Richtlinie zulässt — verlangt sie eine Stärke, deren Verfahren niemand registrieren durfte, sperrt sie die Betroffenen aus, statt sie zu schützen.

Nützlich ist außerdem, dass sich Stärken gezielt einsetzen lassen und nicht nur pauschal: für einzelne besonders sensible Anwendungen, für Personen mit erhöhtem Risiko, für den Zugriff von außerhalb des Firmennetzes oder — zusammen mit den Einstellungen für die organisationsübergreifende Zusammenarbeit — für Gäste aus fremden Tenants.

Zahlenabgleich: die Abwehr gegen Zustimmungsmüdigkeit

Solange Benachrichtigungen mit einem einfachen Bestätigen beantwortet werden konnten, war der Angriff simpel: Der Angreifer meldet sich mit gestohlenem Kennwort wiederholt an, bis jemand entnervt oder versehentlich zustimmt.

Der Zahlenabgleich schließt diese Lücke. Auf der Anmeldeseite erscheint eine Zahl, die in die App einzutippen ist. Wer keine Anmeldung angestoßen hat, sieht die Zahl nicht und kann nicht zustimmen. Laut Dokumentation ist der Zahlenabgleich für alle Benachrichtigungen des Authenticators aktiv und gilt auch für die Kennwortzurücksetzung durch Benutzer.

Wichtig für die Einordnung: Der Zahlenabgleich macht die Zustimmung schwerer zu erschleichen, aber nicht origin-gebunden. Wer die Zahl auf einer nachgebauten Seite abliest und weitergibt, kann sie immer noch eintippen. Das Verfahren ist ein deutlicher Fortschritt und trotzdem nicht phishing-resistent — deshalb steht es nicht in der dritten Stärke.

Das Henne-Ei-Problem der Registrierung

Jetzt kommt die Stelle, an der die meisten Einführungen scheitern. Eine phishing-resistente Anmeldung setzt ein registriertes Verfahren voraus. Um etwas zu registrieren, muss man sich anmelden. Am ersten Arbeitstag hat niemand etwas.

Der bequeme Ausweg ist ein Anfangskennwort, das per Mail oder telefonisch übergeben wird. Damit hängt aber die gesamte Kette an einem weiterleitbaren Nachweis: Wer das Anfangskennwort abfängt, registriert seinen eigenen Schlüssel — und besitzt danach eine phishing-resistente Anmeldung für ein fremdes Konto. Die starke Technik schützt dann zuverlässig den Angreifer.

Registrierungsbindung — Die Frage, woran der Anspruch einer Person auf ein Konto beim allerersten Mal festgemacht wird. Sie bestimmt die Sicherheit aller später registrierten Verfahren, unabhängig davon, wie stark diese sind.

Temporary Access Pass: die Brücke über das Henne-Ei-Problem

Für genau diesen Zweck gibt es den Temporary Access Pass — laut Dokumentation ein zeitlich begrenzter Zugangscode, der für einmalige oder mehrfache Anmeldung eingerichtet werden kann. Damit meldet sich eine Person einmal an, registriert ihr starkes Verfahren, und der Code verfällt. Derselbe Mechanismus trägt den Wiederherstellungsfall, wenn ein starkes Verfahren verloren geht.

Die Richtlinie dafür steht unter den Anmeldeverfahren und wird mit der Rolle Authentication Policy Administrator gepflegt. Diese Werte gelten ab Werk:

minimumLifetimeInMinutes

Mindestgültigkeit, ab Werk 1 Stunde — einstellbar zwischen 10 und 43.200 Minuten.

maximumLifetimeInMinutes

Höchstgültigkeit, ab Werk 8 Stunden — einstellbar zwischen 10 und 43.200 Minuten, also bis zu 30 Tage.

defaultLifetimeInMinutes

Standardgültigkeit, ab Werk 1 Stunde; jeder einzelne Pass darf innerhalb der beiden Grenzen davon abweichen.

isUsableOnce

Erzwingt einmalige Verwendung. Ab Werk false — Codes lassen sich also mehrfach verwenden.

defaultLength

Länge des Codes, ab Werk 8 Zeichen; zulässig sind 8 bis 48.

includeTargets

Die Gruppen, die sich mit einem Pass anmelden dürfen. Ohne Eintrag nützt der beste Code nichts.

Diese Namen lohnt es zu kennen, weil die Richtlinie im Portal nur einen Teil davon zeigt. Wer sie über Microsoft Graph setzt oder in einer Prüfung ausliest, arbeitet mit genau diesen Feldern — und state entscheidet mit den Werten enabled und disabled darüber, ob das Verfahren im Tenant überhaupt zur Verfügung steht.

Wiederherstellung ist ein Angriffsweg, kein Nebenschauplatz

Wer den Erstzugang absichert und die Wiederherstellung vergisst, hat nichts gewonnen. Beide Wege führen zum selben Ziel, und ein Angreifer nimmt den bequemeren.

• Ein Wiederherstellungsweg über eine Sicherheitsfrage ist ein weiterleitbarer Nachweis mit schlecht gewähltem Geheimnis.
• Ein Weg über die private Mailadresse verlagert die Sicherheit des Kontos zu einem Anbieter, über den die Organisation nichts bestimmt.
• Ein telefonischer Weg ist nur so stark wie die Identitätsprüfung im Servicedesk — und die ist selten dokumentiert.
• Ein zweites registriertes starkes Verfahren löst den Verlustfall, ohne einen schwächeren Weg zu eröffnen.

Die praktikable Antwort ist meist die letzte Zeile: Beschäftigte registrieren zwei starke Verfahren, etwa einen Sicherheitsschlüssel und eine Plattform-Anmeldeinformation auf dem Firmengerät. Fällt eines aus, trägt das andere, und der ausgestellte Pass bleibt der seltene Ausnahmefall mit kurzer Gültigkeit.

Prüfen lässt sich das an einer einzigen Frage, die jeden Entwurf schnell sortiert: Welchen Weg würde jemand nehmen, der das starke Verfahren nicht hat, aber Zugriff will? Führt dieser Weg irgendwo an einem weiterleitbaren Nachweis vorbei, ist er der eigentliche Eingang — und die Anmeldestärke in der Zugriffsregel beschreibt nur noch den Weg, den Angreifer nicht nehmen müssen.

Durchgerechnet: ein erster Arbeitstag ohne Kennwort

Der Preis dieses Ablaufs ist Gleichzeitigkeit: Er verlangt, dass jemand mit Ausstellungsrecht genau dann greifbar ist, wenn die Person vor Ort ist. Bei verteilten Teams und Fernanstellungen ist das der eigentliche Aufwand — und der Grund, warum viele Organisationen doch wieder beim verschickten Anfangskennwort landen.

Die Reihenfolge, die alles zusammenhält

Mit dieser Kette lässt sich jeder Vorschlag prüfen, der im Betrieb auftaucht. Die meisten scheitern nicht am zweiten Schritt, sondern am vierten und fünften — dort, wo Bequemlichkeit gebraucht wird und niemand hinschaut.