nemiah / phpFinTS

PHP library to communicate with FinTS/HBCI servers
MIT License
130 stars 39 forks source link

Sparkasse asks for TAN on every $fints->login() #431

Closed peukerjonathan closed 4 months ago

peukerjonathan commented 4 months ago

I ran into a problem this week with to accounts from the bank "Sparkasse Pforzheim-Calw". While everything was running smoothly until last week the bank started to ask for a TAN on every ->login() request since the beginning of this week. (After providing a TAN I can successfully communicate with the bank and get transactions, the account balance, etc) To make this even worse I have antoher account with the same bank which continued working fine, without having to provide a TAN on every request.

So I thought this would be an issue with the bank (some kind of misconfiguration) and gave them a call. Turns out it is not. Back in May 2023 the Sparkasse introduced a "device recognition mechanism" which enables the bank to store "trusted devices". If you login as a non trusted device you will have to enter a TAN every time. Only "trusted devices" can login without providing a TAN. This mechanism is allegedly already there since one year but now the Sparkasse is starting to enforce this mechanism and rolling out on all of their accounts one by one. The enforcement rollout will allegedly be finished on May 14 2024. So every Sparkasse account will be subject to this problem within the next weeks.

The phone contact unfortunately was unable to elaborate how this works on a technical level and was unable to point me to a technical documentation. However I think that some additional request parameters will have to be sent to the server during login procedure and some additional response parameters will be needed to store on client side so we can "authenticate as trusted device" upon the next call to login().

Has anyone else encountered this problem and how could I be of assitance in debugging this?

peukerjonathan commented 4 months ago

I was now able to talk to an employee of the ElectronicBanking department.

In our conversation he confirmed what I already wrote in my initial posting - the Sparkasse will be rolling out these changes until May 14th of 2024 - every client which then does not authenticate propery will need to enter a TAN on every login() request.

Basically one needs to react on the 9391 code with a "HKSYN" and request a customer id. This customer ID should be stored and resent with future requests to avoid further SCA challenges for 90-180 days.

He also provided me with the official announcement issued by the Finanzinformatik GmbH & CO KG which is the technical supplier of the Sparkasse Group:

Sehr geehrte Damen und Herren, im März 2023 hatten wir Sie über eine geplante Änderung im Bereich der FinTS-Schnittstelle informiert. Dazu möchten wir Ihnen nochmals aktuelle Informationen übermitteln. Bitte prüfen Sie, dass Ihre FinTS-Produkte beim Empfang des Rückmeldecodes 9391 korrekt mit einem HKSYN reagieren und damit die Synchronisation der Kundensystem-ID vornehmen. Anderenfalls würde künftig eine weitere Kommunikation vom Banksystem erneut mit dem Rückmeldecode 9391 abgewiesen. Die Ausführung bankfachlicher Geschäftsvorfälle würde somit nicht mehr möglich sein! Das geplante Verhalten stellt keine Neuerung dar, sondern entspricht dem Standard der FinTS-Spezifikation. Wir möchten Sie dennoch explizit darauf hinweisen, da wir seit 2016 in unseren FinTS-Systemen die Prüfung der von den FinTS-Clients eingereichten Kundensystem-IDs ausgesetzt hatten und diese nun wieder einführen. Diese bereits für Mai 2023 angekündigte Wiedereinführung der Prüfung der Kundensystem-ID durch den FinTS-Server haben wir verschoben, um den Zeitraum für die Prüfung und Anpassung zu verlängern.

Das geplante Verhalten stellt keine Neuerung dar, sondern entspricht dem Standard der HBCI-Spezifikation. Hierzu der Auszug aus der Spezifikation (siehe https://www.hbci- zka.de/dokumente/spezifikation_deutsch/fintsv3/FinTS_3.0_Formals_2017-10-06_final_version.pdf Kap. C.8):

Bevor ein Benutzer bei Verwendung des HBCI RAH- / RDH- bzw. des PIN/TAN-Verfahrens von einem neuen Kundensystem Aufträge erteilen kann, hat er im Wege einer Synchronisierung eine Kundensystem-ID für dieses System anzufordern (Ausnahme: bei Verwendung einer RAH-/RDH- Chipkarte ab Sicherheitsprofil-Version 3). Diese ID ist im Folgenden stets anzugeben, wenn der Benutzer von diesem Kundensystem aus Nachrichten sendet. Wenn eine Synchronisierung der Kundensystem-ID durchgeführt wird, ist das DE „Kundensystem-ID“ mit dem Wert ‘0’ zu belegen. Das DE "Identifizierung der Partei" im Signaturkopf in der DEG "Sicherheitsidentifikation, Details" ist mit dem Wert ‚0’ zu belegen. Kundensystem-IDs, die länger als 6 Monate nicht beim Kreditinstitut eingereicht wurden, können im Kreditinstitut gelöscht werden. Meldet sich der Kunde mit dieser Kundensystem-ID erneut an, wird keine Legitimierung zum Senden von Auftragsnachrichten erteilt. Der Kunde hat in diesem Fall eine erneute Synchronisierung durchzuführen. Da jedes Kreditinstitut die Kundensystem-ID unabhängig von an-deren Kreditinstituten vergibt, muss das Kundenprodukt in der Lage sein, für jeden Kreditinstitutszugang eine eigene Kunden-system-ID zu verwalten.

FinTS-Clients müssen die Kundensystem-ID korrekt verarbeiten können, da anderenfalls nach Aktivierung der Prüfung ein FinTS-Zugang (mit erneuter Synchronsationsaufforderung) abgewiesen wird. Es sollte gesichert sein, dass eine erhaltene Kundensystem-ID im FinTS-Client für einen Zeitraum von 6 Monaten erhalten bleibt. Anmeldungen mit unbekannter Kundensystem-ID werden sonst bei einer späteren Erweiterung unseres Systems zu einer SCA-Pflicht bei der Anmeldung führen.

peukerjonathan commented 4 months ago

I could provide logs of the login and tan procedure of an affected account, but would rather not post them here in the public. So if anyone is interested please let me know.

Philipp91 commented 4 months ago

We do store the Kundensystem-ID here.

Do you correctly persist and restore the FinTs instance after every usage (not only persist once after login and then reuse the same persisted data forever)?

As you can see here, that ID can be updated anytime the server sends a response. I presume that many banks map this to a session token.

If you think there's still an issue, I'll take time to read that whole email from them.

peukerjonathan commented 4 months ago

Thanks for the clarification! I was indeed persisting the fints instance, but it seems that I wasn't flushing my updated record to the database consistently. Which was working fine until now and only started to act up now when the Sparkasse implemented their changes. So I guess I just assumed this was simply not implemented yet...

My apologies - after I started to store the persiteted instance properly in my database everything started to work fine again.

Thanks for the excellent support and pointing me in the right direction. It is highly appreciated!