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-

Klar Antwort: Es gibt für Dich keine Alternativen. Außer vielleicht Du wechselst zu irgendwelchen FinTechs, die irgenfwelche selbstgestrickten APIs haben (und die vorher noch nie HBCI unterstützt haben).

Im Übrigen ist es recht blauäugig, nach Alternativen zu Fragen. Die Banken haben sich PSD2 nicht ausgesucht und machen das nicht, weil sie es so toll finden, sondern weil es EU-weit so verpflichtend vorgegeben ist. Also kannst Du gar keine Alternativen finden, die anders arbeiten.

Und die Frage "warum diese und jene nicht" ist naheliegend aber nicht zielführend. Wenn die Politik etwas will, dann wird da meistens nicht über Sinn und Unsinn geredet sondern es wird einfach so gemacht, wie manche sind das vorstellen, auch wenn es noch so unsinnig ist. Du wirst damit leben müssen. Es sei denn, Du wanderst aus der EU aus - dann könnte es andere Möglichkeiten geben. Aber nein, die gibt es auch nicht, weil es in allen anderen Ländern außer Deutschland für Privatkunden überhaupt gar keinen maschinellen Standard gibt bzw. je gegeben hat. Also wieder nichts.

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.

Hallo Stefan,

erstmal: schön, nach so langer Zeit mal wieder was von dir zu hören/lesen!

Zum Thema: Ich bin etwas erstaunt, dass du das Thema über 1 Jahr nach Inkrafttreten von PSD2 jetzt hoch bringst. Rein interessehalber: Hat es dich bisher nicht betroffen oder hat es einfach so lange gedauert, bis der Schmerz gross genug wurde? ;)

PSD2 war vor ziemlich genau einem Jahr hier das mit Abstand größte Thema und hat für Unmengen an Postings und grauen Haaren gesorgt. Genau deine Themen sind da auch schon viel diskutiert worden.

Ich persönlich handhabe es inzwischen so (meine beiden Banken nutzen die 90-Tage-Regel), dass ich die Salden und Umsätze von einem Hibiscus Payment-Server im heimischen LAN abrufen lasse. Intervall und Zeitfenster habe ich dabei so konfiguriert, dass täglich maximal 4 Aufrufe stattfinden (bei mehr Abrufen kann u.U. eine TAN-Abfrage kommen). Die Daten werden in meiner MySQL-Datenbank gespeichert, auf die ich auch per Desktop-Client zugreife. Überweisungen mache ich generell nur vom Desktop aus - nie automatisiert. Da alle 90 Tage auch für den Umsatzabruf bzw. das "Login" eine TAN erforderlich ist - und es ja keine Möglichkeit gibt, die TAN-Abfrage clientseitig zu forcieren, läuft der Server nach 90 Tagen in einen Fehler - weil er eine TAN braucht - aber keine ermitteln kann. Der Scheduler für die automatisierte Abfrage stoppt dann. Da die TAN-Abfrage dennoch ausgelöst wurde, kriege ich die Push-Benachrichtigung mit der TAN (früher die SMS) auf's Handy. Kann sie zwar nicht eingeben (i.d.R. kann man auch gar nicht schnell genug reagieren, weil das ja irgendwann passiert), weiss dann aber zumindest, dass es mal wieder soweit ist. Dann starte ich auf dem Desktop-Client eine Umsatzabfrage, gebe die TAN ein und starte den Scheduler auf dem Server neu. Danach habe ich wieder für 90 Tage Ruhe. Das ganze funktioniert auch nur deshalb, weil die Banken das 90-Tage-Fenster nur an die Benutzerkennung koppeln und nicht an den konkreten Client.

Das ist mein Vorgehen. Klar ist es etwas umständlicher geworden. Aber der Automatisierungsgrad ist für meinen Bedarf immer noch hinreichend.

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

hier könnte doch die "neue" (?) Funktion eine weitere Erleichterung sein:
umgesetzt wurde dies bereits:

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?

Im Fall von Olaf, hilft das, da er am Handy dann einfach bestätigen kann. Ansonsten hilft das wenig zur Automatisierung.
Automatisierung geht nur, wenn man die beiden Faktoren darstellen kann, ohne dass der Anwender eingreifen muss.
(z.B. Schlüsseldatei mit einem gespeicherten Passwort erfüllt Besitz und Wissen)

Ä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?

Die Spezifikation der TAN-Verfahren im FinTS-Standard ist im Juli um sog. "Decoupled" Verfahren erweitert worden, bei denen genau das möglich wird. Läuft ungefähr so ab (stark vereinfacht, Abweichungen möglich):

