Alternativen zum PSD2-geknebelten FinTS?

Hallo Kollegen,

mit PSD2 wird die Verwendung von FinTS (aka HBCI) ziemlich "unbequem".

Fuer Anwender von manuell bedienten Desktop-Anwendungen sind die Einschraenkungen noch ueberschaubar: mehr Hickhack mit 2-Factor-Auth, haeufigere Eingabe von PINs / Passwortern / TANs / Codes / etc.

Fuer Anwender die FinTS fuer Automatisierungszwecke einsetzen wird FinTS praktisch "unbrauchbar". Einfachstes Beispiel: automatisiertes taegliches Abrufen und Auswerten von Kontoauszuegen. Je nach Bank braucht man dafuer nun jedesmal oder spaetestens nach 90 Tagen eine erneute manuelle Interaktion.

Seit der Einfuehrung von Internet-Standards und Protokollen wie FTP, HTTP, SMTP, ... gilt das ungeschriebene Gesetz: sichere Authentizierung wird unterstuetzt und empfohlen, aber wenn ein Anwender unbedingt mit unsicheren Algorithmen arbeiten will, dann kann er.

Beispiele:
- HTTP Digest Auth (erfordert einen unbequeme Challenge-Response roundtrip), kann aber mit HTTP Basic Auth auch "unsicherer", dafuer aber automatisierbar, realisiert werden
- SASL PLAINTEXT .vs. SASL CRAM-MD5 oder SASL GSSAPI (gleiches Prinzip)
- ...

Ohne mich auf technische Detail-Diskussionen einlassen zu wollen ist ziemlich offensichtlich, dass FinTS seit PSD2 keine "unsichere Alternativ-Variante" mehr bietet. Selbst Nutzer die sich nicht um Sicherheit scheren sind nun gezwungen an Challenge-Response-Automatisierungs-Blockern teilzunehmen.

Ich moechte ausserdem klarstellen dass der Einsatz von DDV- und/oder RSA-Chipkarten wohl nicht den PSD2-Regeln unterliegt. Allerdings hilft mir das beim "Automatisieren" auch nicht weiter - ich kann meine Chipkarte nicht zu meinem AWS-Server bringen damit sie dort fuer sichere Verschluesselung sorgt. Schon gar nicht wenn ich Konten bei mehr als einer Bank habe... Ausserdem haben mir 3 von 5 Banken bescheinigt dass sie keine Unterstuetzung fuer Chipkarten-basierte Systeme geben ("bitte wenden Sie sich an den Hersteller").

Der Sinn eines "offenen FinTS-Standards" wird ebenfalls dadurch beschnitten dass FinTS-Clients nun "registriert" werden muessen. Unregistrierte Clients duerfen nicht mitspielen. Glaubt man nicht daran dass eine korrekte Server-Implementierung jeden "malicious client" abwehren kann? Wie armselig. Und als Entwickler von freier, unbezahlter OpenSource Software fuehlt man sich da schnell bevormundet (ich habe nie davon gehoert dass z.B. ein AWS-Client oder ein PayPal-Client solchen Restriktionen unterliegt... nur mal so zum nachdenken)

Meine eigentliche Frage in diesem Post: was habe ich als Anwender fuer Alternativen?
- Ich bin eine Privatperson
- Ich habe mehr als ein FinTS-faehiges Bankkonto, insgesamt bei mehreren verschiedenen Banken
- Ich wuerde gern mindestens das Abrufen von Salden / Kontoauszuegen automatisieren
- Idealerweise wuerde ich auch gern bestimmte Ueberweisungen automatisiert / gescripted anstossen koennen

FinTS scheidet dafuer offensichtlich aus.

EBICS waere eine Alternative, allerdings ist es a) schwierig als Privatperson einen EBICS-Account zu erhalten, und b) uebersteigen die entsprechenden Kosten mein Budget bei weitem. Wobei ich mich ausserdem frage, wieso die PSD2-Regeln nicht auch fuer EBICS gelten - hier hat man von zwei morschen Tueren (FinTS und EBICS) offensichtlich nur eine mit einem Schloss versehen (FinTS), die andere bleibt unveraendert.

Gibt es andere Alternativen? Oder ist der allgemeine Konsens jetzt "ja, wir alle brauchen Digitalisierung" (O-Ton irgendein Minister), aber gleichzeitig werden Automatisierungs-Konzepte per Gesetz beschnitten?

-stefan-

Wie msa es schon geschrieben hat: Es gibt gar keine Alternative, auch nicht bei FinTechs. Mit der PSD2 soll der Schutz des Kontos und dessen Daten sowie elektronischen Zahlungen sicher gestellt werden. Die Möglichkeiten 90 Tage mal keine TAN einzugeben, ist schon eine Erleichterung, die eine Bank nur unter bestimmten Vorraussetzungen überhaupt gewähren kann.
Ansonsten gilt auf allen Wegen eine starke Kundenauthentifizierung mit mindestens zwei Faktoren (Chipkarten unterliegen übrigens auch der PSD2 und erfüllen auch diese Anforderungen). Das gilt für EBICS, für FinTS, Für API Zugänge über Dritte und auch für Web)
Da wo man auf den zweiten Faktor verzichten könnte, ist für die Masse der Kunden praxis fern und daher nicht relevant.

