Passkeys im Banking: was das Passwort ersetzt und was nicht

Registriert ein Kunde einen Passkey, erzeugt der Authentikator ein Schlüsselpaar für genau diesen Dienst. Die W3C-Empfehlung Web Authentication, seit April 2021 eine W3C Recommendation, hält fest, dass der private Schlüssel an einen bestimmten Authentikator gebunden ist und keiner anderen Partei offengelegt werden soll, während der öffentliche Schlüssel zur vertrauenden Partei geht, die ihn speichert. Beim Anmelden sendet der Dienst eine Aufforderung, der Authentikator signiert sie, der Dienst prüft die Signatur gegen den gespeicherten öffentlichen Schlüssel.

Für eine Bank heißt das: eine Datenbank, die sich für Zugangsdaten nicht mehr zu erbeuten lohnt. Eine gestohlene Tabelle öffentlicher Schlüssel authentifiziert niemanden. Bei einer Passwortdatei liegt der ganze Wert des Einbruchs darin, dass das Gespeicherte dasselbe Material ist, das der Kunde vorlegt. Deshalb beschreibt die FIDO Alliance den Schritt als Beseitigung des gemeinsamen Geheimnisses und nicht als dessen besseren Schutz.

In einer Anmeldung treffen zwei Spezifikationen aufeinander. WebAuthn ist die Schnittstelle zum Browser: Die Webanwendung der Bank ruft sie auf, der Browser führt den Ablauf. CTAP, das Client to Authenticator Protocol der FIDO Alliance, regelt, wie der Browser mit einem Authentikator spricht, der nicht im Gerät steckt, etwa einem Sicherheitsschlüssel über USB oder NFC. Die W3C-Spezifikation verweist in ihren Abhängigkeiten auf CTAP und verlangt die kanonische CBOR-Kodierung aus CTAP2, das ist die Nahtstelle zwischen beiden.

Ein Plattform-Authentikator, also das sichere Element im Telefon oder Notebook, wird über denselben WebAuthn-Aufruf erreicht, ohne das externe Protokoll. Für ein Entwicklungsteam deckt eine Anbindung damit beide Fälle ab, ein echter Unterschied zur Zeit, in der jeder Token-Anbieter eigene Middleware lieferte. Für ein Sicherheitsteam wandern die Fragen zum Authentikator von der Anbindung zum Gerät.

Der Schlüssel gilt nur für eine Kennung der vertrauenden Partei, und die W3C-Spezifikation ist deutlich: Ein Public-Key-Credential lässt sich nur zur Authentifizierung bei derselben Stelle nutzen, erkennbar an dieser RP ID, bei der es registriert wurde. Der Browser teilt dem Authentikator mit, welche Herkunft anfragt, und ein Authentikator, dem eine nicht passende Herkunft vorgelegt wird, hat einfach keinen Schlüssel anzubieten.

Dagegen der Einmalcode. Ein Kunde auf einer überzeugenden gefälschten Seite liest den Code vor oder tippt ihn ein, der Angreifer reicht ihn innerhalb der Gültigkeit an die echte Bank weiter, und die Kontrolle ist durch einen Kunden ausgehebelt, der sich an die Anweisung gehalten hat. Ein Passkey lässt sich nicht weiterreichen, weil die Domain des Angreifers nicht die registrierte ist, und kein Überreden des Kunden ändert daran etwas. Das BSI nennt diese Klasse von Verfahren genau deshalb phishingresistent.

Ein gerätegebundener Passkey bleibt auf dem Authentikator, der ihn erzeugt hat. Geht das Gerät verloren, ist der Schlüssel weg, was für die Sicherheitsargumentation sauber und für die Hotline hart ist. Ein synchronisierter Passkey wird über das Plattformkonto des Kunden gesichert und erscheint auf dessen anderen Geräten. Deshalb funktioniert die Verbreitung überhaupt: Wer das Telefon wechselt, muss sich nicht bei jeder Bank neu registrieren.

Eine Bank muss beantworten, was die Synchronisierung mit dem Besitzfaktor macht, auf den sie sich stützt. Wenn ein Schlüssel auf einem neuen Gerät auftauchen kann, weil sich jemand in ein Plattformkonto eingeloggt hat, dann belegt die Bank teilweise dieses Plattformkonto. Die EBA setzt die Anforderungen an die Faktoren, auf die dieses Argument trifft, und starke Kundenauthentifizierung behandelt die Regel und ihre Kategorien. Die Antwort, bei der die meisten Institute landen: synchronisierte Passkeys für Zugänge mit geringem Risiko, etwas anderes für Vorgänge, die Geld bewegen.

