Die Herausforderungen für das Bankwesen summieren sich: PSD2 bedeutet neue Regeln für den Datenaustausch

Veröffentlicht: 2018-04-13

Viele von Ihnen haben zweifellos von der Richtlinie der Europäischen Bankenaufsichtsbehörde (oder EBA) der Europäischen Union mit dem Namen PSD2 (kurz für Payment Services Directive) gehört. Diese Richtlinien wurden ursprünglich Ende 2015 veröffentlicht. Bis Januar 2018 mussten alle Mitgliedstaaten die Vorschriften umsetzen.

Die Bankenbranche steht vor vielen Herausforderungen, wenn sie nicht bereits an eine sehr digitale Zukunft denkt.

Grundlegendes zur starken Kundenauthentifizierung für die PSD2 der EU

Zu den Hauptzwecken von PSD2 gehören:

Eröffnen neuer Marktchancen für eine Vielzahl von Akteuren wie Online-Händlern und gleiche Wettbewerbsbedingungen für alle wichtigen Interessengruppen
Bereitstellung von Verbrauchertransparenz und Verbraucherauswahl
Einführung neuer und robusterer Sicherheitspraktiken für Online- Zahlungen

Es gibt eine Reihe allgemeiner Richtlinien für PSD2; Eine der besseren PSD2-Richtlinien kann jedoch von MEF (Mobile Ecosystem Forum) heruntergeladen werden.

Starke Kundenauthentifizierung

Eines der Schlüsselelemente der PSD2-Vorschriften ist das Konzept der starken Kundenauthentifizierung (oder SCA). Die EBA stellt fest: „Dank PSD2 werden Verbraucher besser geschützt, wenn sie elektronische Zahlungen oder Transaktionen durchführen (z. B. ihr Online-Banking nutzen oder online einkaufen).

Der Regulatory Technical Standard (RTS) macht die starke Kundenauthentifizierung (SCA) zur Grundlage für den Zugriff auf das eigene Zahlungskonto sowie für Online-Zahlungen.“ Kurz gesagt fordert SCA mindestens eine Zwei-Faktor-Authentifizierung (2FA).

Zwei-Faktor-Authentifizierung bedeutet, dass Benutzer ihre Identität durch zwei separate Elemente von drei „beweisen“ müssen:

Etwas, das sie wissen (ein PIN-Code oder ein Passwort)
Etwas, das sie besitzen (ein mobiles Gerät, eine Karte)
Etwas, das sie sind (Fingerabdrücke, Gesichtsscan: z. B. Biometrie)

Die EBA stellt fest, dass SCA üblicherweise in der gesamten EU verwendet wird; Dies ist jedoch bei Online-Zahlungsvorgängen wie Kreditkartenzahlung oder Sofortüberweisung nicht immer der Fall. SCA wird in den EU-Ländern Belgien, Niederlande und Schweden angewendet); In anderen EU-Ländern wird SCA jedoch nur auf freiwilliger Basis angewendet, heißt es in einer ausgezeichneten Pressemitteilung der Europäischen Kommission.

Während die EU-Mitgliedstaaten PSD2 bis Januar 2018 implementieren sollten, wird SCA 18 Monate später nach dem EBA Regulatory Technical Standard (RTS) nach dem Datum des Inkrafttretens des RTS (das voraussichtlich noch in diesem Jahr sein wird) obligatorisch. . Im Wesentlichen rechnen wir also mit Mitte bis Ende 2019 (September 2019 war ein solches Datum, das in einigen Dokumenten zitiert wird). Dies gibt allen Beteiligten ausreichend Zeit, um SCA und andere Sicherheitsanforderungen in ihre Systeme und Arbeitsabläufe zu integrieren.

Privatkundengeschäft: Löwen und Banker und Fintechs, oh mein Gott!

Fintechs bedrohen den Status quo. Im Gegensatz zu Banken sind sie nicht durch Altlasten, Vorschriften und in den meisten Fällen sogar durch die Notwendigkeit, Geld zu verdienen, belastet. Privatkundenbanker müssen sich anpassen und sich auf Kundenbeziehungen konzentrieren, um wettbewerbsfähig zu sein.

2FA für SCA