Es bleibt also nichts Anderes als damit zu leben und darauf hoffen, dass Vereinfachungen durch technische finessen kommen, die den Komfort erhöhen und trotzdem die PSD2 erfüllen.

Eine sehr gute Beschreibung des 90-Tage-Regel-Desasters.
Nach 90 Tagen ist es oft dem Zufall überlassen, wann der Kunde beim Anmelden sein TAN-Gerät hervorholen muss.

Die Stadtsparkasse München warnt nach dem Anmelden in ihrem Webportal wenigstens einige Tage vorher, wann wieder eine TAN eingegeben werden muss. Diese Warnung gilt zwar auch für die Finanzsoftware, solch ein Hinweis kommt aber nicht über die HBCI/FinTS-Schnittstelle.

mfg Volker

Decoupled TAN Verfahren (also TAN-lose Freigaben per App) nun also doch auch per FinTS. War völlig an mir vorbei gegangen. Hatten wir im letzten Jahrzehnt eigentlich mal ein Jahr, wo kein neues TAN-Verfahren erfunden wurde oder neue Prozess-Varianten eingeführt wurden?

Ärm moment, bedeutet TAN-lose Freigaben kommen jetzt offiziell in den FinTS-Standard oder wie wird das da gelöst? Das ist insbesondere deshalb interessant, weil die Fiducia & GAD IT ja auch gerade in Richtung Freigabe-App geht und das eigentlich nicht mit dem derzeitigen FinTS-Standard kompatibel ist. Der Standard will eigentlich immer noch eine TAN haben oder habe ich da was verpasst?

Ja, Du hast was verpasst . Der Decoupled Ansatz ist inzwsichen spezifiziert und somit auch für FinTS nutzbar. Die Spezifikation ist so aufgebaut, das neben dem primitiven Ansatz (die Software geht in eine Warteschleife und fragt ständig nach) , später auch weitere Ansätze möglich sind, bei der der Dialog ohne direkte Bestätigung weiter geführt werden kann. Die aktuelle Spezifikation hat nur den Vorteil, dass die grundsätzlichen Abläufe des FinTS Protokolls nicht so starlk betroffen sind, wie bei den weiterführenden Ansätzen.

Danke fuer eure Antworten. Im wesentlichen verstehe ich die Situation genau so und bin mit den meisten Argumente bei euch, moechte aber trotzdem auf einige Antworten konkret eingehen:



In den letzten Jahren habe ich im wesentlichen an Bank-Zugaengen fuer Corporates gearbeitet (i.e. im B2B-Bereich, via EBICS, SWIFT, und haufenweise proprietaeren Protokollen), bei denen das Thema PSD2 bis heute interessanterweise nicht wirklich zum Problem geworden ist. Aus beruflichen und privaten Gruenden bin ich gerade dabei das Thema "private Nutzung" wieder in den Vordergrund zu holen. Allerdings scheint mir dass das keinen Spass mehr macht wie noch vor 10 Jahren.

Damals bestand die Spez. aus 85% Geschaeftsvorfaellen, 10% DDV/RDH, und 5% PIN/TAN.
Heute besteht die Spez. auf 50% Geschaeftsvorfaellen, 10% DDV/RDH, und 40% PIN/TAN in allen moeglichen Varianten.

Mit anderen Worten: Mir scheint dass es eigentlich ueberhaupt kein grundlegendes Konzept gibt fuer das FinTS-Protokoll (im Security-Bereich). Statt dessen wird bei jeder neuen Anforderung irgendein neuer Flicken drangenaeht.



Da wuerde ich widersprechen. Konzeptionell ist auch eine Schluesseldatei nur "Wissen", denn theoretisch kann ich mir den Schluessel ja auch einfach merken anstatt ihn abzuspeichern. Das sind bei 2048 bit gerade mal 340 base64-Zeichen - ich habe schon groessere Gehirnakrobatikleistungen gesehen. Fuer mein Verstaendnis ist mit "Besitz" eigentlich etwas gemeint wie Schluessel auf einer nicht auslesbaren Chipkarte oder OTP-Tokens. Von mir aus auch noch Fingerabdruck oder Iris-Scan (obwohl auch diese Daten eigentlich "Wissen" und nicht "Besitz" sind).

Oder andersrum: FinTS via HBCI/RDH mit einer gespeicherten Schluesseldatei und gespeichertem Passwort wuerde weiterhin den PSD2-Regeln entsprechen? Bin ich der einzige der das absurd findet, im Vergleich zum Aufwand der fuer FinTS PIN/TAN betrieben wird? Um diesen Glitch zu beheben waere es konsequent dass Banken RDH nur noch via RSA-Chipkarte unterstuetzen und alle software-basierten RDH-Verfahren abgeschaltet werden - einschliesslich EBICS und aller proprietaeren Zugaenge wie SFTP / HTTPs-PUSH / etc. Sind wir tatsaechlich schon so weit?



