Giropay vs. Sofortüberweisung – Interview mit SÜ-Vorstand Dr. Lütcke

Das Interview bringt ja schoneinmal etwas mehr Licht ins Dunkle, für mich ist der Punkt der Weitergabe an Dritte noch nicht ganz klar.. Wie soll das denn definiert werden?? Ich kann meine Daten doch auch nicht dem angesprochenen Postboten geben und sagen er sei nur ein “Dienst”.

Bitte um Aufklärung.

VG,
Thiel

>Daten wie PIN und TAN sind für uns nicht einsehbar, sondern wir leiten diese verschlüsselt an das Kreditinstitut weiter.

Tut mir leid, aber als technisch versierter Mensch würde mich doch interessieren, wie Sie das sicherstellen wollen. Soweit ich das sehe habe ich nämlich ein SSL Zertifikat zu Direktüberweisung und nicht zu meiner Bank. Damit schicke ich die Daten NICHT verschlüsselt zu meiner Bank sondern erstmal verschlüsselt an Direktüberweisung. Es mag sein, dass Direktüberweisung diese Daten dann programmseitig direkt an die Bank weitergibt und das hoffentlich auch wieder verschlüsselt. Das ändert aber nichts daran, dass dazwischen eben Ihr Server und Ihr Programm ist. Praktisch eine Man-In-The-Middle-Attack mit Ankündigung.

Ich glaube gern, dass Sie das Programm so geschrieben haben, dass die Daten nicht gespeichert werden. Aber wer garantiert mir, dass das so bleibt? Was passiert, wenn jemand in Ihr System eindringt und die Daten doch herausholt. Bei Giropay ist das das Problem der Bank.

Tut mir leid, aber so gern ich Ihr Bezahlverfahren in meinem Shop anbieten möchte, so stark misstraue ich dem Service. Bisher konnten Sie meine Bedenken bisher auf jeden Fall nicht widerlegen – sie reden vielmehr drum rum. Denn Fakt bleibt, dass Ihr Server dazwischen steht.

Ich habe sofortüberweisung seit Herbst im shop integriert und war von der Bedienerfreundlichkeit angenehm überrascht. Ich würde mir allerdings ein aggresiveres Marketing von payment Network wünschen, damit gerade auch beim eher “unbedarften” Endkunden Zweifel geklärt und sofortüberweisung als sicheres Zahlungsmittel angenommen wird. Dieser Baknntheitsgrad trifft aber auf giropay genau so zu. Für beide Möglichkeiten sollte mehr Öffentlichkeitsarbeit seitens der Anbieter getätigt werden.

Herr Zierhut, das bestätigt doch nur, dass Ihre Kunden sich nicht um die Sicherheit Ihrer Daten kümmern und sogar die Sicherheit anderer gefährden, denn welches Unternehmen kann solch ausgefeilte Statistiken über PIN/TAN Kombinationen erstellen und auswerten!?

Ich will gar nicht wissen, wieviele Kunden Ihre PIN nach einer SÜ nicht ändern und somit einfach mal Vollzugriff auf die meisten Daten dauerhaft gewähren.

Ich kann da nur ungläubig mit dem Kopf schütteln.

Fakt ist: wenn ich eine Bank ausraube, komme ich in den Knast. Also kann ich sie gar nicht ausrauben…

Bestechende Logik. Respekt!

Ich ordne mich mal auch zu den technisch halbwegs Versierten ein, und daher kann ich den Gedanken von Mathias bzgl. man-in-the-middle durchaus nachvollziehen. Es wäre für SÜ ohne weiteres möglich, die eingegebenen Daten “abzufangen” und zu manipulieren. Schließlich läuft das Eingabeformular auf den Servern von SÜ, die Eingaben werden dort “verarbeitet” bzw. eben dann direkt an die Bank weitergeleitet. Alles was dazu nötig wäre, ist eine serverseitige Sprache die zunächst die vom Formular emfpangenen Daten (Kto, BLZ, TAN aber auch den Betrag) manipuliert und diese manipulierten Daten dann weiter an die Bank gibt. So könnte sich SÜ also theoretisch munter selbst bereichern, indem sie einfach die Überweisung auf ein anderes Konto umleiten. Als solides Geschäftsmodell wird man das aber wohl nicht betreiben können, da die Sache innerhalb weniger Stunden auffliegen würde.

Es ist halt die Frage, in wie weit man SÜ vertrauen darf, dass sie tatsächlich so programmiert haben, dass die ankommenden Daten direkt an die Bank weitergegeben werden. Nur ist genau das ein Punkt, der sich ab erfolgreichem Booten des Betriebssystems stellt. Wer garantiert mir denn, dass z.B. Microsoft nicht einen Keylogger eingebaut hat, der munter Daten überträgt? Für all jene, die mal einen netten Versuch machen wollen: Installiert ein frisches Windows, hängt den PC ohne weiteres zutun ans Netz (am besten mit DHCP Router) und schon werdet ihr sehen, dass die ersten Daten durchs Netz wandern … wie von Geisterhand.

