Probleme bei BitCoin – gesellschaftstheoretisch und technisch

Das komplett dezentrale auf kryptographie basierende Zahlungssystem BitCoin hat es in letzter Zeit zu einiger Berühmtheit gebracht. Das Konzept werde ich hier nicht nochmal erklären, das ist z. B. in der Wikipedia nachzulesen.

Die für diese Betrachtung relevanten Haupteigenschaften von Bitcoin sind:

• Das System ist dezentral und völlig unkontrollierbar
• Zahlungen sind nicht umkehrbar
• Neues Geld wird (beschränkt) ständig erstellt und anteilig nach beteiligter Rechenleistung an die aktiven Teilnehmer verteilt

Die Unkontrollierbarkeit wird als Vorteil gesehen – kein Staat kann willkürlich Konten oder Guthaben einfrieren, auch kann kein Staat einfach so Geld drucken. Bitcoins verhalten sich in einigen Aspekten wie Bargeld – insbesondere sind sie weg, wenn sie mal gestohlen werden.

Gesellschaftstheoretisch

Die Unkontrollierbarkeit kann gesellschaftstheoretisch aber auch als Problem gesehen werden: Anonymität und Unkontrollierbarkeit für Kommunikation und Meinungsäußerung finde ich generell gut, auch wenn sie missbraucht werden kann, einfach weil der Nutzen überwiegt und die Gefahren nicht soo groß sind. Bei der Aufklärung von Straftaten sehe ich „follow the money“ statt Kommunikationsüberwachung als guten Ansatz an. Man kann sich natürlich auf den Standpunkt stellen, dass der Staat möglichst wenig Macht haben soll, und es daher gut ist, wenn seine Macht beschränkt wird. Hier wird aber eine sehr wichtige Aufgabe des Staates übersehen: Er soll eine demokratische Kontrolle von Macht sicherstellen und wo nötig „schwache“ vor „starken“ schützen. Verurteilt ein Gericht jemanden, einem anderen z. B. eine Entschädigung für etwas zu zahlen, kann dieser es entweder tun, oder der Gerichtsvollzieher kommt und pfändet. Das – und damit die Durchsetzung des Rechts! – würde deutlich schwieriger, wenn Geld nicht mehr auf Bankkonten sondern auf verschlüsselten und redundanten USB-Sticks liegen würde.

Nimmt man dem Staat jede Macht, hat man zunächst eine Anarchie, letztlich herrschen diejenigen, die Ressourcen kontrollieren oder die Macht haben, andere Menschen unter Druck zu setzen. Mit anderen Worten: Warlords, die in der Lage sind, sich genug Söldner zu mieten und/oder genug Waffen haben. Irgendwo habe ich ein „interessantes“ Szenario gelesen – was, wenn jemand eine Plattform anbietet, wo man per Bitcoin Kopfgelder auf Personen ausschreiben kann? Oder Belohnungen für terroristische Anschläge? Das geht mit „normalem“ Geld nur sehr eingeschränkt, wäre mit Bitcoin aber anonym umsetzbar. Auch wenn reiche Menschen auch in westlichen Demokratien deutlich mehr Macht haben, bietet ein demokratischer Staat eine gewisse Kontrolle. Gibt man diese auf, hat man eine reine Plutokratie – das will man eigentlich nicht.

Die Einführung von Bitcoin als Zahlungsmittel würde den Staat nicht abschaffen, aber seine Position schwächen. Das hat auch Vorteile, man kann es befürworten, und eine abschließende Meinung dazu habe ich nicht – aber es hat eben auch Nachteile, die oft vergessen werden, und die ich daher hier nennen wollte.

Technisch

Die weiteren Probleme sind technischer Art. Das Gesamtkonzept sieht solide aus und da bisher noch keiner einen Fehler darin gefunden hat, dürfte es auch relativ solide sein. Das Geld, was einem gehört, ist über private Schlüssel gesichert – wer diese Schlüssel hat, kann es ausgeben. IT-Kriminalität wird dadurch ein ganz neues Tor geöffnet: Bisher mussten Kriminelle eine Online-Überweisung manipulieren, um ein Bankkonto leerzuräumen. Bei Bitcoin reicht ein simpler Trojaner auf dem Rechner des Opfers. Experten haben gewisse Chancen, ihre Maschinen sicher zu halten – 95% der Computernutzer dürften aber mit IT-Sicherheit hoffnungslos überfordert sein und viele handeln sich regelmäßig Schadsoftware ein. Ergänzung: Dieser Fall, wo genau das mit Bitcoins im Wert von 500.000 USD passiert sein soll, war Anlass für diesen Artikel. Ich gehe davon aus, dass der (Ex-)Besitzer in Sachen Computersicherheit noch auf jeden Fall zu den Top 10% zählt, auch wenn er sehr sehr viel falsch gemacht hat. Update: Heise über Bitcoin-Trojaner.