Wie oben schon erwaehnt: fuer mich scheint das nur ein weiterer Flicken auf dem Teppich der Authentifizierungs-Methoden zu sein. Beim Design der FinTS-Spezifikation setzt man offensichtlich darauf dass auch FinTS-Clients immer komplexer werden muessen um alle moeglichen Szenarien zu unterstuetzen. Das geht voellig vorbei am aktuellen Stand der Software-Entwicklungs-Strategien bei denen die Clients so "dumm" wie moeglich gehalten werden koennen und die eigentliche Komplexitaet auf Server-Seite liegt (vergleiche z.B. das OAuth2-Konzept).

Aber wie msa mich schon belehrte: es ist muessig sich Gedanken darueber zu machen warum/weshalb/wieso die FinTS-Spezifikation sich entwickelt wie sie es eben tut. Leider (oder zum Glueck) habe ich da kein Wort mitzureden. Es waere schoen gewesen wenn an einem "offenen Protokoll" auch Leute mit spezifizieren duerften die Ahnung von API-Design, Software-Entwicklung im allgemeinen, Abstraktion etc. haetten. Aber es sind wohl nur Banken beteiligt die ihren schon existierenden Mist in den Standard einbringen wollen und kommerzielle Hersteller die ihren neuesten Mist verkaufen wollen.

Nun bringt mich diese Einsicht zurueck zur Frage: lohnt es sich (fuer mich) ueberhaupt noch sich mit FinTS zu beschaeftigen, wenn die eigentliche Hauptaufgabe dabei darin besteht den "Machern" hinterherzuprogrammieren, anstatt wirklich sinnvolle Anwendungen dieser Technologie voranzutreiben? Fuer mich lautet die Antwort im Moment eher "nein".

Danke, ich weiss deinen versteckten Hinweis und die Idee dahinter zu schaetzen.

Natürlich darfst Du mir widersprechen, ändert aber nichts daran, dass es genau so ist, wie ich es gesagt habe. Um Dir die Brücke zu bauen: Die meisten Experten sind davon ausgegangen, dass die Schlüsseldatei den Faktor Besitz nicht ausreichend deckt. Die Einschätzung der Regulierung ist aber -derzeit- anders. Wichtig dabei ist immer derzeit und in der heutigen Form, bei der die Schlüsseldatei mit einem Passwort gesichert ist.
Wenn man möchte, könnte man die Schlüsseldatei auch kryptologisch an die Hardware binden und hätte so einen harten Faktor Besitz. Alle Beurteilungen sind daher immer eine Momentaufnahme!

Nicht würde, sie entspricht den Vorgaben der PSD2

Sorry, wenn ich das so direkt sage, aber Du bist mit deiner Sichtweise extrem eingeschränkt unterwegs.
Dem Regulator interessiert FinTS/EBICS usw. nicht die Bohne. Es werden schlicht für Abstrakte Vorgänge, Abstrakte Anforderungen gestellt. Diese gelten dann in ganz Europa, für alle Verfahren/Anwendungen, die in das gedachte Anwendungsszenarium fallen. Die müssen das dann für sich interpretieren und umsetzen.

An der Spezifikation arbeiten durchaus hochkarätige Fachleute mit, die auch von APIs Ahnung haben. Nur die Welt und die Abhängigkeiten sind erheblich komplexer, als die, mit denen man es als „normaler“ Entwickler, normales Softwarehaus sonst so zu tun hat. Das ist in der Tat nicht immer gut, aber so sind die Rahmenbedingungen, an denen keines der Häuser, die da mitarbeiten etwas mal soeben ändern kann.
So Themen wie Decoupled TAN kommt dann aus dem Markt zurück. Das ist der aktuelle Trend bei den Freigabeverfahren, egal ob es Kreditkarte oder Onlinebanking ist. Das muss man nicht mögen, aber wenn der Markt diese Erwartungshaltung hat, kommt man nicht daran vorbei. Also versucht man auch dafür Lösungen zu schaffen, die möglichst in die bestehenden Architekturen passen.

Die Frage stellt sich nur nicht nur für FinTS. Sie gilt für alle Zugänge die Banken anbieten. Bei Banken bist Du in einem Umfeld, das am stärksten durch aufsichtsrechtliche Vorgaben reguliert ist. Wenn Du mit deinem Unternehmen nur einem Bruchteil dieser Vorgaben unterliegen würdest, könntest Du vermutlich dein Laden zu machen. Hier wird sich noch so mancher Drittdienstleister, der sich für die PSD2 Schnittstelle registriert hat, umgucken.

Ich hab das so verstanden. Wenn die Anwendung nicht auf einem Desktop-System läuft sondern auf einem Mobil-Gerät, wo das Konzept von Push-Beanchrichtigungen überhaupt existiert, dann müsste die Bankinganwendung nicht zyklisch nach dem Status pollen sondern kann direkt von der Bank per Push informiert werden. Genauso, wie die Freigabe-App ja auch die Info per Push erhält. Technisch sollte sowas auch auf dem Desktop gehen. Nur dass es dort halt keine etablierte Standard-Technik für Push-Nachrichten gibt wie etwa bei Android mit Google's Firebase.