Angesichts des SCA-Zeitplans ist 2018 ein perfekter Zeitpunkt für Unternehmen, mit der Implementierung von 2FA-Lösungen zu beginnen, um der erforderlichen erhöhten Sicherheit Rechnung zu tragen.

Die internationale Anwaltskanzlei Taylor Wessing stellt in ihrem Papier: Starke Kundenauthentifizierung unter PSD2 fest, dass „die EBA mit der Mehrheit der Befragten des Konsultationspapiers einverstanden war, um Technologieneutralität zu gewährleisten und eine benutzerfreundliche Entwicklung zu ermöglichen , ein zugängliches und innovatives Zahlungsmittel, sollte die Authentifizierungselemente nicht weiter definiert werden.“ Das bedeutet, dass die EBA nicht spezifiziert, wie 2FA umgesetzt werden kann. Es gibt eine Vielzahl von Schemata, darunter die Token-Zustellung über mobile Kanäle wie SMS oder Push-Benachrichtigungen oder traditionellere E-Mail-Kanäle sowie TOTP-Soft-Token-Lösungen und andere.

All dies angemerkt, sollten wir darauf hinweisen, dass es wie bei jedem guten 2FA-Implementierungsschema einige Einschränkungen und spezifische Vorschriften gibt, die sorgfältig berücksichtigt werden müssen.

Authentifizierungscodes

Der RTS weist darauf hin, dass die Generierung eines Authentifizierungscodes die folgenden Bedingungen erfüllt:

Aus der Bekanntgabe des Authentifizierungscodes lassen sich keine Erkenntnisse über Kenntnis, Besitz und Erbschaft ableiten
Es ist nicht möglich, einen neuen Authentifizierungscode basierend auf der Kenntnis eines anderen zuvor generierten Authentifizierungscodes zu generieren
Der Authentifizierungscode kann nicht gefälscht werden

Darüber hinaus gibt das RTS an, dass innerhalb der Gültigkeitsdauer des Codes nicht mehr als 5 fehlgeschlagene Authentifizierungsversuche unternommen werden sollten und dass die maximale Zeit ohne Aktivität des Zahlers oder Benutzers nach der Authentifizierung für den Online-Zugriff auf sein Zahlungskonto 5 Minuten nicht überschreiten darf .

Dynamische Verknüpfung der Transaktion

Das RTS gibt an, dass elektronische Ferntransaktionen – im Wesentlichen Zahlungen, die über das Internet (ob auf einem Desktop-Gerät wie einem Laptop oder einem Mobilgerät) getätigt werden – Elemente enthalten müssen, die „die Transaktion dynamisch mit einem bestimmten Betrag und einem bestimmten Zahlungsempfänger verknüpfen“. Der RTS betrachtet dies als eine zusätzliche Form von SCA.

Für diese SCA-Anforderung müssen dem Benutzer zum Zeitpunkt einer 2FA-Transaktion der Betrag der Zahlungstransaktion sowie der Zahlungsempfänger (oder Händler) mitgeteilt werden. Wenn sich der Betrag oder der Zahlungsempfänger ändert, sollte ein weiterer Authentifizierungscode generiert werden (z. B. „dynamische Verknüpfung“ dieses Codes mit dem neuen Zahlungsempfänger und/oder Zahlungsbetrag). Eine SMS-Nachricht mit allen erforderlichen Informationen kann wie im Bild rechts aussehen: Der 10-Minuten-Sicherheitscode, der Name des Händlers (oder des Zahlungsempfängers) und der Transaktionsbetrag.

Interessanterweise wird ein Authentifizierungscode, der von einer TOTP-kompatiblen Drittanbieter-App wie Google Authenticator generiert wird, vollständig getrennt von den Zahlungs-/Händlerinformationen generiert und kann daher nicht dynamisch verknüpft werden.

Kanalunabhängigkeit

Diese Anforderung ist etwas knifflig. Das RTS besagt, dass die „Zahlungsdienstleister Sicherheitsmaßnahmen ergreifen müssen, wenn eines der Elemente der starken Kundenauthentifizierung oder der Authentifizierungscode selbst über ein Mehrzweckgerät verwendet wird, um das Risiko zu mindern, das sich aus diesem Mehrzweckgerät ergeben würde kompromittiert werden.“ Ein Mehrzweckgerät kann ein mobiles Gerät oder Tablet oder sogar ein Laptop sein.