BitCoin basiert auf einem P2P-Netzwerk. Sollte es jemand schaffen, eine Sicherheitslücke, welche Code Execution (d.h. das Einschleusen von Malware) erlaubt, im Bitcoin-Client zu finden, kann er einen Wurm schreiben, der sich über das Bitcoin-Netz selbst verbreitet und so innerhalb kürzester Zeit alle zu dem Zeitpunkt aktiven Bitcoin-Teilnehmer gleichzeitig hacken und ihre Konten leerräumen. Aber auch wenn die Software selbst sicher sein sollte, kann ein Angreifer über das P2P-Netz herausfinden, wer alles an Bitcoin teilnimmt, inklusive deren IP-Adressen. Sollten die Systeme andere, von außen erreichbare Schwachstellen haben, kann er diese nutzen, um in die Systeme einzubrechen und die privaten Schlüssel zu stehlen – mit denen er dann die Bitcoins an sich überweisen kann.

Ein weiteres Problem ist, dass der Besitz von Bitcoins durch den (alleinigen) Besitz des privaten Schlüssels gekennzeichnet ist. Das Verfahren gilt als sicher, d.h. es ist nicht möglich diese Schlüssel zu knacken – noch. Was aber, wenn in 20 Jahren Quantencomputer existieren oder das Verfahren auf andere Art und Weise geknackt wird? Man kann Bitcoin mit ein paar Schwierigkeiten auf ein neues Verfahren migrieren, aber das muss passieren bevor das alte Verfahren angegriffen wird. Wird das Verschlüsselungsverfahren was in Bitcoin eingesetzt wird geknackt, hat der Angreifer, dem das gelungen ist, die Möglichkeit, Geld aus beliebigen Bitcoin-Konten zu überweisen, und es gibt keine Möglichkeit, Angreifer und legitimen Besitzer mehr zu unterscheiden (wie auch in anderen Fällen, wo der Angreifer den private key gestohlen hat).

Durch das Investieren von Rechenzeit („Mining“) kann man Bitcoins generieren, allerdings ist das ein Zufallsprozess – ein normaler Mensch mit einer einzelnen normalen Grafikkarte (Grafikprozessoren können die nötigen Operationen schneller ausführen als CPUs, mit CPUs rechnen ist nahezu sinnlos) dürfte sehr lange rechnen, bis er Bitcoins sieht. Daher gibt es sogenannte Mining-Pools, bei denen mehrere Menschen zugleich minen und im Erfolgsfall der Gewinn dann auf die Beteiligten aufgeteilt wird. Diese Mining-Pools konzentrieren große Mengen an Rechenleistung. Das ist insofern ein Problem, als dass die Sicherheit des Netzes darauf basiert, dass die Mehrheit der beteiligten Rechenleistung von ehrlichen Teilnehmern kontrolliert wird. Die Pools kontrollieren jeweils über ihre Teilnehmer sehr viel Rechenleistung, und die einzelnen Teilnehmer können nicht (direkt) prüfen, ob der Pool „ehrlich“ arbeitet. Falls einer der großen Pools die Mehrheit der Rechenleistung kontrolliert, könnte er diese missbrauchen. Soweit ich sehe ermöglicht das jedoch „nur“ das doppelte ausgeben von Bitcoins, und es dürfte laut dem Konzept von Bitcoin lohnenswerter sein, die Leistung wie vorgesehen für die Unterstützung des Netzes zu nutzen statt sie zu missbrauchen. Dieses Problem dürfte also nicht allzu groß sein. Sollte allerdings eine Lücke in den Mining-Clients gefunden werden, könnte einer der Pool-Betreiber (oder jemand, der ihn hackt!) die Kontrolle über zahlreiche beteiligte Rechner übernehmen und deren Bitcoin-Börsen plündern.

