SECURITY22. Januar 2020

FIDO – Banken-Retter in der SCA-Not?

Wie stehen die Banken bei der Umsetzung der PSD2/SCA? Felix Magedanz beschreibt, wie FIDO-Standards (Fast IDentity Online) für die Authentifizierung zur Verbesserung von Sicherheit und Benutzerfreundlichkeit im Online- und Mobile-Banking eingesetzt werden können.

von Felix Magedanz, Hanko.io

FIDO-Standard
stockwerk fotodesign/bigstock.com
Spätestens Mitte September 2019 haben die meisten europäischen Banken relativ umfassende Anpassungen an ihren Online-Banking-Systemen vorgenommen. Die Absicherung des Kontozugriffs, insbesondere des Logins bei Online- oder Mobile Banking, sowie von Zahlungsauslösungen wurde auf Verfahren umgestellt, die den Anforderungen an die Starke Kundenauthentifizierung (SCA) der PSD2 genügen.

Anmeldung nur noch mit extra TAN

Die größten Änderungen gab es beim Login zum Online-Banking. Dieser ist nun nur noch erlaubt, wenn der Nutzer sich stark authentisiert, was gleichbedeutend ist mit einer Zwei-Faktor-Authentifizierung (2FA). Bei allen betrachteten Umsetzungen besteht der erste Faktor wie gehabt aus einem Passwort, bei vielen Banken auch PIN genannt. Wie (und wann) anschließend der zweite Faktor geprüft wird, unterscheidet sich:

Felix Magedanz ist FIDO-Experte und Gründer von Hanko.ioHanko.io
1. Bei vielen Banken ist nun die zusätzliche Eingabe einer Transaktionsnummer (TAN) aus einem TAN-Verfahren erforderlich. Der Login wird also auf die gleiche Weise abgesichert wie eine Überweisung. Die bekanntesten dafür zum Einsatz kommenden TAN-Verfahren sind mTAN, chipTAN, photoTAN oder pushTAN.
2. Einige Banken setzen für die SCA beim Online-Banking auch auf Device Binding. Das bedeutet, dass der Nutzer den Login in einer App auf seinem Mobilgerät bestätigen muss. Teilweise ist diese Funktion integriert in die eigene Banking-App oder ausgelagert in eine separate TAN-App (z. B. “photoTAN” der Commerzbank).
3. Manche Banken machen von der 90-Tage Ausnahmeregel Gebrauch und erfordern eine SCA für den Login nur alle drei Monate. Dies ist allerdings nur mit gewissen Einschränkungen beim Umfang der im Online-Banking angezeigten Umsatzinformationen möglich und wurde aufgrund der dafür notwendigen Anpassungen nur von einigen Banken umgesetzt.

Für die 2FA im Mobile Banking machen sich die Banken in der Regel bereits die biometrischen Verfahren von iOS und Android in Verbindung mit Device Binding zunutze. Der initiale Login bei neu installierter App geschieht entweder wie im Online-Banking mit Benutzername + Passwort + TAN oder basiert auf einmalig verwendbaren QR-Codes, die manchmal als extra Verifizierungsschritt per Post versendet werden, oder ähnlichen Verfahren.

Nur wenige Änderungen bei Transaktionen

Bei Zahlungsauslösungen hat sich im Grunde nicht viel getan, da diese auch schon vor der PSD2 per TAN abgesichert wurden. Hier ist die wohl größte Änderung der Wegfall der TAN-Listen (iTAN). Die iTAN hat das Problem, dass sie statisch sind, d.h. eine gültige iTAN kann für jede beliebige zukünftige Transaktion verwendet werden und leitet sich nicht jedes Mal dynamisch aus den konkreten Transaktionsdaten ab. Diese “Blankoscheck”-Eigenschaft war nicht mehr gewollt. Die übrigen TAN-Verfahren bleiben nutzbar. Viele Banken bewegen ihre Kunden seit einiger Zeit zur Verwendung der auf Device Binding basierenden Verfahren, da hier weder Kosten für Hardware (chipTAN) noch für SMS-Versand (mTAN) anfallen.

Mangelhafte Umsetzung mit proprietären Verfahren

Zusammenfassend muss gesagt werden, dass die Umstellungen auf PSD2 SCA bei vielen Banken nicht reibungslos verlaufen sind. Auch die Situation heute ist sowohl aus Nutzersicht als auch im Hinblick auf die Sicherheitsaspekte teilweise alles andere als optimal. Folgende Probleme bei den Umsetzungen lassen sich identifizieren:

Passwörter. Der erste Faktor der Authentifizierung ist im Online-Banking nach wie vor ein Passwort, ein auf Wissen basierender Faktor. “Geteilte Geheimnisse” (das Passwort muss schließlich dem Nutzer und der Bank bekannt sein) haben den Nachteil, dass sie keinen Schutz vor skalierenden Angriffen wie z. B. Phishing bieten. Der Nutzer kann ausgetrickst werden, sein Passwort bei einer täuschend echt aussehenden Webseite einzugeben. Daraufhin verfügt der Angreifer ebenfalls über das Passwort und kann es frei verwenden. Die Verwendung von Passwörtern ist allgemein geläufig und akzeptiert, trotzdem lässt ihre Benutzerfreundlichkeit zu wünschen übrig. Dies wird insbesondere deutlich bei der ständig steigenden Anzahl an Online-Accounts und den dafür benötigten (hoffentlich) sicheren und sich unterscheidenden Passwörtern.

SMS. Die SMS als Sicherheitsfaktor (mTAN) ist bei vielen Banken immer noch Standard, in manchen Fällen sogar das einzige angebotene Verfahren. Etwas salopp gesagt wird also die Sicherheit im Online-Banking und für Überweisungen ausgelagert an die Telekommunikationsanbieter. Diese müssen nämlich sicherstellen, dass z. B. eine neue SIM-Karte für eine Rufnummer nur an exakt dieselbe Person ausgegeben werden kann. Das kann erwiesenermaßen keinesfalls immer gewährleistet werden (“SIM-Swap”-Angriffe). Die “Abhörsicherheit” des SMS-Kanals ist ebenfalls nicht mehr vorauszusetzen, auch hier sind Schwachstellen bekannt.

Proprietäre 2FA-Verfahren. Die Banken setzen für die Absicherung des Kontozugriffs im Online-Banking auf eigens entwickelte, proprietäre Verfahren. Die Tatsache, dass es dafür längst gängige Web-Standards gibt, wurde anscheinend komplett ignoriert. Dies hat zur Folge, dass die Banken dediziertes Personal oder Dienstleister für ihre Implementierungen vorhalten müssen, während die Nutzer bei jeder Bank abweichende Verfahren “neu lernen” müssen. Auch wurde das Device Binding in manchen Fällen so rudimentär umgesetzt, dass man z. B. bei der Bestätigungsaufforderung in der App nicht erkennen kann, was man eigentlich gerade bestätigt.

Autor Felix Magedanz, Hanko.io
Felix Magedanz ist FIDO-Experte und Gründer von Hanko.io. Mit seinem Team entwickelt er Lösungen für benutzerfreundliche, passwortlose Multifaktor-Authentifizierung (MFA) und Identity und Access Management (IAM) für Kunden aus den Bereichen Finance, Healthcare und SaaS.
Mehrere Apps. Den Sinn einer extra TAN-App, die man sich zusätzlich neben der Banking-App installieren muss, können die meisten Nutzer (zu Recht) nicht verstehen. Hat der Nutzer dann auch noch Konten bei verschiedenen Banken, so wird schnell eine große Anzahl an Apps benötigt.

Kein Schutz vor Phishing. Viele der eingesetzten TAN-Verfahren – wie auch schon der 1. Faktor Passwort – sind anfällig für Phishing- und Man-in-the-Middle-Angriffe, da sie technisch bedingt keine automatisierte Überprüfung der tatsächlichen URL in der Adressleiste des Browsers beim Nutzer enthalten. Wenn ich durch einen Link in einer Phishing-Mail auf “www.secure-thisbank.de” (fiktiv) gelandet bin (und nicht auf der echten Seite www.bank.de), hält die meisten Nutzer leider nichts davon ab, ihr Passwort einzugeben und anschließend eine gültige TAN oder den Login in der App zu bestätigen. Der Kriminelle, der hinter dem Angriff steht, betreibt dafür einen sogenannten Proxy-Server, der die echte Seite www.thisbank.de “durchschleift” und dem Nutzer unter “www.secure-thisbank.de” komplett unverändert anzeigt. Mit einem Unterschied: der Angreifer bekommt alles mit, was der Nutzer auf der Proxy-Seite eingibt, bevor es zur Bank weitergeleitet wird. Hat der Nutzer sich erfolgreich auf der Proxy-Seite eingeloggt, kann der Angreifer nicht nur das Passwort und eine TAN im Klartext mitschneiden, sondern gleich die ganze Session übernehmen und sämtliche Konto- und Transaktionsdaten einsehen. Tätigt der Nutzer in dieser Umgebung eine Überweisung, kann der Angreifer sogar im Hintergrund die Empfänger-IBAN verändern und dies so verschleiern, dass der Nutzer den Betrug nur schwerlich mitbekommt.

Wie kann FIDO helfen?

Wie können die FIDO-Standards im Online- und Mobile-Banking eingesetzt werden, um die Situation zu verbessern? Dazu ein kurzer Exkurs zu der Funktionsweise und den beiden Hauptzielen von FIDO:

1. Verbesserung der Online-Sicherheit durch standardisierte und auf allen Plattformen direkt verfügbare Infrastruktur für asymmetrische Kryptografie in Verbindung mit den Biometrie-Sensoren der Geräte.

2. Verbesserung der User Experience durch Ablösung von Passwörtern und native Integration à la Apple/Google Pay mit der daraus resultierenden reibungslosen, oft bereits gewohnten und leicht verständlichen Verwendung der Technologie.

Dabei legt FIDO den Fokus nicht primär auf den Bereich Business-to-Employee (B2E), sondern explizit auch auf den Business-to-Consumer (B2C) Bereich, was es beispielsweise den zertifikatsbasierten Verfahren deutlich überlegen macht.

Die FIDO-Standards werden von der FIDO Alliance entwickelt und frei veröffentlicht. Die Allianz ist ein Konsortium aus etwa 250 Mitgliedsorganisationen, darunter Internet- und Payment-Giganten wie Microsoft, Google, Amazon, PayPal, VISA und Mastercard, aber auch Behörden wie beispielsweise das Bundesamt für Sicherheit in der Informationstechnik (BSI). Der Clou bei FIDO ist, dass mit Google und Microsoft zwei der aktuell relevantesten Plattformen (Android und Windows mit zusammen mehr als 75% aller Internetnutzer) als treibende Kräfte in der Allianz vertreten sind. So ist nahezu jedes Gerät mit Android oder Windows 10 bereits heute FIDO-zertifiziert und unterstützt out-of-the-Box die passwortlose Authentifizierung. Apple hat sich zu FIDO anfangs bedeckt gehalten, aber inzwischen unterstützen auch die Safari-Browser unter iOS und MacOS den neuesten FIDO-Standard und ein Beitritt Apples zur FIDO Alliance und die Zertifizierung scheinen die nächsten logischen Schritte.

FIDO ist der Webstandard für das, was im PSD2-Umfeld als “Device Binding” beschrieben wird. Es bringt die Möglichkeit zur Authentifizierung mit dem Faktor Besitz (privater Schlüssel gespeichert auf dem Gerät) in dokumentierter, vereinheitlichter und zertifizierbarer Form auf die Geräte der Nutzer. Darüber hinaus enthält FIDO eine Abstraktionsschicht für die vereinfachte Verwendung der biometrischen Sensoren für den Faktor Eigenschaft. Kombiniert wird damit eine 2FA erzielt, die vom Nutzer lediglich seinen Fingerabdruck oder die Gesichtserkennung abverlangt. Der dafür benötigte FIDO-Stack ist entweder vollständig im Betriebssystem und in der Hardware des Geräts des Nutzers enthalten, oder kann auch in verteilter Form vorliegen, z. B. beim Einsatz von FIDO Security Keys.

FIDO2/WebAuthn für die Anmeldung im Online-Banking

Die Anmeldung im Online-Banking kann mit FIDO, genauer gesagt durch Unterstützung der W3C WebAuthentication API (WebAuthn), für einen immer größer werdenden Teil der Nutzer deutlich verbessert werden. Anstelle eines Passworts und einer TAN können Biometrie-Schnittstellen wie Windows Hello oder Touch ID für den PSD2-konformen, vollständig passwortlosen Login verwendet werden. Darüber hinaus erlaubt WebAuthn im gleichen Zuge auch die Verwendung von FIDO Security Keys – entweder als zweiten Faktor anstelle der TAN oder ebenfalls ganz ohne Passwort, wenn der Key über einen Biometrie-Sensor oder einen PIN-Schutz verfügt. Das ist praktisch für alle Bankkunden, die bereits über einen Security Key verfügen und diesen z. B. zum Schutz ihrer Google- oder Microsoft-Accounts sowie bei einer wachsenden Zahl anderer großer Anbieter verwenden. Und das Beste: Nicht nur mit Blick auf die User Experience ist FIDO2/WebAuthn allen anderen 2FA-Methoden überlegen, es ist darüber hinaus die einzige effektive Maßnahme gegen Phishing-Attacken. FIDO2/WebAuthn ist unter Windows 10, Android 7+, iOS 13.3 und MacOS verwendbar.

Anmeldung und Transaktionsabsicherung im Mobile-Banking mit FIDO UAF

Für die Implementierung von Device Binding, Biometrie und der Transaktionsabsicherung im Kontext von Mobile-Banking wurde der FIDO UAF Standard (“Universal Authentication Framework”) entwickelt. Anders als bei FIDO2/WebAuthn wird bei UAF kein FIDO-Stack auf dem Gerät des Nutzers vorausgesetzt, da hier der benötigte FIDO-Code als Teil einer App für iOS oder Android ausgeliefert wird. Anstelle einer proprietären Implementierung – wie bei manchen Banken bereits erfolgt – kann also mit UAF auf ein Verfahren gesetzt werden, welches als offener Standard vorliegt. Die Vorteile liegen auf der Hand:

Geringerer Implementierungsaufwand aufgrund bestehender umfassender Dokumentation oder durch Verwendung existierender, FIDO-zertifizierter Software Development Kits (SDKs)
Geringerer Dokumentationsaufwand für Konformitätserklärungen und das interne Informationsmanagement
Vereinfachte IT-Infrastruktur durch zentralen FIDO-Server, der UAF und FIDO2/WebAuthn gemeinsam bedienen kann. Damit entfällt der zusätzliche Bedarf für die Implementierung und den Betrieb einer proprietären Applikation für die Schlüsselverwaltung und Signaturüberprüfung auf den Bank-Servern
Erweiterbarkeit um neue biometrische Verfahren (z. B. Behavioral Biometrics) oder neue kryptographische Algorithmen im Rahmen der Weiterentwicklung des Standards
Bessere Sicherheit durch hohe Sichtbarkeit und große Community hinter dem Standard

Was muss die Bank tun?

Die Entscheidung für FIDO muss als Teil der IT-Strategie der Banken betrachtet werden. Eine schrittweise Integration in die bestehende Online- und Mobile-Banking-Infrastruktur bietet sich an. So kann bspw. mit der Umsetzung von Device Binding mit UAF gestartet werden und die Integration von FIDO2/WebAuthn im Online-Banking auf Basis der dann bereits erprobten FIDO-Infrastruktur im nächsten Schritt erfolgen. Folgende Voraussetzungen sollten für eine Einführung von FIDO erfüllt werden:

UI-Konzept. FIDO verändert die Art und Weise, wie sich Nutzer anmelden. Wenn der Nutzer FIDO aktiviert hat, wird kein Passwort und damit auch kein Passwort-Eingabefeld mehr benötigt. Es bietet sich an, auf einen “Identifier-first”-Ablauf zu wechseln, damit nach der Eingabe des Benutzernamens die Authentifizierungsmethode dynamisch abgefragt werden kann. Außerdem muss der Nutzer an geeigneter Stelle seine FIDO-Keys verwalten können.

WebAuthn-Support im Online-Banking. Auf Basis des UI-Konzepts muss eine Anpassung des Online-Bankings erfolgen und bei angestrebter Verwendung von FIDO2/WebAuthn die WebAuthn API der Browser unterstützt werden. Dies ist technisch nicht sehr kompliziert, und auch hierfür kann auf unterstützende Bibliotheken zurückgegriffen werden.

FIDO-Server. Als zentrale Komponente für die Unterstützung von FIDO muss die Bank über einen FIDO-Server verfügen, der die Standards FIDO2 und UAF unterstützt. Dieser kann entweder selber implementiert oder von einem Zulieferer bereitgestellt werden.

FIDO-SDKs. Für die UAF-Implementierung in den Banking Apps werden die entsprechenden FIDO-Komponenten für iOS und Android benötigt. Auch diese können auf Grundlage der Spezifikationen von den Banken selber implementiert oder von einem Zulieferer geliefert werden.

Fazit

Viele Banken haben sich im Vorfeld der PSD2 augenscheinlich auf eine rasche Umsetzung zur Erfüllung der regulatorischen SCA-Vorgaben konzentriert und dabei mehr oder weniger jeweils ihr eigenes Süppchen gekocht. Die unscharfen Formulierungen in der PSD2 haben sicher einen Teil zur aktuellen Situation beigetragen. Man kann sich rückblickend fragen, warum hier nicht gemeinsam und rechtzeitig sämtliche Anwendungsfälle aus Sicht der Kunden vor und nach der PSD2 durchgespielt und auf Basis von existierenden Standards einheitliche, konkrete Vorgaben oder zumindest Umsetzungsempfehlungen ausgearbeitet wurden.

Die FIDO-Standards haben inzwischen eine Reife und Verbreitung erlangt, die einen Produktiveinsatz insbesondere auch im regulierten Bankenumfeld möglich machen. Mit dem modernen Verfahren kann mit relativ einfachen Mitteln eine deutliche Steigerung von Nutzerfreundlichkeit und Sicherheit herbeigeführt werden, ohne neue Abhängigkeiten durch proprietäre Verfahren zu erzeugen. Felix Magedanz, Hanko.io

 
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/100145 
 
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (11 Stimmen, Durchschnitt: 4,91 von maximal 5)
Loading...

 

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Cloud: BSI stellt aktualisierten C5-Katalog vor

Seit seiner Veröffentlichung 2016 hat sich der Cloud Computing Compliance...

Schließen