Wenn sich ein Benutzer auf einem Laptop befindet und aufgefordert wird, eine Zahlung vorzunehmen, kann dieser Händler eine SMS mit dem Zahlungsempfänger (z. B. dem Händler) sowie dem zu zahlenden Betrag zusammen mit der Authentifizierung an das mobile Gerät des Benutzers senden Code im Textkörper der SMS.

Wenn in einem anderen Beispiel der Benutzer ein mobiles Gerät verwendet, um mit einem Händler zu interagieren und eine Zahlung initiiert, dann verbietet diese Kanalunabhängigkeit nicht ausdrücklich SMS oder einen mobilspezifischen Lieferkanal. Hier ist es ein schmaler Grat. In vielen Fällen ist das einzige Gerät, das ein Benutzer hat, ein Mehrzweckgerät wie ein Mobiltelefon. Aber die Kanalunabhängigkeit ist genau das – ein unabhängiger Kanal auf demselben Gerät – eine SMS mit einem Authentifizierungscode ist ein anderer Kanal (tatsächlich ist es ein Out-of-Band-Kanal , der über die Mobiltelefonnummer erreicht wird) als das Mobiltelefon App oder Webbrowser, mit der der Benutzer mit dem Händler interagiert. Die gleiche Kanalunabhängigkeit würde für die Verwendung einer mobilen App zum Generieren eines TOTP-konformen Codes (wie Google Authenticator) gelten, aber wie bereits erwähnt, scheitert der TOTP-Beschwerdecode an der dynamischen Verknüpfung der Transaktion.

Wenn der Benutzer hingegen eine mobile App verwendet, um auf den Händler zuzugreifen, wäre eine Push-Benachrichtigung an dieselbe App (mit dem Authentifizierungscode) nicht möglich, da es sich um denselben Kanal handelt.

Es gibt diejenigen, die sagen würden, dass 2FA über SMS sehr unsicher ist und in einigen Fällen könnte das wahr sein. Ja, es gab einige Einzelfälle, in denen es einem Angreifer gelang, auf 2FA-SMS-Nachrichten über SS7 bei einem Betreiber zuzugreifen; Viele dieser Schwachstellen wurden jedoch geschlossen. Außerdem spielt es eine große Rolle, wie der Authentifizierungscode generiert und dem Benutzer bereitgestellt wird und wie der Messaging-Dienstanbieter solche Codes liefert.

In Situationen, in denen Mehrzweckgeräte weit verbreitet sind (und dies sind und bleiben heute die am weitesten verbreiteten Geräte), sollte ein von Mobilfunkbetreibern bereitgestellter Messaging-Kanal weiterhin ein praktikabler Out-of-Band-Kanal für 2FA-Token sein.

Für eine detailliertere Analyse habe ich einen informativen Blogbeitrag von Frederik Mennes gefunden, der mehr Details darüber enthält, welche Arten von Szenarien – insbesondere für Mehrzweckgeräte – für PSD2 SCA konform sein sollten.

PSD2 SCA sollte nicht auf die leichte Schulter genommen werden, aber viele bereits implementierte 2FA-Lösungen sollten funktionieren; Wir wissen jedoch auch, dass viele Online-Händler noch keine Lösungen anbieten, die mit PSD2 SCA kompatibel sind. Zum jetzigen Zeitpunkt ist noch genügend Zeit, um SCA in Zahlungsabläufe zu integrieren.

SAP Authentication 365 ist eine Lösung, die eine API-basierte Cloud-Lösung bereitstellt, mit der Unternehmen PSD2-konforme SCA implementieren können. Der mobile Service SAP Authentication 365 ist ein End-to-End-Service, mit dem Sie schnell und sicher einen Multichannel-Zwei-Faktor-Authentifizierungsdienst (2FA) mit einer auf Ihr digitales Geschäft zugeschnittenen Authentifizierung implementieren können.

Es hilft, die Identität und Daten Ihrer Unternehmenskunden zu schützen, indem es die Authentifizierung per SMS, E-Mail, Push-Benachrichtigungen oder TOTP-Soft-Token ermöglicht. Die REST-API von SAP vereinfacht die Generierung und Authentifizierung von Validierungs- oder Authentifizierungscodes und bietet Flexibilität und Funktionen, um die Implementierung einer PSD2-konformen SCA-Strategie zu ermöglichen.