Hallo zusammen,
im Rahmen meiner Arbeit bei der FSFE habe ich mich mit dem Thema Freie Software im Bereich Banken beschäftigt und möchte meine Erfahrungen und Gedanken mit euch teilen. Das Thema ist Teil des größeren Themas der Appifizierung/des Drucks zur Verwendung unfreier Apps für bestimmte Interaktionen.
Mir persönlich fällt in den letzten Jahren auf, dass Banken sehr stark versuchen, ihre unfreien Apps für Bankgeschäfte selbst und auch für die so genannte Zwei-Faktor-Authentifizierung zu erfordern. Tatsächlich blockieren sie oft andere Authentifizierungsmethoden ganz. Das ist natürlich ein Problem für uns, und deshalb habe ich mich mit diesem Thema etwas genauer beschäftigt.
Das niederländische FSFE-Team hat hier einen wunderbaren Anfang gemacht, indem es eine Bank kontaktiert hat, um zu erfahren, warum sie es ihren Kunden erschwert, Freie Software zu benutzen. Meine Aufgabe war es, das Thema allgemeiner anzugehen. Leider war es sehr schwierig, direkt von Banken Antworten zu erhalten. Eine sehr häufige Rückmeldung war, dass es rechtliche Anforderungen gibt, die Dinge so zu tun, wie sie es tun, und dass die IT-Abteilungen vernünftige Entscheidungen getroffen hätten, die nicht zu sehr hinterfragt werden sollten.
Ein Grund, den die Banken manchmal anführten, war PSD2, eine EU-Richtlinie zur Regulierung von Zahlungsdiensten und Zahlungsdienstleistern. So wie ich es nach einigen Hintergrundrecherchen sehe, schreibt PSD2 offenbar keine genauen technischen Maßnahmen vor, auch nicht für den zweiten Faktor. So wie die Banken PSD2 interpretieren, bedeutet dies jedoch, dass sie die Authentifizierngs-Secrets an eine bestimmte Hardware binden müssen. Meiner Meinung nach ist diese Auslegung bereits das erste Problem für Freie Software, denn auch wenn dies keine rechtliche Anforderung ist, schließt es Zwei-Faktor-Lösungen wie TOTP aus, bei denen die Secrets auf mehreren Geräten verwendet oder einfach durch Verwendung einer entsprechenden TOTP-App extrahiert werden können.
Das zweite große Problem ist, wie Banken die Secrets an die Hardware binden: vollständig in Software. Dies macht es erforderlich, dass die Banking-Apps auf gerootete Telefone usw. prüfen, denn wenn ein Telefon gerootet ist, könnte das Secret theoretisch extrahiert werden. Die Root-Checks erfolgen in der Regel durch die Verwendung von Bibliotheken in den Apps, die Sicherheit auch in bösartigen Umgebungen versprechen, z.B. auf einem von Malware befallenen Telefon. Die Banken verlassen sich derzeit mehr auf solche Sicherheitsversprechen als auf tatsächliche Sicherheit, denn echte Sicherheit würde beispielsweise bedeuten, eine richtige Zwei-Faktor-Authentifizierung zu implementieren, statt zwei Apps auf demselben Telefon laufen zu lassen und dies Zwei-Faktor-Authentifizierung zu nennen.
In Kombination sind diese Probleme noch gravierender, da praktisch alle Banken das Verfahren so implementieren und es zu einer Art Best Practice geworden ist. Die Banken befürchten, dass sie bei einer anderen Vorgehensweise im Falle einer angeblich nicht autorisierten Transaktion haftbar gemacht werden könnten. Leider ist es, wie in anderen Bereichen auch, oft einfacher, das zu tun, was alle anderen tun, auch wenn es Schwächen hat, denn dann kann man sein Vorgehen wenigstens damit verteidigen, dass man sich an den "Standard" hält. Und in diesem Fall wird dadurch leider Freie Software eingeschränkt.
Eine Art Ausweg aus dieser Situation ist die Verwendung von Secure Elements in Telefonen. Durch deren Verwendung wären die Secrets tatsächlich an die Hardware gebunden. Das würde bedeuten, dass Freie Software das Secure Element ähnlich wie eine Smartcard nutzen könnte, indem wir es einfach nutzen, um eine Transaktion zu signieren. Dadurch wären Root-Checks und unfreie Apps nicht notwendig. Wie bei einer Smartcard würden jedoch in der Regel immer noch unfreie Schritte stattfinden, nur eben in Hardware. Auch dies wäre also keine perfekte Lösung.
Das größere Problem dabei ist jedoch, dass es keine Standardmethode für die Kommunikation mit Secure Elements gibt, was es für Banken schwierig macht, sie zu verwenden, und es würde erfordern, dass sie eine Liste von Secure Elements führen müssten, so wie eine Liste von CAs. Hinzu kommt, dass die Banken wahrscheinlich nicht auf diese Lösung umsteigen, so lange es keine Zertifizierung dafür gibt; so lange sie eine funktionierende Lösung haben, gibt einfach keinen großen Anreiz für sie, etwas zu ändern.
Eine Sache, die ich sehen konnte, ist, dass Banken oft noch ältere Standards verwenden, die den Zugang mit Freier Software ermöglichen könnten. Einige Apps geben zum Beispiel Fehlermeldungen mit HBCI-Fehlercodes aus. Das hörte sich zunächst vielversprechend an, denn wenn es irgendwo noch ein System gibt, das mit Freier Software kompatibel ist, dann könnten wir vielleicht darauf zugreifen. Leider ist es offenbar jedoch oft so, dass Banken eine weitere Schicht um eine ältere Schnittstelle herum bauen und dann nur noch die neuere Schicht nach außen verfügbar machen. Das mag aus der Sicherheitsgesichtspunkten sogar sinnvoll sein, wenn die Wartung dieser älteren Systeme schwierig ist. Auf diese Weise können Banken intern weiterhin Legacy-Systeme einsetzen, ohne dabei Sicherheitslücken öffentlich angreifbar zu machen, und gleichzeitig haben sie nach außen hin moderne Schnittstellen zur Verfügung. Das bedeutet, dass es leider zu kurz gedacht ist, dass wenn Banken intern HBCI intern nutzen, sie uns einfach weiterhin Zugang dazu geben könnten.
Ein weiterer Lösungsansatz besteht darin, dass Banken verpflichtet sind, Dritten Zugang zu gewähren, um neue Dienste auf Basis bestehender Bankkonten zu ermöglichen. Dies würde es theoretisch erlauben, einen solchen Dienst in Freier Software anzubieten, aber in der Regel ist für die Anmeldung immer noch die sogenannte Zwei-Faktor-App der Bank erforderlich, so dass uns auch das nicht viel hilft.
Irgendwann dachte ich, es gäbe ein Beispiel für eine Bank, die TOTP als zweiten Faktor (und Anmeldung ohne zweiten Faktor) zulässt: Paypal. Aber soweit ich weiß, tritt Paypal hier nicht als Bank, sondern als Zahlungsanbieter auf und nutzt seine Banklizenz für andere Dinge. Das bedeutet, dass Paypal zwar auf den ersten Blick wie ein positives Beispiel in dieser Hinsicht aussieht, es aber doch nicht ist, weil die Anforderungen an Zahlungsdienstleister sehr anders als die für Banken sind.
Ich bin neugierig, was ihr über dieses Thema denkt. Welche Erfahrungen habt ihr mit eurer Bank gemacht? Wie macht ihr euer Banking? Gibt es einen wichtigen Aspekt, den ich übersehen habe? Ich freue mich über jede Rückmeldung.
Happy hacking! Florian
Nabend Florian,
On Thu, Feb 22, 2024 at 07:35:55PM +0100, Florian Snow wrote:
Ich bin neugierig, was ihr über dieses Thema denkt. Welche Erfahrungen habt ihr mit eurer Bank gemacht? Wie macht ihr euer Banking? Gibt es einen wichtigen Aspekt, den ich übersehen habe? Ich freue mich über jede Rückmeldung.
bei einer Sparkasse nutzte ich chipTAN. Anfangs mit deren TAN-Generator.
Die NIBC hatte letztes Jahr die durchaus ungreifbare SMS-Tan abgelöst. Wer nicht deren SecureGo plus-App will, kann mit sm@artTAN plus arbeiten. Da bekommt man kostenpflichtig eine Chipkarte und kann mit z.B. Reiner tanJack photo QR arbeiten. Da dies Gerät auch das chipTAN der Sparkasse beherrscht, habe ich ein Gerät und je Bank eine Chipkarte. Ich nutze das am Laptop. Ohne Smartphone erübrigt sich die mobile Anwendung.
Ich hatte mal mit der 1822direkt geliebäugelt. Die bieten aber nur ihre 1822TAN+ App oder QR-TAN+ App, also nur Apps - kein alternatives Hardwareverfahren. https://www.1822direkt.de/service/fragen-und-antworten/online-banking-und-ap... Hatte die auch mal angeschrieben. So kann ich dort halt nicht Kunde werden.
On Thu, 22 Feb 2024, Florian Snow wrote:
im Rahmen meiner Arbeit bei der FSFE habe ich mich mit dem Thema Freie Software im Bereich Banken beschäftigt und möchte meine Erfahrungen und Gedanken mit euch teilen. Das Thema ist Teil des größeren Themas der Appifizierung/des Drucks zur Verwendung unfreier Apps für bestimmte Interaktionen.
Ich bin bei der GLS- und der EthikBank. Bei beiden kann ich den gleichen PhotoTAN-Generator benutzen. Die Anbindung an meine Buchhaltung mit hledger schaffe ich mit dem CSV-Export.
Beide Banken sind vor zwei bzw. einem Jahr intern von der Software Bank21 auf Agree21 umgestiegen, was anscheinend ein Umstieg von der besseren auf die schlechtere Software war, aber die Volksbanken wollten ihre Softwarebasis vereinheitlichen und die Entscheidung trifft das Management und nicht die Techniker, wie mir ein Informatiker der Volksbanken verraten hat, und Agree21 hat mehr die Smartphone-App-Optik auf dem Desktop. Egal, PhotoTAN und CSV-Export funktionieren weiterhin.
Ein Handy besitze ich nicht. Deswegen musste ich mich von der HypoVereinsbank trennen. Die hatte 2019 von Papier-TAN auf drei TAN-Arten umgestellt, wo von einer versprochen wurde, dass sie ohne Handy funktionieren würde. Für diese eine TAN-Art sollte ich mir einen eigenen TAN-Generator kaufen, was ich gemacht habe. Nach Erhalt stellte sich heraus, dass zum Freischalten eine Handy-Nummer erforderlich ist. Ich habe die Bank gefragt, wozu sie eine Handy-Nummer braucht, warum da keine Festnetznummer geht. Naja, sie müssten mir einen Bestätigungscode senden. Warum das mit Festnetz nicht geht, weiß am Bankschalter und in der Hotline keiner. Es leuchtete mir nicht ein, wie die Bank irgendwas mit einer ihr bislang unbekannten Handynummer authentifizieren will, wohingegen sie eine Festnetznummer von mir bereits besitzt und erfolgreich genutzt hat. Ich hatte mich beim Datenschutzbeauftragten beschwert, dass die Bank anscheinend Handynummern ohne erkennbaren Zweck sammelt. Der Datenschutzbeauftragte hat ausgerichtet, dass die Bank frei aussuchen dürfe, wie sie Authentifizerungen gestaltet. Naja.
Papier-TAN war auch eine Zwei-Faktor-Authentifizierung und nicht schlechter als das Smartphone-Zeugs. Inzwischen sind auch einige erfolgreiche Fälle von Enkeltricks bekannt geworden, wo Betrüger trotz 2FA Konten abgeräumt haben. Ich denke, man kann recht zuverlässig feststellen, dass diese Smartphone-Zwei-Faktor-Authentifizierungen nicht sicherer sind und wenn beide Faktoren auf einem Gerät laufen, sogar noch unsicherer als Papier-TAN. Es wird den Nutzern auch nicht erklärt, welche Arten von Betrug die 2FA-Systeme abwehren sollen, wie sie Betrug erkennen, welche Zahlen sie mit dem TAN-Generator vergleichen müssen und was im Falle einer Abweichung zu tun ist. Ganz im Gegenteil: Nahezu alle Firmen erziehen ihre Kunden dazu, Fehlermeldungen wegzuklicken und sich an ständig wechselnde Designs zu gewöhnen und sich nicht über alternative Domains zu wundern, alle Cookies und JavaScripte zu akzeptieren.
Hallo,
also wir sind geschäftlich bei der GLS Bank und privat noch bei der Volksbank / Sparkasse. Für alle drei nutzen wir den gleichen TAN-Generator, bei der GLS mit einer extra Banking-Card. Alle Konten verwalten wir mit der freien Banking-Software Hibiscus, auf welcher auch noch eine Vereinsverwaltung läuft.
Von den Smart-TAN oder der 2F-Auth. mit Smartphone halten wir nichts. Die Sparkasse versucht das ja auch durchzudrücken - aber die Kunden (vor allem die älteren) wollen nicht und so läuft es nach wie vor mit TAN-Generator problemlos.
Ich finde es auch sehr fragwürdig, dass der Bürger zum einen gezwungenermaßen ein Girokonto braucht - und zum anderen dann durch die Banken in eine technologische Abhängigkeit gebracht wird, aus der sich viele Kunden (mangels Wissen) praktisch nicht mehr befreien können. Ich habe bereits Fälle erlebt, wo jungen Leuten ihr Handy geklaut wurde und sie unvermittelt und sofort völlig "blank" da standen! Gerade bei der Sparkasse, wo auch alles über zwei Handy-Apps läuft, ist da das Handy weg, kann man sich nicht einmal mehr via Webbrowser einloggen! Aber der Dieb, der das Handy hat kann ab sofort alles (Zugang vorausgesetzt).
Mit freundlichen Grüßen
Thoralf Schilde SEC
*Firetech Consultants GmbH* Hauptstrasse 15 D - 04827 Machern OT Püchau Phone/Fax: +49(0)3425 857600 /www.firetech-online.de/
Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen. Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet. The information contained in this message is confidential or protected by law. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited.
Am 22.02.24 um 19:35 schrieb Florian Snow:
Hallo zusammen,
im Rahmen meiner Arbeit bei der FSFE habe ich mich mit dem Thema Freie Software im Bereich Banken beschäftigt und möchte meine Erfahrungen und Gedanken mit euch teilen. Das Thema ist Teil des größeren Themas der Appifizierung/des Drucks zur Verwendung unfreier Apps für bestimmte Interaktionen.
Mir persönlich fällt in den letzten Jahren auf, dass Banken sehr stark versuchen, ihre unfreien Apps für Bankgeschäfte selbst und auch für die so genannte Zwei-Faktor-Authentifizierung zu erfordern. Tatsächlich blockieren sie oft andere Authentifizierungsmethoden ganz. Das ist natürlich ein Problem für uns, und deshalb habe ich mich mit diesem Thema etwas genauer beschäftigt.
Das niederländische FSFE-Team hat hier einen wunderbaren Anfang gemacht, indem es eine Bank kontaktiert hat, um zu erfahren, warum sie es ihren Kunden erschwert, Freie Software zu benutzen. Meine Aufgabe war es, das Thema allgemeiner anzugehen. Leider war es sehr schwierig, direkt von Banken Antworten zu erhalten. Eine sehr häufige Rückmeldung war, dass es rechtliche Anforderungen gibt, die Dinge so zu tun, wie sie es tun, und dass die IT-Abteilungen vernünftige Entscheidungen getroffen hätten, die nicht zu sehr hinterfragt werden sollten.
Ein Grund, den die Banken manchmal anführten, war PSD2, eine EU-Richtlinie zur Regulierung von Zahlungsdiensten und Zahlungsdienstleistern. So wie ich es nach einigen Hintergrundrecherchen sehe, schreibt PSD2 offenbar keine genauen technischen Maßnahmen vor, auch nicht für den zweiten Faktor. So wie die Banken PSD2 interpretieren, bedeutet dies jedoch, dass sie die Authentifizierngs-Secrets an eine bestimmte Hardware binden müssen. Meiner Meinung nach ist diese Auslegung bereits das erste Problem für Freie Software, denn auch wenn dies keine rechtliche Anforderung ist, schließt es Zwei-Faktor-Lösungen wie TOTP aus, bei denen die Secrets auf mehreren Geräten verwendet oder einfach durch Verwendung einer entsprechenden TOTP-App extrahiert werden können.
Das zweite große Problem ist, wie Banken die Secrets an die Hardware binden: vollständig in Software. Dies macht es erforderlich, dass die Banking-Apps auf gerootete Telefone usw. prüfen, denn wenn ein Telefon gerootet ist, könnte das Secret theoretisch extrahiert werden. Die Root-Checks erfolgen in der Regel durch die Verwendung von Bibliotheken in den Apps, die Sicherheit auch in bösartigen Umgebungen versprechen, z.B. auf einem von Malware befallenen Telefon. Die Banken verlassen sich derzeit mehr auf solche Sicherheitsversprechen als auf tatsächliche Sicherheit, denn echte Sicherheit würde beispielsweise bedeuten, eine richtige Zwei-Faktor-Authentifizierung zu implementieren, statt zwei Apps auf demselben Telefon laufen zu lassen und dies Zwei-Faktor-Authentifizierung zu nennen.
In Kombination sind diese Probleme noch gravierender, da praktisch alle Banken das Verfahren so implementieren und es zu einer Art Best Practice geworden ist. Die Banken befürchten, dass sie bei einer anderen Vorgehensweise im Falle einer angeblich nicht autorisierten Transaktion haftbar gemacht werden könnten. Leider ist es, wie in anderen Bereichen auch, oft einfacher, das zu tun, was alle anderen tun, auch wenn es Schwächen hat, denn dann kann man sein Vorgehen wenigstens damit verteidigen, dass man sich an den "Standard" hält. Und in diesem Fall wird dadurch leider Freie Software eingeschränkt.
Eine Art Ausweg aus dieser Situation ist die Verwendung von Secure Elements in Telefonen. Durch deren Verwendung wären die Secrets tatsächlich an die Hardware gebunden. Das würde bedeuten, dass Freie Software das Secure Element ähnlich wie eine Smartcard nutzen könnte, indem wir es einfach nutzen, um eine Transaktion zu signieren. Dadurch wären Root-Checks und unfreie Apps nicht notwendig. Wie bei einer Smartcard würden jedoch in der Regel immer noch unfreie Schritte stattfinden, nur eben in Hardware. Auch dies wäre also keine perfekte Lösung.
Das größere Problem dabei ist jedoch, dass es keine Standardmethode für die Kommunikation mit Secure Elements gibt, was es für Banken schwierig macht, sie zu verwenden, und es würde erfordern, dass sie eine Liste von Secure Elements führen müssten, so wie eine Liste von CAs. Hinzu kommt, dass die Banken wahrscheinlich nicht auf diese Lösung umsteigen, so lange es keine Zertifizierung dafür gibt; so lange sie eine funktionierende Lösung haben, gibt einfach keinen großen Anreiz für sie, etwas zu ändern.
Eine Sache, die ich sehen konnte, ist, dass Banken oft noch ältere Standards verwenden, die den Zugang mit Freier Software ermöglichen könnten. Einige Apps geben zum Beispiel Fehlermeldungen mit HBCI-Fehlercodes aus. Das hörte sich zunächst vielversprechend an, denn wenn es irgendwo noch ein System gibt, das mit Freier Software kompatibel ist, dann könnten wir vielleicht darauf zugreifen. Leider ist es offenbar jedoch oft so, dass Banken eine weitere Schicht um eine ältere Schnittstelle herum bauen und dann nur noch die neuere Schicht nach außen verfügbar machen. Das mag aus der Sicherheitsgesichtspunkten sogar sinnvoll sein, wenn die Wartung dieser älteren Systeme schwierig ist. Auf diese Weise können Banken intern weiterhin Legacy-Systeme einsetzen, ohne dabei Sicherheitslücken öffentlich angreifbar zu machen, und gleichzeitig haben sie nach außen hin moderne Schnittstellen zur Verfügung. Das bedeutet, dass es leider zu kurz gedacht ist, dass wenn Banken intern HBCI intern nutzen, sie uns einfach weiterhin Zugang dazu geben könnten.
Ein weiterer Lösungsansatz besteht darin, dass Banken verpflichtet sind, Dritten Zugang zu gewähren, um neue Dienste auf Basis bestehender Bankkonten zu ermöglichen. Dies würde es theoretisch erlauben, einen solchen Dienst in Freier Software anzubieten, aber in der Regel ist für die Anmeldung immer noch die sogenannte Zwei-Faktor-App der Bank erforderlich, so dass uns auch das nicht viel hilft.
Irgendwann dachte ich, es gäbe ein Beispiel für eine Bank, die TOTP als zweiten Faktor (und Anmeldung ohne zweiten Faktor) zulässt: Paypal. Aber soweit ich weiß, tritt Paypal hier nicht als Bank, sondern als Zahlungsanbieter auf und nutzt seine Banklizenz für andere Dinge. Das bedeutet, dass Paypal zwar auf den ersten Blick wie ein positives Beispiel in dieser Hinsicht aussieht, es aber doch nicht ist, weil die Anforderungen an Zahlungsdienstleister sehr anders als die für Banken sind.
Ich bin neugierig, was ihr über dieses Thema denkt. Welche Erfahrungen habt ihr mit eurer Bank gemacht? Wie macht ihr euer Banking? Gibt es einen wichtigen Aspekt, den ich übersehen habe? Ich freue mich über jede Rückmeldung.
Happy hacking! Florian
Hi,
T. Schilde - Firetech Consultants, 2024-02-22 21:10 +0100 (UTC+0100):
Für alle drei nutzen wir den gleichen TAN-Generator, bei der GLS mit einer extra Banking-Card. Alle Konten verwalten wir mit der freien Banking-Software Hibiscus, auf welcher auch noch eine Vereinsverwaltung läuft.
Das ist leider eine der wenigen Möglichkeiten und der unfreie Teil läuft da auf der Karte.
Ich finde es auch sehr fragwürdig, dass der Bürger zum einen gezwungenermaßen ein Girokonto braucht - und zum anderen dann durch die Banken in eine technologische Abhängigkeit gebracht wird, aus der sich viele Kunden (mangels Wissen) praktisch nicht mehr befreien können.
Richtig. Während man in manchen Bereichen vielleicht (mit Einschränkungen) diese Abhängigkeit vermeiden kann, indem man die Bereiche nicht nutzt, geht das bei Banken eben nicht, weswegen das ein zentraler Punkt ist, wo wir Freiheit brauchen.
Happy hacking! Florian
Hallo Florian,
Am Thu, Feb 22, 2024 at 07:35:55PM +0100 schrieb Florian Snow:
Hallo zusammen,
im Rahmen meiner Arbeit bei der FSFE habe ich mich mit dem Thema Freie Software im Bereich Banken beschäftigt und möchte meine Erfahrungen und Gedanken mit euch teilen. Das Thema ist Teil des größeren Themas der Appifizierung/des Drucks zur Verwendung unfreier Apps für bestimmte Interaktionen.
Mir persönlich fällt in den letzten Jahren auf, dass Banken sehr stark versuchen, ihre unfreien Apps für Bankgeschäfte selbst und auch für die so genannte Zwei-Faktor-Authentifizierung zu erfordern. Tatsächlich blockieren sie oft andere Authentifizierungsmethoden ganz. Das ist natürlich ein Problem für uns, und deshalb habe ich mich mit diesem Thema etwas genauer beschäftigt.
Das ist nicht nur bei Banken so. Bei Krankenkassen läuft es leider ähnlich. Habe da länger mit denen telefoniert und die gefragt, was Leute ohne Smartphone machen sollen? (Wohlgemerkt nicht ohne Handy, seinerzeit hatte ich noch ein Nokia 8910i.) Die Antwort war sinngemäß, solche Leute gäbe es ja gar nicht mehr. Der Verein Digitalcourage nennt derartiges Geschäftsgebaren ganz treffend "Digitalzwang". Mittlerweile erledige ich meine Angelegenheiten mit denen wieder per Post.
Das niederländische FSFE-Team hat hier einen wunderbaren Anfang gemacht, indem es eine Bank kontaktiert hat, um zu erfahren, warum sie es ihren Kunden erschwert, Freie Software zu benutzen. Meine Aufgabe war es, das Thema allgemeiner anzugehen. Leider war es sehr schwierig, direkt von Banken Antworten zu erhalten. Eine sehr häufige Rückmeldung war, dass es rechtliche Anforderungen gibt, die Dinge so zu tun, wie sie es tun, und dass die IT-Abteilungen vernünftige Entscheidungen getroffen hätten, die nicht zu sehr hinterfragt werden sollten.
Ein Grund, den die Banken manchmal anführten, war PSD2, eine EU-Richtlinie zur Regulierung von Zahlungsdiensten und Zahlungsdienstleistern. So wie ich es nach einigen Hintergrundrecherchen sehe, schreibt PSD2 offenbar keine genauen technischen Maßnahmen vor, auch nicht für den zweiten Faktor. So wie die Banken PSD2 interpretieren, bedeutet dies jedoch, dass sie die Authentifizierngs-Secrets an eine bestimmte Hardware binden müssen. Meiner Meinung nach ist diese Auslegung bereits das erste Problem für Freie Software, denn auch wenn dies keine rechtliche Anforderung ist, schließt es Zwei-Faktor-Lösungen wie TOTP aus, bei denen die Secrets auf mehreren Geräten verwendet oder einfach durch Verwendung einer entsprechenden TOTP-App extrahiert werden können.
Das zweite große Problem ist, wie Banken die Secrets an die Hardware binden: vollständig in Software. Dies macht es erforderlich, dass die Banking-Apps auf gerootete Telefone usw. prüfen, denn wenn ein Telefon gerootet ist, könnte das Secret theoretisch extrahiert werden. Die Root-Checks erfolgen in der Regel durch die Verwendung von Bibliotheken in den Apps, die Sicherheit auch in bösartigen Umgebungen versprechen, z.B. auf einem von Malware befallenen Telefon. Die Banken verlassen sich derzeit mehr auf solche Sicherheitsversprechen als auf tatsächliche Sicherheit, denn echte Sicherheit würde beispielsweise bedeuten, eine richtige Zwei-Faktor-Authentifizierung zu implementieren, statt zwei Apps auf demselben Telefon laufen zu lassen und dies Zwei-Faktor-Authentifizierung zu nennen.
Been there, done that. Ich benutze LineageOS und habe das auf allen Handys in der Familie installiert. Die App der DAK bspw. hat sich strikt geweigert Dinge zu tun, weil sie davon ausging das Gerät sei gerootet. Ähnlich war es zwischendurch mit der Corona-Warn-App. Das wurde später in eine Warnung geändert, die man wegklicken konnte.
Irgendwann dachte ich, es gäbe ein Beispiel für eine Bank, die TOTP als zweiten Faktor (und Anmeldung ohne zweiten Faktor) zulässt: Paypal. Aber soweit ich weiß, tritt Paypal hier nicht als Bank, sondern als Zahlungsanbieter auf und nutzt seine Banklizenz für andere Dinge. Das bedeutet, dass Paypal zwar auf den ersten Blick wie ein positives Beispiel in dieser Hinsicht aussieht, es aber doch nicht ist, weil die Anforderungen an Zahlungsdienstleister sehr anders als die für Banken sind.
Ich bin neugierig, was ihr über dieses Thema denkt. Welche Erfahrungen habt ihr mit eurer Bank gemacht? Wie macht ihr euer Banking? Gibt es einen wichtigen Aspekt, den ich übersehen habe? Ich freue mich über jede Rückmeldung.
Ich mache Banking seit jeher am Laptop oder PC im Webbrowser und überhaupt nicht am Handy. War zuvor bei der Sparkasse und bin zur GLS-Bank gewechselt. So kann ich den alten Sm@rtTAN Generator von Reiner, den ich vor Jahren von der Sparkasse bekommen hatte, jetzt bei der GLS Bank einfach weiter nutzen. Was die Infrastruktur angeht, nutzt die Bank wohl die Technik der Volksbanken, genaueres weiß ich da aber nicht.
Grüße Alex
On Fri, 23 Feb 2024, Alexander Dahl wrote:
Ich mache Banking seit jeher am Laptop oder PC im Webbrowser und überhaupt nicht am Handy. War zuvor bei der Sparkasse und bin zur GLS-Bank gewechselt. So kann ich den alten Sm@rtTAN Generator von Reiner, den ich vor Jahren von der Sparkasse bekommen hatte, jetzt bei der GLS Bank einfach weiter nutzen. Was die Infrastruktur angeht, nutzt die Bank wohl die Technik der Volksbanken, genaueres weiß ich da aber nicht.
GLS-Bank, EthikBank, PSD-Bank, Sparda-Banken, Skat-Bank, Volksbanken, sprich Genossenschaftsbanken nutzen "Agree": https://de.wikipedia.org/wiki/Atruvia#Kernbanksystem_agree21
Hi Alex,
Alexander Dahl, 2024-02-23 08:01 +0100 (UTC+0100):
Das ist nicht nur bei Banken so. Bei Krankenkassen läuft es leider ähnlich.
Das finde ich genauso bedauerlich und es ist Teil eines generellen unguten Trends, den man seit einiger Zeit beobachten kann, nur bei solchen grundlegenden Bereichen, von denen jeder betroffen ist, ist es besonders problematisch.
Ich mache Banking seit jeher am Laptop oder PC im Webbrowser und überhaupt nicht am Handy. War zuvor bei der Sparkasse und bin zur GLS-Bank gewechselt. So kann ich den alten Sm@rtTAN Generator von Reiner, den ich vor Jahren von der Sparkasse bekommen hatte, jetzt bei der GLS Bank einfach weiter nutzen. Was die Infrastruktur angeht, nutzt die Bank wohl die Technik der Volksbanken, genaueres weiß ich da aber nicht.
Das ist leider eine der wenigen Möglichkeiten und das reicht halt nicht. Es ist verständlich, dass Menschen Banking auch unterwegs machen wollen und auch das sollte möglich sein.
Happy hacking! Florian
Hola,
On 22/02/2024 7:35 pm, Florian Snow wrote:
schreibt PSD2 offenbar keine genauen technischen Maßnahmen vor, auch nicht für den zweiten Faktor.
Das ist doch hier im Delegated Act, oder? https://eur-lex.europa.eu/eli/reg_del/2018/389/oj
Liebe Grüße Alex
Hi Alex,
Alexander Sander, 2024-02-27 09:11 +0100 (UTC+0100):
Das ist doch hier im Delegated Act, oder? https://eur-lex.europa.eu/eli/reg_del/2018/389/oj
Genau, nur stehen da nur Anforderungen drin, nicht die konkrete Umsetzung.
Happy hacking! Florian
Hallo,
ich habe irgendwann mal gesehen, dass es von der Varengold Bank (für Privatkunden gibt es nur Tages- und Festgeldkontos) eine TAN App in F-Droid gibt: https://f-droid.org/packages/de.varengold.activeTAN/
Habe selbst keine Erfahrung damit.
Am Donnerstag, 22. Februar 2024, 19:35:55 CET schrieb Florian Snow:
Hallo zusammen,
im Rahmen meiner Arbeit bei der FSFE habe ich mich mit dem Thema Freie Software im Bereich Banken beschäftigt und möchte meine Erfahrungen und Gedanken mit euch teilen. Das Thema ist Teil des größeren Themas der Appifizierung/des Drucks zur Verwendung unfreier Apps für bestimmte Interaktionen.
Mir persönlich fällt in den letzten Jahren auf, dass Banken sehr stark versuchen, ihre unfreien Apps für Bankgeschäfte selbst und auch für die so genannte Zwei-Faktor-Authentifizierung zu erfordern. Tatsächlich blockieren sie oft andere Authentifizierungsmethoden ganz. Das ist natürlich ein Problem für uns, und deshalb habe ich mich mit diesem Thema etwas genauer beschäftigt.
Das niederländische FSFE-Team hat hier einen wunderbaren Anfang gemacht, indem es eine Bank kontaktiert hat, um zu erfahren, warum sie es ihren Kunden erschwert, Freie Software zu benutzen. Meine Aufgabe war es, das Thema allgemeiner anzugehen. Leider war es sehr schwierig, direkt von Banken Antworten zu erhalten. Eine sehr häufige Rückmeldung war, dass es rechtliche Anforderungen gibt, die Dinge so zu tun, wie sie es tun, und dass die IT-Abteilungen vernünftige Entscheidungen getroffen hätten, die nicht zu sehr hinterfragt werden sollten.
Ein Grund, den die Banken manchmal anführten, war PSD2, eine EU-Richtlinie zur Regulierung von Zahlungsdiensten und Zahlungsdienstleistern. So wie ich es nach einigen Hintergrundrecherchen sehe, schreibt PSD2 offenbar keine genauen technischen Maßnahmen vor, auch nicht für den zweiten Faktor. So wie die Banken PSD2 interpretieren, bedeutet dies jedoch, dass sie die Authentifizierngs-Secrets an eine bestimmte Hardware binden müssen. Meiner Meinung nach ist diese Auslegung bereits das erste Problem für Freie Software, denn auch wenn dies keine rechtliche Anforderung ist, schließt es Zwei-Faktor-Lösungen wie TOTP aus, bei denen die Secrets auf mehreren Geräten verwendet oder einfach durch Verwendung einer entsprechenden TOTP-App extrahiert werden können.
Das zweite große Problem ist, wie Banken die Secrets an die Hardware binden: vollständig in Software. Dies macht es erforderlich, dass die Banking-Apps auf gerootete Telefone usw. prüfen, denn wenn ein Telefon gerootet ist, könnte das Secret theoretisch extrahiert werden. Die Root-Checks erfolgen in der Regel durch die Verwendung von Bibliotheken in den Apps, die Sicherheit auch in bösartigen Umgebungen versprechen, z.B. auf einem von Malware befallenen Telefon. Die Banken verlassen sich derzeit mehr auf solche Sicherheitsversprechen als auf tatsächliche Sicherheit, denn echte Sicherheit würde beispielsweise bedeuten, eine richtige Zwei-Faktor-Authentifizierung zu implementieren, statt zwei Apps auf demselben Telefon laufen zu lassen und dies Zwei-Faktor-Authentifizierung zu nennen.
In Kombination sind diese Probleme noch gravierender, da praktisch alle Banken das Verfahren so implementieren und es zu einer Art Best Practice geworden ist. Die Banken befürchten, dass sie bei einer anderen Vorgehensweise im Falle einer angeblich nicht autorisierten Transaktion haftbar gemacht werden könnten. Leider ist es, wie in anderen Bereichen auch, oft einfacher, das zu tun, was alle anderen tun, auch wenn es Schwächen hat, denn dann kann man sein Vorgehen wenigstens damit verteidigen, dass man sich an den "Standard" hält. Und in diesem Fall wird dadurch leider Freie Software eingeschränkt.
Eine Art Ausweg aus dieser Situation ist die Verwendung von Secure Elements in Telefonen. Durch deren Verwendung wären die Secrets tatsächlich an die Hardware gebunden. Das würde bedeuten, dass Freie Software das Secure Element ähnlich wie eine Smartcard nutzen könnte, indem wir es einfach nutzen, um eine Transaktion zu signieren. Dadurch wären Root-Checks und unfreie Apps nicht notwendig. Wie bei einer Smartcard würden jedoch in der Regel immer noch unfreie Schritte stattfinden, nur eben in Hardware. Auch dies wäre also keine perfekte Lösung.
Das größere Problem dabei ist jedoch, dass es keine Standardmethode für die Kommunikation mit Secure Elements gibt, was es für Banken schwierig macht, sie zu verwenden, und es würde erfordern, dass sie eine Liste von Secure Elements führen müssten, so wie eine Liste von CAs. Hinzu kommt, dass die Banken wahrscheinlich nicht auf diese Lösung umsteigen, so lange es keine Zertifizierung dafür gibt; so lange sie eine funktionierende Lösung haben, gibt einfach keinen großen Anreiz für sie, etwas zu ändern.
Eine Sache, die ich sehen konnte, ist, dass Banken oft noch ältere Standards verwenden, die den Zugang mit Freier Software ermöglichen könnten. Einige Apps geben zum Beispiel Fehlermeldungen mit HBCI-Fehlercodes aus. Das hörte sich zunächst vielversprechend an, denn wenn es irgendwo noch ein System gibt, das mit Freier Software kompatibel ist, dann könnten wir vielleicht darauf zugreifen. Leider ist es offenbar jedoch oft so, dass Banken eine weitere Schicht um eine ältere Schnittstelle herum bauen und dann nur noch die neuere Schicht nach außen verfügbar machen. Das mag aus der Sicherheitsgesichtspunkten sogar sinnvoll sein, wenn die Wartung dieser älteren Systeme schwierig ist. Auf diese Weise können Banken intern weiterhin Legacy-Systeme einsetzen, ohne dabei Sicherheitslücken öffentlich angreifbar zu machen, und gleichzeitig haben sie nach außen hin moderne Schnittstellen zur Verfügung. Das bedeutet, dass es leider zu kurz gedacht ist, dass wenn Banken intern HBCI intern nutzen, sie uns einfach weiterhin Zugang dazu geben könnten.
Ein weiterer Lösungsansatz besteht darin, dass Banken verpflichtet sind, Dritten Zugang zu gewähren, um neue Dienste auf Basis bestehender Bankkonten zu ermöglichen. Dies würde es theoretisch erlauben, einen solchen Dienst in Freier Software anzubieten, aber in der Regel ist für die Anmeldung immer noch die sogenannte Zwei-Faktor-App der Bank erforderlich, so dass uns auch das nicht viel hilft.
Irgendwann dachte ich, es gäbe ein Beispiel für eine Bank, die TOTP als zweiten Faktor (und Anmeldung ohne zweiten Faktor) zulässt: Paypal. Aber soweit ich weiß, tritt Paypal hier nicht als Bank, sondern als Zahlungsanbieter auf und nutzt seine Banklizenz für andere Dinge. Das bedeutet, dass Paypal zwar auf den ersten Blick wie ein positives Beispiel in dieser Hinsicht aussieht, es aber doch nicht ist, weil die Anforderungen an Zahlungsdienstleister sehr anders als die für Banken sind.
Ich bin neugierig, was ihr über dieses Thema denkt. Welche Erfahrungen habt ihr mit eurer Bank gemacht? Wie macht ihr euer Banking? Gibt es einen wichtigen Aspekt, den ich übersehen habe? Ich freue mich über jede Rückmeldung.
Happy hacking! Florian
Hi,
das ist auf jeden Fall ein sehr guter Hinweis! Danke dafür!
Happy hacking! Florian
Hi,
das ist auf jeden Fall ein sehr guter Hinweis! Danke dafür!
Happy hacking! Florian
Moin,
Am Donnerstag 22 Februar 2024 19:35:55 schrieb Florian Snow:
Das zweite große Problem ist, wie Banken die Secrets an die Hardware binden: vollständig in Software. Dies macht es erforderlich, dass die Banking-Apps auf gerootete Telefone usw. prüfen, denn wenn ein Telefon gerootet ist, könnte das Secret theoretisch extrahiert werden.
wie in weiteren Situation auch. Ein Defekt einer hoch priveligierten Komponente zum Beispiel oder falsch vergebene Rechte könnten ebenfalls Schadsoftware erlauben.
In den Abschnitten 2.1 Root ein generelles Sicherheitsrisiko? 2.2 Banking-Apps und Co.: Root-Erkennung erklärt Mike Kuketz warum ein gerootetes Android besser ist und die Banken - seiner Ansicht nach - das Kind mit dem Bade ausschütten. https://www.kuketz-blog.de/magisk-bei-der-macht-von-root-take-back-control-t...
Die Root-Checks erfolgen in der Regel durch die Verwendung von Bibliotheken in den Apps, die Sicherheit auch in bösartigen Umgebungen versprechen, z.B. auf einem von Malware befallenen Telefon.
Apps sind Software. Und Software kann sich nie ganz sicher sein, wirklich auf Hardware zu laufen. Auch Hardware-Krypto-Module können simuliert werden.
Ein zugeschraubtes Betriebssystem auf einem Mobiltelefon ist grundsätzlich gut für die Sicherheit, weil es Prüfungen erlaubt, ob wirklich nur die Software läuft, welche ich laufen lassen möchte. Allerdings sollten es die Nutzenden (und manchmal die Eigentümer:innen) der Geräte sein, welche das bestimmen. Dazu müssten sie in der Lage sein das Telefon auf- und zuzuschrauben. Bei Sony und Google Pixel Geräten kann z.B. von Usern der Bootloader aufgesperrt und dann wieder zugesperrt werden.
Selber aufsperren ("rooten") ist also gut, wenn jemand damit verantwortwortungsvoll umgeht, erhält er sogar ein sichereres Mobiltelefon. Banken sollten die Nutzung für Ihre (in der Regel proprietären) Apps erlauben.
Noch besser wäre eine Freie Software Standard App, mit der allgemeine Dinge, die viele Leute brauchen gehen.
Gruß Bernhard