Da es Geld für Rechenleistung gibt, wird es sicherlich früher oder später Schadsoftware geben, die fremde (übernommene) Rechner benutzt, um Bitcoins zu erzeugen (falls es das nicht schon längst gibt). Wenn Firmen mit großen Rechenzentren wie Amazon, Google oder Facebook sich entscheiden würden, bei Bitcoin einzusteigen, könnten sie wohl allein mit unbenutzten Servern in kürzester Zeit (bevor der Algorithmus die Erzeugung bremst) riesige Mengen an Bitcoins erzeugen (oder das Netzwerk zerstören, wovon sie aber nichts hätten). Diese Möglichkeit könnte gerade in einem Krisenfall die Stabilität der Währung massiv gefährden.

In den Zeiten, wo das Bitcoin-Netz noch klein war, konnten einzelne Personen große Mengen an Bitcoins erzeugen – dadurch haben einige „early adopter“ unglaublich große Geldmengen, und könnten dadurch vermutlich den Kurs massiv beeinflussen. Außerdem ist Bitcoin Ziel von zahlreichen Spekulanten. Der aktuelle Wert der Bitcoins, meist definiert über den Umtauschkurs in USD bei MtGox, kann sich also sehr schnell ändern und ist soweit ich weiß vor einiger Zeit innerhalb eines Tages von 30 USD auf 15 USD gefallen.

Auch die vielgerühmte Anonymität bei Bitcoin ist keineswegs so toll, wie viele glauben – im Gegenteil: Bedingt durch die Dezentralität des Netzes sind alle Transaktionen komplett öffentlich, mit Sender, Betrag und Empfänger. Sender und Empfänger sind jedoch keine Personen, sondern Bitcoin-Konten, und es wird empfohlen, für jede Transaktion ein neues Konto anzulegen. Selbst wenn jemand dieser Empfehlung folgt – wenn ich jemandem Geld schicke, sehe ich, was er damit weiter macht und kann der Spur weiter folgen. Er kann das Geld natürlich an ein weiteres Konto überweisen, und ich weiß nicht, ob es noch ihm oder jemandem anderen gehört. Aber angenommen ich führe meine Überweisung an einen mir bekannten Empfänger X auf Konto 1 durch, und sehe, dass innerhalb von Minuten mein ganzes überwiesenes Geld auf Konto 2 geht, dort drei Tage liegen bleibt, dann ein bestimmter Betrag auf Konto 3 geht und von dort auf ein Sammelkonto 4, was wie bekannt ist einem Pornohändler gehört: Dann kann ich davon ausgehen, dass in einem Versuch, das Geld zu anonymisieren, der Empfänger X sein Geld auf ein zweites Konto (Konto 2) von sich verschoben hat, und sich später davon bei besagtem Pornohändler Pornos zu kaufen, indem er das Geld an die für ihn erstellte Bezahladresse des Händlers (Konto 3) überweist – bevor der Händler es auf sein bekanntes Hauptkonto (Konto 4) zieht. Anhand des Betrages und der Preisliste des Händlers kann ich vielleicht ja sogar sehen, was genau der Kunde gekauft hat. Anonymisierungsdienste (bzw. Geldwäschedienste) sind möglich und existieren, man kann also mit etwas Aufwand Bitcoin anonym nutzen. Bitcoin als „anonym“ zu bezeichnen ist jedoch schlicht falsch. Um die Anonymität muss man sich selbst kümmern, und dafür dürften 95% der Nutzer zu unerfahren sein, viele wissen nicht einmal, dass es eigentlich nötig ist, geschweige denn, wie es geht.

Zusammenfassung

Bitcoin ist also sowohl extrem anfällig für IT-Kriminalität und kann vor allem schlagartig zusammenbrechen, plötzlicher und heftiger als die „schlechten, instabilen, altmodischen“ Währungen und Geldsysteme. Die Halbwertszeit dürfte sogar darunter liegen. Als Zahlungssystem könnte Bitcoin, sobald sich der Wert etwas stabilisiert hat, sogar taugen, als alternatives Weltwährungssystem eher nicht. Bei einem Zusammenbruch westlicher Währungen könnte es natürlich sein, dass Menschen anfangen, es als Ersatz zu nutzen, weil man außer Naturalien nichts anderes hat (und darauf dürften auch einige der Bitcoin-Spekulanten spekulieren). Eine langfristige Lösung ist das aber nicht.