Ein Kunde wird den Authentikator verlieren, und was dann passiert, ist das tatsächliche Sicherheitsniveau. Führt der Wiederherstellungsweg über einen Anruf bei einer Hotline, die nach dem Geburtsdatum fragt, dann ruft der Angreifer an, der den Passkey nicht phishen konnte, und die ganze Investition schrumpft auf die Qualität dieses Gesprächs. NIST SP 800-63B behandelt die Bindung eines Authentikators und den Ersatz eines verlorenen als Teil des Entwurfs, nicht als Betriebsdetail.

Die Entwürfe, die halten, haben eine gemeinsame Form: einen zweiten Authentikator registrieren, solange der Kunde noch Zugang hat, damit ein Verlust ein Routinefall wird, und den Wiederherstellungsweg mindestens so stark machen wie das Verfahren, das er ersetzt. Die Hinweise des BSI zur Authentisierung zeigen in dieselbe Richtung. Ist die Wiederherstellung schwächer, gehört das offen in die Risikoanalyse, denn eine Prüfung findet es.

Im delegierten Modell führt ein Händler oder eine Wallet die Authentifizierung durch, und der Emittent übernimmt das Ergebnis, anstatt den Kunden vor die eigene Bank zu stellen. Für den Kunden entfällt ein unangenehmer Sprung mitten im Kauf, für den Emittenten heißt es, sich auf eine Prüfung zu stützen, die jemand anderes durchgeführt hat, unter einem Vertrag, der festlegt, wie diese Prüfung aussehen musste.

Hier wird ein Passkey, den der Händler ohnehin hält, für den Emittenten interessant, und hier beginnt auch das Gespräch über die Haftung, denn wer prüft und wer den Schaden trägt, sind nicht mehr dieselben. Kartenzahlung in Deutschland behandelt die wirtschaftliche Seite, PSD3 und die PSR die Richtung der Gesetzgebung.

Über die Kundenanmeldung reden alle, der größere Schaden entsteht beim Mitarbeiterzugang, denn das Konto eines Administrators öffnet mehr als das eines Kunden. Dasselbe FIDO2-Verfahren greift dort und beseitigt den Angriff, mit dem Vorfälle am häufigsten beginnen: ein Mitarbeiter, der dazu gebracht wird, sich auf einer Seite anzumelden, die nicht der Bank gehört.

DORA zählt Zugangsrechte und Identitätsverwaltung zu den IKT-Schutzpflichten eines europäischen Finanzunternehmens, das Feld ist also reguliert und kein Hygieneprojekt. Zero Trust in Banken behandelt die Architektur, die ohnehin mit gestohlenen Zugangsdaten rechnet, und Maschinenidentitäten in Banken die Konten, bei denen sich nie ein Mensch anmeldet.

Er kann es sein, wenn das Entsperren des Authentikators ein biometrisches Merkmal oder eine PIN verlangt: Das registrierte Gerät ist ein Element, der Fingerabdruck oder die PIN, die den Schlüssel freigibt, ein zweites. Ob eine Aufsicht eine konkrete Umsetzung als zwei unabhängige Elemente akzeptiert, hängt davon ab, wie der Schlüssel gehalten und synchronisiert wird. Die Regel steht auf starke Kundenauthentifizierung.

Bei einem gerätegebundenen Passkey ist dieser Schlüssel verloren, und der Kunde braucht den Wiederherstellungsweg. Ein synchronisierter Passkey erscheint auf dem nächsten Gerät, in das der Kunde sein Plattformkonto einträgt. Das trägt die Verbreitung und ist zugleich der Grund, warum eine Bank überlegen muss, was dieses Plattformkonto einem Angreifer wert ist. In beiden Fällen macht ein zweiter registrierter Authentikator aus dem Verlust eine Kleinigkeit.

Das Verfahren nicht, der Kunde schon. Ein Passkey verhindert, dass ein Angreifer bei der Anmeldung etwas Wiederverwendbares abgreift. Gegen einen Anrufer, der den Kunden dazu bringt, eine Zahlung selbst auszulösen, hilft er nicht. Das sind andere Kontrollen, und Betrugsprävention in Deutschland behandelt die Zahlungsseite.

Ja. Ein Plattform-Authentikator im Telefon oder Notebook wird über denselben WebAuthn-Aufruf erreicht, die meisten Kunden halten also nie einen separaten Schlüssel in der Hand. Externe Schlüssel über USB oder NFC nutzen CTAP und bleiben dort nützlich, wo sich das Verfahren vom Gerät trennen lassen muss, eine gängige Wahl für Administratorzugänge.