- Client sendet Auftrag an die Bank
- Bank sendet Freigabe-Request an Handy-App
- Client zeigt währenddessen einen Wartedialog an und und fragt in einer Schleife im Hintergrund alle paar Sekunden bei der Bank, ob die Freigabe schon erfolgt ist
- Bank antwortet dem Client dann irgendwann mit: "Jepp, erledigt, kannst weitermachen".
- Client zeigt Bestätigung an.

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.

[Decoupled-Zwei-Schritt-Verfahren]

Wieder mal ein weiteres nicht hardware-basiertes Sicherheitsverfahren, da keine Bankkarte erforderlich ist.
Zitat aus der Spezifikation:
"Von Institutsseite wird eine verfahrensspezifische Challenge ermittelt und an eine Authentifizierungsanwendung auf einem anderen Gerät des Kunden über einen getrennten Kanal gesendet (HKTAN#7)."

mfg Volker

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".

Wenn man sich allein damit beschaeftigt, ist es in der Tat so, dass der Grossteil der Zeit nur noch fuer das Aufrecht-Erhalten des Status-Quo verbraucht wird, weil dauernd neue TAN-Varianten, SEPA-Versionen oder eben PSD2-Änderungen kommen. Aber du musst dich ja nicht allein damit beschäftigen. Wenn man sich rein teilt, ist durchaus auch Zeit für die Umsetzung neuer GVs oder anderer Features, die man selbst gern hätte und die nicht nur aufgrund von äusseren Anforderungen rein kommen.

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

Ist das mit DecoupledPush gemeint? Ich habe aus der Spezifikation nicht verstanden, was DecoupledPush eigentlich meint.

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.

Kann ich zu 100% bestätigen. Mach keinerlei Spaß mehr, ist nur noch eine Quälerei.



Nein, Du bist nicht der Einzige.



Das sehe ich nicht so. EBICS ist ausschließlich für gewerbliche Kunden und basiert auf einem speziellen Vertragsverhältnis zwischen Firma und Bank. PSD2 war eigentlich für Endverbraucher gedacht und muss deshalb "idiotensicher" sein.



Auch da gebe ich Dir 100% Recht.



Ich glaube nicht, dass irgendein kommerzieller Hersteller (der keine 100%ige Banktochter ist) da irgendwie beteiligt ist. Ansonsten gebe ich Dir auch hier Recht.

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.

Hallo Kollegen,

vielen Dank fuer euer Feedback.



Damit habe ich nicht dir persoenlich widersprochen lieber Holger. Vielmehr gilt mein Unmut dem zugrunde liegenden Konzept (oder besser: dem fehlenden Konzept) was genau "Wissen und Besitz" bedeutet bzw. wie das Thema "2-Factors" zu interpretieren ist. Ich habe mich in den letzten Jahren viel damit beschaeftigt.



Das ist mir klar - reguliert werden die nur Anforderungen aus Sicht der Kunden und Banken. Gegen die Regulatoren habe ich auch nichts gesagt (obwohl ich auch dazu eine Meinung habe, aber das waere hier off-topic). Der Punkt ist offensichtlich dass das FinTS-Protokoll im Grundsatz nicht dafuer gemacht ist mit solch "dynamischen Anforderungen an das Authentifikations-System" umzugehen (und das ist meine eigentliche Kritik an die "Macher" der FinTS-Spec).

Konzepte wie Challenge-Response (auch dynamisch abhaengig vom Content), 2FA, delayed authentication, off-channel authentication etc. sind seit Jahren ein alter Hut und in der "normalen Welt" sehr gut etabliert. In der FinTS-Welt wollte man das Rad neu erfinden, hat dabei ein unregelmaessiges Sechseck erfunden, das jetzt bei jedem Durchlauf eine Ecke mehr bekommt - bis es vielleicht irgendwann mal ein Rad wird [wahrscheinlich aber eher nicht, es wird immer holperig sein].

Lange Rede kurzer Sinn: Holger, ich verstehe deinen Standpunkt dass wir dummen Entwickler nur die Spitze des Eisbergs der Komplexitaet innerhalb der Bankenwelt verstehen, und dass all die Kritik nicht angebracht ist weil "alles schon seinen Sinn hat".

Muss ich mich damit abfinden? Scheint so.

Muss ich das gut finden? Auf keinen Fall.

Kann ich da was aendern? Schoen waer's. Leider ist diese Branche so "closed" dass neue Ideen und Vorschlaege (e.g. zur grundsaetzlichen Verbesserung des Protokolls) niemals irgendwo "da oben" ankommen.