An dieser Stelle möchte ich anmerken, dass ich Bitcoin unter theoretischen Gesichtspunkten extrem gut finde: Technisch ist es eine bemerkenswerte Leistung – in einem dezentralen Netzwerk ohne zentrale vertrauenswürdige Stelle ein System mit solchen Sicherheitseigenschaften und darauf basierend ein Zahlungssystem aufzubauen, was das doppelte Ausgeben von Geld verhindert, kontrollierte Inflation beinhaltet, einen gewissen Grad an Anonymität bietet und zumindest vom Konzept her sicher ist, ist schlicht und einfach eine reife Leistung. Das Konzept ist solide und hat sogar praktische Anwendungen. Nur der darin gesetzte Hype ist übertrieben und man sollte sich davor hüten, die Probleme auszublenden und ein solches System als die ultimative Lösung für die Geldsystemproblematik anzusehen.

Einschätzung des SCHUFA-Hacks

Wie Gulli berichtet und die Piratenpartei kommentiert hat, wurde die SCHUFA gehackt (in den Kommentaren bei Gulli gibts/gab es Details). Zunächst betraf das „nur“ den Webserver. Die Lücke bestand laut Beschreibung im Gulli-Forum darin, dass das Skript, was Dateien wie Formulare zum Download ausgeliefert hat, den Download beliebiger Dateien von der Platte des Servers erlaubte. Da die eigentliche SCHUFA-Datenbank natürlich hoffentlich nicht auf diesem Webserver liegen dürfte, ist in der Theorie erstmal keine unmittelbare Gefahr gegeben, weil man über die Lücke ja „nur“ Dateien auf diesem Server herunterladen kann. Diese Position vertritt natürlich auch die SCHUFA, ein Datenleck zuzugeben wäre für ihr Geschäft nicht gerade förderlich.

Der Angreifer konnte also mehr oder weniger beliebige Dateien vom Server herunterladen. So ein Fehler in einer Webanwendung ist ein ziemlicher Anfängerfehler, der auf so einem kritischen Server eigentlich nicht passieren darf. (Das sieht der Experte der Tagesschau übrigens genauso.) Wie schon bei der kaputten SSL-Implementierung bei der AusweisApp sieht man, dass die Annahme „so doof können die nicht sein“ keine Garantie dafür ist, dass in einer kritischen Anwendung solche dummen Fehler wirklich nicht vorhanden sind. Dass es dem kaputten Skript wohl auch möglich war, auf Dateien außerhalb des eigentlichen Websiteverzeichnisses zuzugreifen, deutet außerdem darauf hin, dass mit der Rechte- und Benutzerkontenverwaltung auf dem Server auch eher „locker“ (lies: schlampig und ohne wirklich auf Sicherheit Wert zu legen) umgegangen wurde. Daran, dass für die Schufa Datenschutz und Datensicherheit „seit jeher eine hohe Priorität“ hätten, lässt es genauso zweifeln wie am Sicherheitszustand des restlichen Netzes bei der SCHUFA.

Das wird in dem Moment wichtig, wenn man sich klar macht, auf was für Daten mit der Lücke Zugriff möglich war: Der Server muss irgendwie auf die SCHUFA-Datenbank im Hintergrund zugreifen können. Natürlich wäre es möglich, dass hier irgendein ausgeklügeltes Verfahren genutzt wird, bei dem der Zugriff erst freigegeben wird, wenn der sichere Server am anderen Ende das Login des Kunden geprüft hat. Angesichts der oben genannten Punkte halte ich es jedoch für sehr unwahrscheinlich. Am Wahrscheinlichsten ist es, dass irgendwo auf dem gehackten Webserver die Zugangsdaten für die Datenbank im Klartext herumlagen und darüber die Datenbank ausgelesen werden kann. Ein Angreifer konnte diese Zugangsdaten höchstwahrscheinlich mit vertretbarem Aufwand (configdatei finden) bekommen.

