Banken und Freie Software

T. Schilde - Firetech Consultants t.schilde at firetech-online.de
Do Feb 22 20:10:52 UTC 2024


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
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20240222/6b256941/attachment-0001.htm>


Mehr Informationen über die Mailingliste FSFE-de