Als spontane Idee würde ich eher bei den Banken ansetzen. Deren API müsste zunächst eine Verbindung bereit stellen, in der vom Kunden aus mitgeteilt wird, welcher Betrag auf welches Konto soll. Aufgrund dieser Zahlenkombi (kann man ja einen schönen Hash draus basteln) würde dann eine TAN gewählt werden, z.B. Nr 43. Nun übergibt die API dann die TAN-Abfrage an die externe Software (SÜ, Starmoney, Mein Geld usw. usw.). Der Kunde gibt TAN 43 ein und der Datensatz wird via API zurück an die Bank übermittelt. Dort wird dann nochmal überprüft, ob 1. TAN richtig und 2. die Kombination aus Empfängerkonto und Betrag noch passen.
Man müsste über sowas natürlich noch sehr detailliert nachdenken, aber das scheint mir zunächst eine Möglichkeit, mit wenig Aufwand eine ziemlich hohe Sicherheit zu bekommen, trotz zwischengeschalteten “Mittlern”.

PS: bin ebenfalls _nicht_ von SÜ, nutze das aber immer wieder gerne weils schnell geht und noch nie Probleme gab.

@Markus Zierhut:

> Fakt ist, wenn Sofortüberweisung irgendetwas anstellen würde, dass das Ende der Firma besiegelt wäre. Daran dürften die wenig Interesse haben.

Das ist gerade auch ein großes Problem an Sofortüberweisung: wenn ein Hacker in das System eindringt und die Daten abfängt, dann würde eine entsprechende Pressemitteilung dazu führen, dass das Kerngeschäft – das Anbieten einer sicheren Zahlungsmethode – angegriffen wäre. Ergo Moral gegen Gewinn. Ergo fraglich.

Wenn hingegen bei der Bank ein entsprechender Hackerangriff stattgefunden hat, dann traue ich der Bank hier mehr zu, dies auch entsprechend Public zu machen, evtl. sofort die PIN zu sperren. Denn das Kerngeschäft wird dadurch nicht gefärdet, höchstens angekratzt.

Dass die Banken gerne einen Mitbewerber loswerden wollen ist verständlich. Wenn sie selbst ein vergleichbares, günstiges Bezahlsystem anbieten würden, gäbe es jagar keinen Bedarf an Sofortüberweisung.
Sofortüberweisung beweist ja, dass es möglich ist ein solches System aufzubauen UND vernünftige Gebühren zu verlangen. Also müssen irgendwie alle anderen System, die höhere Gebühren verlangen entweder vollkommen unfähig sein ein solches System effizient zu betreiben oder absichtlich überhöhte Gebühren verlangen. Für beides habe ich eigentlich kein Verständnis. Ich finde SÜ ist ein legitimer Anbieter am Markt.
Und wer den Banken von Haus aus einen Vertrauensvorschuss gibt, der hat irgendwie die Entwicklung des letzten Jahres verschlafen…

Hallo an alle,

egal welche Produkte wir anbieten. In den Zahlungsformularen der jeweiligen Produkte, egal ob Sofortüberweisung, Sofortabo, Sofortlastschrift wird den Kunden immer erklärt, was unsere Software macht.

Gruß

Christoph

oh, der Chef persönlich schaltet sich ein! Habe mal einen TV-Beitrag (glaube es war auf VOX) gesehen ;-)

Also man kann denke ich definitiv nicht abstreiten, dass externe Möglichkeiten der Überweisung (sei es nun SÜ oder irgendwelche Desktop-Anwendungen) immer ein erhöhtes Sicherheitsrisiko darstellen. Ich muss allerdings auch sagen, dass allein schon die Benutzung von Online Banking eine nicht zu unterschätzende Gefahr darstellt; ich hatte schon einige Kunden, wo sich Keylogger speziell zum Belauschen von Online-Banking-Eingaben auf dem Rechner befanden, glücklicherweise hat das iTAN-Verfahren Schlimmeres verhindert.

Aber nach wie vor bin ich der Überzeugung, dass eigentlich die Banken am Zug sind und bessere/flexiblere Sicherheitsmöglichkeiten einbauen sollten. So könnten externe Anwendungen mit innovativen Ideen trotzdem entstehen, ohne dass deswegen größere Sicherheitsrisiken entstehen.
Und bezüglich der “Kategorisierungsdaten” zur Erstellung individueller User-Profile mit entsprechender Werbung sollten die Banken einfach entsprechende Einstellungs-Menüs anbieten, was alles über die API raus gegeben wird, ähnlich zu Facebook.

@Felix: sehe ich genau so. Prinzipiell sollten Banken gezwungen werden, eine entsprechende API zur Verfügung zu stellen. Ähnlich zu OpenID könnte man dadurch die TAN / PIN – Problematik lösen.

Ich bezweifel leider, dass das freiwillig gemacht werden würde.

Interessanter Artikel bei der Financel Times Deutschland:

http://www.ftd.de/it-medien/it-telekommunikation/:agenda-tag-der-onlineabrechnung/50065421.html