Wenn die Schufa schlau genug war, den Datenbankserver hinter eine Firewall zu stellen (so blöd, es nicht zu tun, kann man eigentlich nicht sein, aber siehe oben), bringen diese Zugangsdaten dem Angreifer aber zunächst nichts, weil er sich zu dem Server gar nicht verbinden kann – das ist dann aber die letzte verbleibende Hürde. Gelingt es ihm, z. B. über vom Webserver geklaute Passwörter in den Webserver einzudringen, oder in einen beliebigen anderen Rechner im Netz der SCHUFA, der auch Zugriff auf den Datenbankserver hat (das könnte eingeschränkt sein – könnte…), kann er sich an der Datenbank bedienen. Vielleicht stehen da „nur“ die Daten der Leute an, die meineschufa.de nutzen, es ist aber mindestens genauso wahrscheinlich, dass der Angreifer sich dann beliebige SCHUFA-Datensätze anschauen und herunterladen kann. Solche Angriffe auf weniger gesicherte „unwichtige“ Rechner, um sie als Brücke ins Netz zu benutzen, sind üblich und bei vielen Angriffen wie z. B. dem auf Google beobachtet worden. Über weitere Angriffe mit dieser Lücke als Einstiegspunkt dürfte also vieles möglich sein.

Selbst wenn mehr Schutzmaßnahmen getroffen würden – wenn es einem Angreifer gelingen würde, den offensichtlich mies gesicherten Webserver komplett zu übernehmen, könnte er zumindest die darüber laufenden Daten abfangen, also die Daten derjenigen, die meineschufa.de nutzen, während der Angreifer Zugriff hat. Die Lücke wurde zwar als „Local file inclusion“ bezeichnet, da die Dateien aber scheinbar so wie sie auf der Platte lagen ausgeliefert wurden und PHP-Skripte nicht geparst wurden, würde ich eher von „Local file disclosure“ sprechen. Das ist insofern etwas weniger gefährlich, als über diese Lücke vermutlich wenigstens „nur“ Daten ausgelesen, aber keine Programme auf den Server geschleust werden können. Andere Lücken, die das (und damit die Übernahme des Servers) erlauben, könnten jedoch durchaus existieren.

Meiner Meinung nach kann man die Situation also folgendermaßen zusammenfassen:

• Der Server wurde gehackt, das hat die SCHUFA bestätigt
• Die Sicherheit lässt sehr zu wünschen übrig
• Die SCHUFA-Daten konnten vermutlich nicht direkt ausgelesen werden, aber
• ich halte es für wahrscheinlich, dass ein Angreifer mit etwas Mühe gute Chancen gehabt hat, auch an die SCHUFA-Daten selbst zu kommen.

Jetzt stellt sich natürlich die Frage: Was nun? Zunächst muss natürlich die Lücke selbst geschlossen werden. Indem die SCHUFA das kaputte Download-Skript gelöscht hat, ist diese Gefahr vorerst gebannt. Dann müssen auch alle potentiell betroffenen Zugangsdaten für die Datenbank und sonstige Server geändert werden – denn sonst könne ein Angreifer die vor kurzem gestohlenen Daten in ein paar Wochen, nachdem die eigentliche Lücke schon geschlossen ist, nutzen, um die Datenbank auszulesen. Hier müssen wir hoffen, dass die SCHUFA sich nicht die Mühe spart und darauf verzichtet, „weil man ja von außen eh nicht an die Datenbank drankommt“. Schließlich – und das ist der schwierigste Teil – muss anhand von Logs geprüft werden, ob die Lücke bereits missbraucht wurde, und wenn z. B. Zugangsdaten gestohlen wurden, ob diese missbraucht wurden. Ich bezweifle, dass es ausreichend weit zurückreichende Logs geben wird, um das für die Zeit seit Bestehen der Lücke ausschließen zu können. Somit dürfte nicht eindeutig zu klären sein, ob Daten geklaut wurden oder nicht. Ganz abgesehen davon muss die SCHUFA natürlich massiv an der Sicherheit ihrer Server arbeiten.

Eines muss man der SCHUFA (bisher) jedoch zugute halten: Sie hat soweit ich weiß nicht versucht oder gedroht, dem ehrlichen Hacker, der die Lücke gemeldet hat, irgendeine Form von Ärger zu machen. Das ist eigentlich eine Selbstverständlichkeit und liegt im Interesse der betroffenen Firma – ehrliche Hacker, die Lücken melden, helfen die Sicherheit zu verbessern. Würde eine Firma einen solchen Hacker bedrohen, werden andere dadurch a) wütend b) angesport weitere Lücken zu finden vor allem c) auf gefundene Lücken nicht hinweisen, sondern sie veröffentlichen oder nutzen um Schaden anzurichten – und das ganze natürlich so, dass sie nicht zurückverfolgt werden können. Leider kommen solche Drohungen immer noch viel zu oft vor.

