Martins key.matiq-Blog
>> Zurück zum Artikelverzeichnis >>
Digitaler Kontoblick – sauber oder nicht?
Geschrieben: 12.06.2024
Letzte Überarbeitung: 15.06.2024
Stichwörter: Grundsätze
Der Blog-Artikel "Die haben wohl alle Lack gesoffen" hat mich animiert, bezüglich der digitalen Bankkontoblicke tiefer zu bohren. Sind diese nun generell sicher oder eher nicht? Wenn sicher: Wieso verbieten die Banken die Weitergabe des Onlinebanking-Passworts, wenn sie ein Verfahren unterstützen, das genau diese Weitergabe erfordert? Wenn unsicher: Wie müsste das Verfahren denn sauber gestaltet werden?
Es geht hier nicht um die Bahn ...
... denn dazu ist alles in dem o. g. Artikel geschrieben. Das Verhalten der Bahn ist skandalös. Ganz anders ist das Verhalten der Banken zu bewerten, die digitale Kontoblicke ermöglichen. Sie sind schließlich nach der EU-Zahlungsdiensterichtlinie PSD2 dazu verpflichtet. Aber so ganz sauber scheint das Verfahren noch nicht zu sein.
Wie funktioniert der digitale Kontoblick?
Ich werde fündig bei Kredit-Zeit.de im Artikel "Digitaler Kontoblick – Ablauf, Datenspeicherung und automatische Datenauswertungen". Dort findet sich ein Link zu einer "Demo für den digitalen Kontoblick". Wenn man diesem folgt und als Aktion "Digitaler Kontoauszug" und als Bank "Testbank" wählt und danach beliebige Login-Daten verwendet, sieht man, wie z. B. Tink Daten aus dem Kontoblick zusammenstellt. Ähnlich geschieht dies für Bonitätsprüfungen.
Was ist daran sauber?
Wenn man weiß, dass man sich auf einer Tink-Domain befindet und Tink die Genehmigung gibt, mit den eigenen Onlinebanking-Anmeldedaten die entsprechende Abfrage zu tätigen und die Auswertung vorzunehmen, sieht das im Prinzip schon recht sauber aus.
Was aber ist da unsauber?
Das Banking-Passwort sollte man eigentlich nur bei der betroffenen Bank im Online-Banking eingeben. Es ist schon seltsam, dass Banken einerseits per AGB verbieten, das Banking-Passwort Dritten weiterzugeben1, andererseits aber akzeptieren, dass das Banking-Passwort ihnen über Dritte zur Autorisierung der Kontoabfrage mitgeteilt wird.
Aber es wird doch immer behauptet: "der Login ist sicher"2
Die Prüfung durch den TÜV bedeutet immer nur eine Momentaufnahme. Solange die Login-Daten in einem Formular unter einer Tink-Domain eingegeben werden, hat Tink über diese Daten die volle Kontrolle, d. h. ob diese gespeichert werden oder nicht, liegt nicht in der Hand von Nutzer*in und Bank, auch nicht in der Hand vom TÜV, sondern allein von Tink.3
Wie wäre es sauberer?
Wenn man im Online-Banking der Bank die Genehmigung erteilen könnte, dass z. B. Tink einen Kontoblick tätigen darf, wäre nichts dagegen einzuwenden. Es wäre auch nichts dagegen einzuwenden, wenn man ein spezielles Passwort für Kontoblicke (oder andere Aktivitäten von Drittdiensten) festlegen könnte, das man dann z. B. Tink mitteilen könnte, damit Tink auf die Kontodaten zuzugreifen kann.
Letzteres hätte den Vorteil, dass die Schnittstelle zwischen Banken und Drittdiensten gar nicht geändert werden müsste. Lediglich die Software für das jeweilige Online-Banking müsste entsprechend etwas abgeändert werden.
(Man könnte das auch so gestalten, dass ein Extra-Passwort für Drittdienste optional ist, aber auch weiterhin ermöglicht wird, für diesen Zweck das normale Online-Banking-Passwort anzugeben. Damit hätte die Konto-Eigenümer*in die Freiheit, selber zwischen höherer Sicherheit und mehr Einfachheit zu wählen.)
Was ist denn der Unterschied zwischen beiden Verfahren?
Im gegenwärtigen unsauberen Verfahren erhält Tink das Kennwort für das interaktive Online-Banking der Konto-Eigentümer*in. Auch wenn Tink dieses Kennwort gleich wieder vergisst:
- Man muss Tink vertrauen, dass Tink das Kennwort tatsächlich vergisst. Es gibt aber die Regel, dass Vertrauen, indem es in Anspruch genommen wird, auch verbraucht wird.
- Im sauberen Verfahren ist dagegen die Mitteilung des Online-Banking-Kennworts (mit dem man auch Überweisungen tätigen kann oder auch z. B. das Kennwort ändern kann) unnötig.
Man kann einwenden, dass es ja noch einen zweiten Faktor für die Authentisierung gibt, den man ohnehin nicht aus der Hand gibt (also z. B. eine SMS aufs eigene Handy mit einer TAN).
Ja, möglicherweise ist das so.4 Aber ein zweiter Faktor sollte der Risikominderung dienen, ein Notanker sein und kein Grund sein, den ersten Faktor (das Kennwort) aus der Hand zu geben.5
Man kann doch das Kennwort ändern. Reicht das nicht an Sicherheit?
Leicht passiert es, das Kennwort eben nicht gleich zu ändern. Man wird abgelenkt oder vergisst einfach, es zu tun.
Außerdem ist eine Änderung eines Kennworts, wenn eine komplett neue Phrase gewählt wird, aufwändig. (Eine nur teilweise Änderung wäre deutlich unsicherer.6) Jeder unnötige zusätzliche Aufwand für Kennwörter geht aber meist zu Lasten der Passwortstärke und damit der Passwortsicherheit.
Ausnahmen von wichtigen Regeln sollte man nicht leichtfertig machen!
Für jeden Zweck sollte man ein eigenes Kennwort wählen, das dann auch nicht aus der Hand gegeben wird, außer für den Zweck, für den es erstellt wurde.7. Dies ist die zweitwichtigste Regel für die Passwortsicherheit.8. Es gibt auch Ausnahmen von dieser Regel:
- Von Kennwörtern, die man händisch eingeben muss (z. B. für die Anmeldung an Computern), kann man sich, wenn sie stark sein sollen, nicht beliebig viele merken. Da ist meist schon eine Vereinfachung nötig.
- Passwortmanager sind sinnvoll, um viele unterschiedliche starke Kennwörter zu verwalten. In der Abwägung der Risiken macht es deshalb Sinn, einem Passwortmanager Kennwörter anzuvertrauen, z. B. auch das Banking-Passwort.9
Aber jede weitere Ausnahme ist schon sehr kritisch zu sehen. Leichtfertigkeit in einem Fall führt dann auch leicht zu einem Dammbruch.
Was ist nun mit den AGB?
Die Regel in den AGB von Banken, dass man das Banking-Passwort nicht weitergeben darf, können diese Banken getrost in der Pfeife rauchen, wenn sie Kontoblicke durch Tink mit eben solchen weitergegebenen Kennwörtern zulassen. Solange die Banken ihre AGB nicht dahingehend abändern, dass sie die von ihnen selbst direkt unterstützten Ausnahmen aufführen, werden sie wohl bei jeder juristischen Auseinandersetzung diesbezüglich unterliegen.10
Wieso schätzen die Banken die Regeln der Passwortsicherheit11 so gering?12
Beim Online-Banking prallen zwei Welten aufeinander: Die ältere Welt der Mainframes und geschlossenen Rechenzentren und die jüngere Welt des Internets.
Beide Welten benötigen und fördern unterschiedliche Kompetenzen. Die Welt der Rechenzentren braucht (für sich selbst) die 4 S der Passwortsicherheit keineswegs so dringend wie die Welt des Internets.13
Bei den Banken ist intern die Welt der Rechenzentren dominierend, aber zumindest ihre Privatkund*innen leben hauptsächlich in der Welt des Internets. Und diese Welt braucht die Regeln der Passwortsicherheit ganz dringend.14
Wer Erfolg haben will, sollte als Firma und erst recht als Dienstleister auf die Kundenzufriedenheit achten. Deshalb sollten die Banken nicht so sehr darauf achten, was sie in ihrer Rechenzentrumsmentalität für ausreichend halten, sondern was der Sicherheit der Kund*innen tatsächlich, aber auch gefühlt dient. Ich fürchte jedoch, dass es auch bei den Banken einen Eisberg der Ignoranz gibt.
Fazit
Banken und Datenschützer*innen haben durchaus gemeinsame, aber auch verschiedene Interessen und Prioritäten.
Die Banken sehen eher die Welt der Rechenzentren, und verfolgen die Interessen ihres Unternehmens, d. h. achten auf wenig Aufwand, wenige Risiken für sich selbst und wollen keine Gefährdung von Profiten. Sie tun sich dagegen schwer mit den 4 S der Passwortsicherheit.
Datenschützer*innen sehen eher die Welt des Internets, denn das ist die Welt der Privatleute. Die 4 S der Passwortsicherheit sind für sie eine Selbstverständlichkeit. Ihre Klientel ist aber unsicher bei diesem Thema. Sie ist stark beeinflusst auch von Desinformation, auch von solcher, die aus Unkenntnis von den Banken stammt.
Zusammenkommen könnten beide Seiten dann, wenn es um die Vermeidung von Hacking geht.
Die PSD2 ist bezüglich der Beauftragung von Drittdiensten durchaus komplex. Eine faire Umsetzung erfordert, sich in die Sicht der Kund*innen hineinzuversetzen und auch eine ziemliche Kompetenz in Sachen digitaler Sicherheit. Daran lassen es aber die Banken beim Thema Kontoblick noch offensichtlich missen.
Nachdem es bei den Banken (zumindest bei den klassischen Banken) noch immer an Verständnis der Passwortsicherheit mangelt, verwundert es nicht, dass die Verantwortlichen große Schwierigkeiten haben, auch nur ansatzweise zu begreifen, warum viele Nutzer*innen ihre Probleme mit dem digitalen Kontoblick haben.
Noch schwerer verstehen die Verantwortlichen, dass für den Teil der Nutzer*innen, der jetzt weniger Probleme damit hat, wohl die eigentlichen Probleme erst noch kommen werden: Weil diese Menschen nicht an saubere Regeln im Umgang mit Passwörtern gewöhnt wurden, sondern an unsaubere Regeln und weil sie damit auch gegenüber Phishing-Angriffen anfällig gemacht wurden.
Phishing lässt sich nur mit sauberen, klaren, konsequent beachteten Regeln bekämpfen. Unsaubere Regeln verwischen und relativieren jedoch die sauberen Regeln und ermöglichen, dass den Menschen Fallen gestellt werden.
1) Das Verbot ist für sich genommen völlig in Ordnung.
2) Z. B. schreibt die Bank of Scotland über den Digitalen Kontoblick unter "Ist der Login sicher?": "Ja, der Login ist sicher. Ihre Login-Daten sind nicht einsehbar und werden niemals gespeichert. Die Übertragung der Daten erfolgt verschlüsselt und ist durch den TÜV geprüft ('Geprüfter Datenschutz', TÜV Saarland).
3) Die JavaScript-Datei dafür heißt "xs2a.js". Sie ist von Tink erstellt und wird beim Aufruf der Tink-Seite geladen. Sie ist 56 Kilobyte groß, ziemlich unleserlich (da sie wohl durch einen Obfuscator gelaufen ist) und daher ist es für eine normale Nutzer*in kaum überprüfbar, was xs2a.js tatsächlich macht. Es bleibt also eine Frage des Vertrauens in Tink, ob das Kennwort tatsächlich direkt an die Bank geschickt wird und ansonsten nur im Browser der Nutzer*in verbleibt (oder besser noch gelöscht wird).
4) Ich habe das nicht getestet. Ein eigenes Konto für den Test einzurichten, war mir zu aufwändig, ein bestehendes zu verwenden, ebenso, da ja Kontoinformationen immer auch Daten von Dritten beinhalten, deren Einverständnis ich hätte einholen müssen.
Wenn es aber so ist, dass beim Kontoblick auch der zweite Faktor abgefragt wird (also z. B. eine TAN), damit Tink oder Verimi den Kontoblick durchführen können, müsste die Bank auch mitteilen für welche Aktion diese TAN berechtigt. Anderenfalls könnte ja der Drittdienst z. B. statt einen Kontoblick abzufragensich selbst interaktiv in das Online-Banking anmelden und könnte dann mit der von der Kund*in übermittelten TAN viel mehr Rechte bekommen, als die Kund*in wähnt, also z. B. nicht nur die Abfrage des einen Girokontos, sondern auch die die Abfrage von weiteren Konten (Geschäftskonto, Konten von betreuten Personen), die die Kund*in über das Online-Banking verwaltet.
Aber das habe ich alles nicht getestet, ich möchte ja auch für mich und andere kein Risiko eingehen.
Und das ist ja auch die ganze Krux an dem Verfahren, dass man (z. B. ultimativ von der Bahn) gezwungen wird, ein Verfahren anzuwenden, von dem man gar nicht genau weiß, wie es letztendlich in der Praxis (d. h. bei der eigenen Bank, nicht bei einer "Testbank") funktioniert.
5) Das ist keineswegs nur theoretisch gemeint. Es gibt auch eine Angriffsart, die von Hacker*innen stammt, die bereits ein Kennwort erbeutet haben und nun nur noch den zweiten Faktor benötigen: Ermüdungsangriffe. Man wird mit E-Mails oder anderen Nachrichtsformen bombadiert, die TAN oder einen Code oder was auch immer für den zweiten Faktor steht, preiszugeben. Und tatsächlich mit einigem Erfolg.
6) Wenn dann z. B. der Zahlungsdienst wieder mal in Anspruch genommen wird und das geänderte Kennwort bekommt, könnte aus beiden Kennwortversionen möglicherweise die nächste, dritte Kennwortversion erraten werden oder zumindest die Anzahl der wahrscheinlichen Möglichkeiten dafür stark eingeschränkt werden.
7) Interaktive Verwaltung via Online-Banking und Erlaubnis für digitalen Kontoblick sind aber zwei verschiedene Zwecke.
Anders wäre der Fall gelagert, wenn man z. B. durch einen Drittdienst mehrere Konten bei verschiedenen Banken gemeinsam verwalten will. Dann könnte es durchaus angebracht sein, den Zugriff auf den Drittdienst jeweils komplett zu übertragen, also die regulären Banking-Passwörter an den Drittdienst zu übergeben.
8) Siehe den Blog-Artikel "Passwortsicherheit" (Abschnitt "Stillschweigen").
9) Es gibt sogar noch mehr Ausnahmen, an die man meist gar nicht denkt, weil es jedem*jeder völlig klar ist, dass man gar nicht um diese herum kommt (und die ich deshalb der Lesbarkeit halber im Haupttext dieses Artikels weggelassen habe):
- Bei Internet-Logins müssen Sie das Kennwort im Browser eingeben ganz egal, ob Sie dessen Passwortmanager verwenden oder nicht. D. h. der Browser kennt in jedem Fall alle Internetkennwörter, die sie verwenden.
- Aber auch das Gerät und auch das Betriebssystem, auf dem Sie ein Kennwort (egal ob über Tastatur oder über einen Touchscreen) eingeben, erhält dieses Kennwort. Beide geben gibt es aber (hoffentlich) nur weiter und vergessen es dann gleich wieder.
Das sind mit den im Haupttext genannten schon eine ganze Reihe Ausnahmen und Ansatzpunkte für Angriffe, die jedoch in aller Regel von verantwortungsbewussten und kompetenten Lieferanten (der Hardware, des Betriebssystems, des Browsers und des Passwortmanagers) abgesichert werden. Weitere als diese meist undbedingt nötigen Ausnahmen zuzulassen, würde aber meist bedeuten, dass man eher an weniger kompetente Lieferanten gerät:
Der beschriebene Umgang mit den Kontoblicken zeigt ja gerade, dass weder die Dritt-Dienste (wie Tink und Verimi) noch die Banken hohe Kompetenz in der Passwortsicherheit besitzen:
- Wer in der Passwortsicherheit kompetent ist, versucht gerade selbst so wenig wie möglich Passwörter zu ergattern.
- Und wenn man welche benötigt, würde darauf dringen, dass man mit diesen Kennwörtern nur das für den Zweck nötige anfangen kann.
- Und man würde darauf dringen, dass dieses Kennwort nicht schon woanders (z. B. für den Kund*innenzugriff auf das Onlinebanking) verwendet werden kann.
- Und man würde auch verlangen, dass dieses extra-Passwort für den Kontoblick von der Kund*in im Online-Banking erstellt wird, so dass ganz klar ist: Die Kontrolle über alles behält die Kund*in.
- Und man würde niemals Vertrauen einfordern, sondern alles dafür tun, dass sich Vertrauen von selbst entwickelt (weil man gerade auf die eben genannten Dinge achtet).
10) Die Regel in den AGB dient ja dazu, Bankkund*innen grobe Fahrlässigkeit zu unterstellen, falls sie das Banking-Passwort aus der Hand gegeben haben, damit die Bank dann nicht für evtl. Schäden haften muss.
Aber wie soll eine grobe Fahrlässigkeit bei den Bankkund*innen vorliegen, wenn die Regeln der Bank in sich widersprüchlich sind? Also wenn einerseits die nach der PSD2 verpflichtende Schnittstelle nur bei Weitergabe des Banking-Kennworts funktioniert, die AGB dies aber generell verbieten, ohne Ausnahmen zu benennen. Wie soll da die Bankkund*in noch durchblicken? Fahrlässigkeit ist da wohl eher bei der Bank zu sehen.
11) Siehe den Blog-Artikel "Passwortsicherheit" (Abschnitt "Stillschweigen"). Die Regeln (die "4 S der Passwortsicherheit"), stammen in diesem Wortlaut von mir selbst. Aber jede*r, mit dem ich darüber gesprochen habe, hat gleich gesagt: "Klar, kenn ich." D. h. ich habe einfach nur zusammengeschrieben, was unter Leuten, die sich mit Passwortsicherheit beschäftigen, gemeinsames Gedankengut ist. (Sollte jemand anderer Ansicht sein, bitte ich um ein "Feedback").
12) So lag die Länge der PINs beim Online-Banking ursprünglich meist bei vier Ziffern, während damals bei anderen Web-Apps mindestens acht Zeichen schon üblich waren. Während das NIST seit 2017 empfiehlt, die Länge von Kennwörtern nach oben hin nicht zu begrenzen (außer sie ist unsinnig hoch, d. h. Passphrasen mit bis zu 100 Zeichen sollten durchaus möglich sein), verhindert die Online-Banking-Software für die Genossenschaftsbanken und die Sparkassen Passwörter mit mehr als 20 Zeichen.
Die Zumutung, das Online-Banking-Passwort an Dritt-Dienste weiterzugeben hat auch etwas mit Geringschätzung der Passwortsicherheitsregeln zu tun. Es ist die alte Denke, dass es schon reicht, die Dritt-Dienste zertifizieren zu lassen, anstatt die Regel des maximalen Stillschweigens zu befolgen. Sonst wären die Online-Banking-Entwickler*innen schon auch auf die Idee gekommen, die ich im Abschnitt "Wie wäre es sauberer? beschrieben habe.
Auch die sichere Speicherung von Kennwörtern in Passwortmanagern (drittes S der Passwort-Sicherheit) wurde durch Online-Banking-Web-Apps torpediert, indem sie das "autocomplete"-Attribut missbrauchten und grundsätzlich auf "off" stellten. Die Browser-Entwickler*innen sahen sich gezwungen, dieses Attribut grundsätzlich zu ignorieren, um echter Sicherheit Vorrang vor Pseudosicherheit zu gewähren. (Leider fielen dieser Aktion auch einige sinnvolle Anwendungsfälle von "autocomplete=off" zum Opfer.)
Der vierte Aspekt der Passwortsicherheit, das Sicherheitsnetz, musste den Banken auch erst aufgezwungen werden. Dazu gehört die Zwei-Faktor-Authentisierung bei der Anmeldung im Online-Banking. Diese wurde erst durch die PSD2 mit eingeführt. Vorher habe ich z. B. weder bei der Hypo-Vereinsbank, noch bei der Postbank, noch bei einer VR-Bank so etwas gesehen. Bei Nicht-Banking-Web-Apps aber durchaus.
13) Rechenzentren erfordern (und fördern dadurch) viel Kompetenz in Sachen Zugangskontrolle und Personalauswahl, Schutz gegen Diebstahl und Sabotage, Schutz gegen Stromausfall, Feuer, Wasserrohrbruch.
Dadurch ist aber auch bereits der Rest der Welt vom Zugang ausgeschlossen und die Aufgabe der Authenfikation und Autorisierung der Mitarbeiter*innen (und evtl. Besucher*innen) ist viel einfacher als im Internet.
Brute-Force-Angriffe, bei denen unzählige Anmeldeversuche nach Passwortlisten durch Botnets auf ein Gerät einprasseln, sind hier undenkbar. Die Angreifer*innen würden sofort identifiziert und kalt gestellt. Ebenso funktionieren innerhalb eines Rechenzentrums Denial-of-Service-Angriffe kaum. Wenn an einem Rechner mehrfach die Anmeldung scheitert, kann man den Zugang einfach für einige Minuten oder länger sperren. Damit können auch kurze Kennwörter sicher sein, weil es in absehbarer Zeit nicht möglich ist, alle möglichlichen Kennwörter durchzuprobieren.
In der Welt der Rechenzentren lag es nahe, einfach lange Banking-IDs für die Anmeldung im Online-Banking zu vergeben. Diese verhindern (wenn gehalten) Denial-Of-Service-Angriffe. Allerdings, so geheim wie Kennwörter sind sie nun doch nicht. In einem geschlossenen Betrieb wären sie OK, aber im Internet sind sie eher eine Krücke. Jedenfalls erlauben diese halbgeheimen IDs, nach einer Reihe Fehlanmeldungen, das Konto zu sperren, ohne dass man riskiert, dass gleich alles über Denial-Of-Service-Angriffe zusammenbricht
Die Rechenzentren der Banken halten sich also ganz tapfer, sind aber nicht gerade ein Vorbild für alle in Sachen Schutz gegen Angriffe aus dem Internet. Nachahmer*innen, die sich nicht eine teure Infrastruktur leisten können, würden nämlich schnell merken, dass solche halbgeheimen IDs nicht so leicht geheimzuhalten sind. Beim ersten Datenabfluss von dem Server wären die wohl schon sämtlich im Klartext geklaut. Und die mitgeklauten verschlüsselten Kennwörter, würden, da meist zu schwach gewählt, bald offline mit der Brute-Force-Methode entschlüsselt.
14) Schon einen kleinen Server im Internet zu betreiben, erfordert (und fördert dadurch) Kompetenz in Sachen Serversicherheit, aber auch Passwortsicherheit, sonst droht schnell Ungemach.
Im Internet hängt alles physikalisch zuzammen (über Drähte, Lichtleiter und Funk), aber die Geräte sind weit verstreut. Die logischen Zugänge können nur über Passwörter und krytografische Schlüssel und Hashes kontrolliert werden.
Im Internet kann man nicht einfach nach fünf falschen Anmeldeversuchen das Anmeldekonto sperren, denn das würde zu Denial-of-Service-Angriffen geradezu einladen. Anmeldekonten müssen also resistent gegen Brute-Force-Angriffe sein, d. h. sie müssen durch starke Kennwörter geschützt werden.
Diebstähle und physikalische Sabotage lohnen sich dagegen in Einzelhaushalten und Home-Offices kaum, jedenfalls nicht so wie bei einem ungeschützten Rechenzentrum.
Im Internet braucht man auf Dauer saubere Lösungen. Natürlich werden auch dort Banking-IDs nicht herumposaunt, aber die Kennwörter müssen schon so stark sein, dass es nicht nötig ist, ein Konto nach Fehlanmeldungen zu sperren. (D. h. sollte eine Hacker*in an eine Banking-ID kommen, sollte es ihr dennoch nichts nützen.)