Der Vorfall zeigt auch einige interessante Probleme auf:

Sicherheit kann nicht nachgerüstet werden. Die Sicherheit muss bereits bei der Entwicklung von Software bedacht werden – nachträgliche Tests und Überprüfungen sind sinnvoll, können das aber nicht ersetzen. Irgendwas wird immer übersehen. Hier haben die Entwickler offenbar nicht ausreichend über Sicherheit nachgedacht, als sie das Downloadsystem entwickelt haben. Das ist gerade in einem solchen sicherheitskritischen Bereich eigentlich völlig inakzeptabel.

Datenschutz lohnt sich nicht. Es gibt keine empfindlichen Strafen, wenn jemand Daten nicht ausreichend schützt. Natürlich ist es nicht gut für den Ruf und fürs Geschäft, wenn solche Lecks passieren, aber das scheint als Motivation nicht auszureichen. Würden für Datenlecks Strafen von ein paar Euro pro Datensatz drohen, wäre gerade bei große Datenbanken die Absicherung plötzlich finanziell sehr attraktiv.

In kritischen Bereichen wird massiv geschlampt. Selbst bei so kritischen Servern wie in diesem Fall bei der SCHUFA wird an der Sicherheit gespart und es werden grobe Fehler gemacht. Wie viele andere wichtige Systeme genauso schlecht gesichert sind? Hier sei exemplarisch nur auf SCADA verwiesen, die Industriesteueranlagen, die von der Chemiefabrik bis zum Atomkraftwerk alles Mögliche kontrollieren und meist auf völlig veralteter Software laufen, mit kaum vorhandenen Sicherheitsmaßnahmen (siehe Vortrag auf einem CCC-Kongress).

Wie Sofortüberweisung.de funktioniert

Scheinbar wissen viele nicht, wie der Dienst „Sofortüberweisung.de“ funktioniert – denn ich glaube kaum, dass so viele ihn sonst nutzen würden. Der Dienst verspricht, wie der Name schon sagt, sofortige Überweisungen, was beim Online-Shopping dem Händler die (vermeintliche – siehe unten) Garantie gibt, dass die Ware direkt bezahlt ist, und dem Kunden so unter Umständen zu einer kürzeren Lieferzeit verhilft. Im Gegensatz zum Lastschriftverfahren ist eine Überweisung auch nicht (zumindest nicht so leicht und nur innerhalb kurzer Zeit) zurückrufbar.

Wie aber schafft es der Dienst, Überweisungen durchzuführen? Ganz einfach – man gibt ihm seine Onlinebanking-Zugangsdaten. Nein, man loggt sich nicht bei seiner eigenen Bank ein und überweist, man gibt diesem Dienst seine Zugangsdaten für den Onlinebankingzugang. Damit loggt er sich dann bei der Bank ein und führt die Transaktionen durch. Mit Benutzername/Kontonummer und PIN hat der Dienst schonmal weitreichenden Lesezugriff aufs Konto – und wurde vor kurzem dabei erwischt, wie er diesen missbraucht, um die Umsätze der letzten 30 Tage, den Dispokredit, Vorhandensein und Kontostände anderer Konten bei der gleichen Bank und/oder vorgemerkte und ausgeführte Auslandsüberweisungen abzufragen. Das soll nur der Absicherung der Überweisung dienen, was aber nichts daran ändert, dass Sofortüberweisung.de die entsprechenden Informationen abfragt. Mit der eingegebenen TAN wird dann die Überweisung durchgeführt. Technisch läuft die Kommunikation mit der Bank über das HBCI-Protokoll, worüber auch Onlinebanking-Software wie Hibiscus, WISO etc. mit der Bank kommuniziert.

Rein technisch gesehen ist das ganze Verfahren exakt das gleiche, was die ganzen Phishingseiten machen – es werden Zugangsdaten des Nutzers abgefragt und dann verwendet, um eine Transaktion durchzuführen. Bei iTAN wird die Transaktion eben der Bank gegenüber eingeleitet, die Bank sagt, welche iTAN sie möchte, und dann wird diese iTAN abgefragt. Der Nutzer muss darauf vertrauen, dass Sofortüberweisung.de mit der TAN keinen Missbrauch anstellt. Das soll durch ein TÜV-Zertifikat bestätigt werden – es gab allerdings schon zahlreiche Fälle (hier ein anderer TÜV-Verein), wo TÜV-geprüfte Webseiten völliger Murks waren. Diese Zertifikate sind also meiner Meinung nach nicht die Bytes wert, die die PDF-Dateien belegen.

Wenn ein Händler also nur eine Zahlung über Sofortüberweisung anbietet, oder bei anderen Zahlungsmethoden miese Konditionen bietet, kaufe ich eben woanders. Sofortüberweisung ist genauso (un)sicher wie Vorkasse per Überweisung, bietet aus Kundensicht in dem Punkt also keinen Vorteil. Wenn ein Händler Lastschrift anbietet, bevorzuge ich das – kaum Arbeit, sollte es große Probleme mit dem Händler geben (was mir bisher nie passiert ist) kann die Lastschrift zurückgebucht werden und die Missbrauchsgefahr ist nahe Null. Klar kann unberechtigt abgebucht werden, dann wird es eben zurückgebucht – dazu ist die eigene Bank grundsätzlich verpflichtet, egal ob sie sich das Geld vom Händler zurückholen kann oder nicht!

Bei mTAN und chipTAN dürfte das Verfahren ähnlich laufen – die Überweisung wird eingeleitet, bei der chipTAN leitet Sofortüberweisung.de die Challenge weiter, der Nutzer gibt die TAN vom Handy/Generator an Sofortüberweisung. Hier ist wenigstens sichergestellt, dass keine falsche Überweisung aufgegeben werden kann – die PIN kann allerdings immer noch benutzt werden, um – wie im oben genannten Fall geschehen – das Konto auszuspähen!

Diese Funktionsweise hängt Sofortüberweisung natürlich nicht an die große Glocke (natürlich steht das alles irgendwo – aber irgendwo wo es keiner liest), und setzt darauf, dass Nutzer sich schon nicht so recht informieren oder es ihnen egal ist. Die Weitergabe von Logindaten an fremde Webseiten verstößt in der Regel gegen Banken-AGB. Diesen Punkt hat das Kartellamt übrigens in einer grandiosen Fehlentscheidung bemängelt, denn viele Banken bieten einen ähnlichen Dienst selbst unter dem Namen GiroPay an. Dieser hat höhere Transaktionsgebühren, wird jedoch von den Banken selbst betrieben und unterscheidet sich in einem „klitzekleinen“ Detail: Der Kunde loggt sich bei seiner eigenen Bank in sein Onlinebanking ein, und die Bank bestätigt dann die Überweisung. Die Logindaten gehen also nicht an eine dritte Partei, in deren Hände sie nicht gehören.

Die Banken hätten also einerseits ein wirtschaftliches Interesse, Sofortüberweisung zu behindern, riskieren dabei allerdings juristische Probleme – weswegen z. B. die Postbank den Laden auch nicht technisch aussperrt. Wäre ich zuständiger für die Online-Sicherheit einer Bank und hätte das unabhängig von den wirtschaftlichen/rechtlichen Sachen zu entscheiden, würde ich die IPs von Sofortüberweisung regelmäßig in die Firewalls stopfen, und die bis zur Erkennung als IP von Sofortüberweisung eingereichten, aber noch nicht durchgeführten Überweisungsaufträge stornieren (mit Benachrichtigung des Kunden, aber ohne Benachrichtigung von Sofortüberweisung) – der Laden müsste dann zusehen, wie er sein Geld vom Kunden bekommt, vor allem, nachdem dieser einen bösen Brief von seiner Bank erhalten hat. Es wäre natürlich auch denkbar, dem Kunden einfach den Onlinezugang wegen Missbrauch zu sperren. Ehrlich gesagt überrascht es mich massiv, dass das nicht durch irgendwelche automatischen Systeme, denen das hohe Transaktionsvolumen auffällt, geschehen ist. Die vereinzelten Posts in Foren, wo behauptet wird, dass Leuten wegen der Nutzung von Sofortüberweisung.de (d.h. unberechtigter Weitergabe von Zugangsdaten) die Onlinebankingzugänge oder gar Konten gekündigt werden, sind bisher (leider, muss man sagen) vermutlich eher Falschmeldungen, das kann sich aber natürlich noch ändern. In Foren als Möglichkeit erwähnt und durchaus denkbar ist es, dass die Banken protokollieren, wer derart gegen AGB verstößt, und im Falle eines Schadens (z. B. durch Phishing) das Verhalten des Kunden als Argument benutzen, um den Schaden nicht auszugleichen. Sofortüberweisung.de „empfiehlt“ den Shopbetreibern, um Abmahnungen durch Verbraucherzentralen zu vermeiden, zu Erklärungen von Sofortüberweisung einen Text hinzuzufügen, in dem zwischen viel wiederholendem Geschwurbel steht:

Vorsorglich weisen wir dennoch darauf hin, dass es in Deutschland Banken und Sparkassen gibt, die davon ausgehen, dass die Nutzung von sofortüberweisung.de wegen der Verwendung von PIN und TAN außerhalb der eigenen Online-Banking-Systeme bei etwaigen Missbrauchsfällen zu einer Haftungsverlagerung führen kann. Dies kann bedeuten, dass im Missbrauchsfall die Bank sich weigert, den Schaden für den Endkunden zu übernehmen und der Endverbraucher den Schaden zu tragen hat.

Für Händler hat das Verfahren neben der Abmahngefahr außerdem noch das Problem, dass die Überweisung keineswegs so garantiert ist wie angedeutet wird – Sofortüberweisung bestätigt nur, dass die Überweisung abgeschickt wurde. Wenn der Kunde die Überweisung direkt danach bei der Bank widerruft, oder die Bank sich einfach entscheidet, die Überweisungen zu stornieren, dürfte der Händler seinem Geld wohl hinterherlaufen.

Giropay hat übrigens auch ein Problem, ist nämlich bei unvorsichtigen Nutzern besonders anfällig gegen Phishing. Der Nutzer wird von einer Drittwebsite (Onlineshop) auf sein Onlinebanking umgeleitet und soll sich dort einloggen. Der Onlineshop könnte den Nutzer nun auf eine Phishingseite umleiten. Wenn der Nutzer weiß, wie Giropay zu funktionieren hat (d.h. Login erfolgt auf der eigenen Bankwebsite) und er (z. B. über das SSL-Zertifikat) prüft, dass er sich auf der richtigen Website befindet, würde er so etwas natürlich erkennen. Ich weiß das, weiß wie ich das prüfen kann, und tue es auch konsequent – ich bezweifle jedoch, dass das auf Otto Normalnutzer auch zutrifft. Das ließe sich mit ein wenig Aufklärung aber wahrscheinlich korrigieren, denn die Nutzer sind inzwischen für Sicherheitsthemen gerade beim Onlinebanking sensibilisiert. Das gleiche Problem (mit der gleichen Lösung) gibt es übrigens auch beim Verified-by-Visa-Programm für Kreditkarten (bei Online-Kreditkartenzahlungen muss man sich bei Visa einloggen, somit sind Zahlungen nur mit den Infos die der Händler klauen kann nicht mehr mögich) sowie beim Authentifizierungsverfahren OpenID – und natürlich bei Sofortüberweisung, wo ein „Phishing-Angriff“ sogar mehr oder weniger Teil des Verfahrens ist.

Und nein, ich bekomme für diesen Artikel weder Geld noch habe ich irgendwas mit Giropay oder sonstigen Online-Zahlungssystemen zu tun. Es regt mich „nur“ tierisch auf, wenn das Verletzen grundlegener Sicherheitskonzepte zum Geschäftsmodell gemacht wird. Wenn man sich die Kommentare im Heiseforum zur Entscheidung des Kartellamts anschaut, bin ich offensichtlich nicht der einzige.

Zusammenfassung:

Probleme für Kunden

• Kontoumsätze wurden und werden abgefragt
• Missbrauch möglich
• Keine Rückbuchung bei Problemen mit Händler (wie bei normaler Vorkasse auch)
• AGB-Verstoß gegen Bank-AGB
  • Bank könnte Haftung bei Missbrauch (auch in unabhängigen Fällen!) verweigern
  • Onlinebanking-Sperrung denkbar

Probleme für Händler

• Verlust von Kunden die wissen wie das Verfahren funktioniert und es daher nicht nutzen wollen oder es gar als unseriös ansehen
• Abmahngefahr durch Verbraucherzentralen
• Zahlungen sind keineswegs garantiert!