Diskussion:Homebanking Computer Interface

Liste von HBCI-Geschäftsvorfällen

Kann jemand diese Tabelle um die Übertragungs-Codes erweitern ? (nicht signierter Beitrag von Bastl73 (Diskussion | Beiträge) 23:41, 6. Nov. 2011 (CET))

Spricht etwas dagegen, die Liste um zusätzliche Spalten zu erweitern? Aus denen soll je Bank hervorgehen, welche Geschäftsvorfälle unterstützt werden. Mathias (nicht signierter Beitrag von 77.178.140.80 (Diskussion) 17:00, 2. Mär. 2012 (CET))

Zwei zusätzliche Spalten habe ich eingefügt. Es wäre schön, wenn da noch mehr hinzu kämen. Mathias (nicht signierter Beitrag von 77.178.150.148 (Diskussion) 21:27, 26. Mai 2012 (CEST))

Tabelle

eine Tabelle, in der die Unterschiede HBCI und Co verglichen werden wäre übersichtlich. Z.B. eine Spalte Ports, Einführungsjahr, etc.. --J. Stein 16:37, 29. Aug. 2011 (CEST)

Wie funktioniert (z. B.) HBCI Diskette prinzipiell?

Liebe HBCI-Artikel Bearbeiter/innen, ich bin Laie in Sachen HBCI. Ich würde mir wünschen, dass das Verfahren im Artikel prinzipiell dargestellt wird. Bei HBCI Diskette etwa in der Form: Man füllt Überweisung aus, Daten werden mit Signatur versehen, werden verschlüsselt, gehen zur Bank, werden von der Bank verschlüsselt zurückgesendet oder wie immer das funktioniert.

Mir ist beim Einsatz von HBCI Diskette aufgefallen, dass er jedes Mal die Datei auf der Diskette ändert. Was macht er da? Warum passiert das? Eben eine Erklärung die auch ein Laie mit EDV-Wissen versteht.

Vielleicht wäre das ja für die Fachleute hier möglich. Ich habe den Artikel gelesen, diese Informationen aber nicht gefunden (vielleicht auch nicht verstanden).

Herzliche Grüße Rainer

2-Key-3DES

Hallo liebe IP 62.214.227.189, die Schlüssellänge von 2-Key-3DES soll durchaus im Artikel erwähnt werden, da bei diesem Thema jeder immer nach den Bits fragt. Natürlich ist 128 insofern falsch, als dass da die CRC mit reingerechnet wurde; richtig ist also 112 Bits (eben zweimal 56).

Und die Erklärung von 2-Key-3DES, naja, die steht so mitten im Artikel vielleicht nicht an idealer Position, aber anderswo ist sie auch nicht zu finden. Auf 3DES zumindest ist das dermaßen versteckt, daß es eigentlich gar nicht lohnt, dort hin zu verlinken. Aber wenn es einen extra Eintrag oder einen direkt erreichbaren, verständlichen Abschnitt auf 3DES gibt, dann kann die Erklärung hier auch gerne raus. --Cstim 14:03, 17. Aug 2005 (CEST)

Bin sonst eher Benutzer:134.60.1.151 *g*, vielleicht sollte man eher 3DES von DES abkoppeln? Ich seh dein Problem. Meines war, dass ich mich von den teils auch noch falschen Erklaerungen hab ablenken lassen und erst beim dritten lesen HBCI verstanden hab. --Benutzer:134.60.1.151 14:00, 2. Sep 2005 (CEST)

Na klar, mach doch gerne einen extra Artikel für 3DES auf. Sobald da eine vernünftig erreichbare Erklärung von 3DES ist, sollte die Erklärung hier auch wieder raus. Ich hab nur von den tatsächlich Crypto-Sachen nicht genug Ahnung, als dass ich mich da auch noch einmischen würde. --Cstim 14:13, 2. Sep 2005 (CEST)

Kein Belauschen

"Bei diesem Verfahren kann weder der kryptographische Schlüssel der Karte ausgelesen werden, noch ist das Belauschen der PIN-Eingabe mit einem Keylogger oder Trojaner möglich." Kann jemand erklären warum das so ist? Oder auf eine erklärende Seite verweisen? --Pinetik 12:36, 2. Sep 2005 (CEST)

Das ist so, weil die Verschlüsselung der Daten (bzw. des Session-keys) in dem Prozessor der Chipkarte stattfindet. Der Schlüssel kommt wie erwähnt nie aus der Chipkarte raus, sondern der Computer schickt den cleartext zum Prozessor der Chipkarte und bekommt den ciphertext zurück. Der Chipkarten-Prozessor braucht aber halt die PIN dazu, und wenn diese direkt am Kartenleser eingegeben wird, dann kommt die PIN auch nie in den Computer rein, sondern wird nur vom Kartenleser an die Chipkarte gegeben. Ist das verständlich? --Cstim 13:02, 2. Sep 2005 (CEST)

Ack. Der Computer muss als generell unsicher angesehen werden. Die Karte "hoffentlich" nicht. Insofern ist HBCI ein Fortschritt, am besten wenn man alles an Display und Tastatur des Kartenlesers macht. --Benutzer:134.60.1.151 14:00, 2. Sep 2005 (CEST)

Naja, HBCI ist dann und nur dann ein Fortschritt, wenn man tatsächlich die Chipkarte als Sicherheitsmedium benutzt. Bei RDH (Schlüsseldiskette/-datei) fällt das weg (aber man hat wenigstens noch die Signatur der Aufträge), und bei PIN/TAN hat man gar nix. Die unterschiedlichen Sicherheitsmedien machen es schwer, eine einheitliche Aussage "über HBCI" (oder genauso FinTS) zu machen. --Cstim 14:13, 2. Sep 2005 (CEST)

man kann doch die kommunikation mit dem kartenleser genauso belauschen. wenn ein sniffender trojaner dazwischen sitzen sollte, müßte das genauso zu knacken sein wie alles andere. also der sicherheitsvorteil gegenüber diskette dürfte marginal sein. --217.84.44.68 15:09, 13. Jun. 2007 (CEST)

Abhängig vom verwendeten Algorithmus hilft das aber nicht: Zero_Knowledge. Die Daten auf der Diskette hingegen kann man direkt auslesen. 134.58.253.57 11:20, 6. Nov. 2008 (CET)

Restrisiko Chipkarte

Hallo, folgenden Absatz im Abschnitt "Technische Merkmale - Sicherheit" habe ich gelöscht:

Eine potentielle Gefahr herrscht jedoch weiterhin: Wenn es einem Schadprogramm gelingt, die Kommunikation zwischen Clientsoftware und Kartenleser zu manipulieren, dann besteht damit die Möglichkeit, veränderte Datensätze an die Chipkarte zu übermitteln. Die Karte fordert weiterhin die PIN des Benutzers an, welche auch nicht durch das Schadprogramm ausgespäht werden kann, und autorisiert anschließend den erhaltenen Transaktionsauftrag. Dieser entspricht jedoch nicht dem vom Benutzer erstellten. Mit entsprechenden Bemühungen kann es einer kriminellen Person also gelingen, auf sehr elegante Weise, vom Benutzer völlig unbemerkt, dessen Konto zu plündern.

Das stimmt nämlich nicht. Der Kartenleser verschlüsselt mitnichten den eigentlichen Auftrag, sondern nur den session key. Der session key wird in der Applikation erzeugt, ebenso wie der eigentliche Auftrag. Ein Angreifer will ja den Auftrag manipulieren (um das Empfängerkonto zu ändern). Da kommt er in diesem Fall nur noch ran, wenn er die Applikation verändert. Das wiederum ist bei kompromittiertem Computer durchaus theoretisch möglich, weshalb ich einen entsprechenden Text reingesetzt habe. Aber die Kommunikation zum Kartenleser bringt in diesem Fall gar nichts, denn der session key hat ja nix mit den Auftragsdaten zu tun. --Cstim 17:11, 10. Jan 2006 (CET)

Nachtrag: Na ja, vielleicht stimmt es doch so ein bisschen. Das Schadprogramm könnte sich auf diese Weise einen gültig signierten session key besorgen und vom Kartenleser an die Applikation stattdessen einen ungültigen zurückgeben. Die angegriffene Bankingsoftware kriegt beim Abschicken des ungültigen session keys vom Bankserver die Rückmeldung "Signatur falsch", und das Schadprogramm könnte dann schnell mit dem signierten session key einen eigenen HBCI-Auftrag losschicken. Dazu müsste das Schadprogramm einerseits alle Zugangsdaten (HBCI-Benutzerkennung etc) aus dem angegriffenen Programm auftreiben und andererseits einen gültigen HBCI-Auftrag zusammenbasteln. Wäre also nur mit einem für ein bestimmtes Homebankingprogramm maßgeschneidertes Schadprogramm möglich, und das ist eigentlich die gleiche Kategorie als wenn ein Angreifer gleich das Homebankingprogramm direkt manipuliert. Es genügt eben nicht, nur in der Kommunikation zum Kartenleser ein paar Werte zu ändern. Also liebe IP 134.147.40.98 (ruhr-uni-bochum.de), wenn du das genauer formulieren willst, dann gerne, nur bitte beachten, dass in der Kommunikation zum Kartenleser noch nicht der Auftrag selber drin ist, sondern eben nur ein session key. --Cstim 17:26, 10. Jan 2006 (CET)

Und was ist, wenn ein Trojaner sich in die Tastatureingabe und Bildschirmausgabe einhängt und alle Überweisungen auf ein anderes Konto umbiegt, aber die Bildschirmausgabe so manipuliert, daß das richtige Konto angezeigt wird?

Klar, das ist ein mögliches Angriffsszenario, was ich im obigen Absatz schon genannt habe: ein Angreifer könnte das Homebankingprogramm (welches die Überweisungs-Angaben anzeigt) direkt manipulieren. Dazu genügt aber eben nicht ein Trojaner in der Tastatureingabe (was recht einfach wäre), sondern der müsste eben auch die Bildschirmdarstellung des Homebankingprogramms ändern. Also ein Angriff maßgeschneidert auf das vorliegende Homebankingprogramm (was erheblich schwieriger wäre). Ein Tastatur-Trojaner genügt nicht. --Cstim 10:44, 8. Jan. 2007 (CET)

Gilt Angriff für jede Homebanking-Methode

Bemerkung zu: "Angriff gilt für jede Homebanking-Methode": Diese pauschale Aussage ist nicht korrekt, z.B. Homebanking per mTAN ist resistent gegen Programmmanipulationen, da hier das Mobiltelefon als vom PC unabhängige Instanz zur Überprüfung der Transaktion herangezogen wird! Im Endeffekt übernimmt das Handy damit als vom PC unabhängige Instanz die Rolle, die ein Klasse3 Kartenleser, mit eigenem Display zur unabhängigen Anzeige der zur Signatur vorgelegten Daten, eigentlich bei HBCI spielen sollte (Was aber leider nicht der Fall ist. Nach der FinTS Spezifikation Zufolge wird sich das bedauerlicherweise auch nicht ändern, was höchst ärgerlich ist, da der Vorteil eines Kartenlesers ja gerade der ist, das er vertrauliche Vorgänge unabhängig vom PC bearbeiten soll :( )

Na endlich wird hier mal diskutiert. Also zuerst gilt schon mal, wenn wir über Risiko reden, dann muss da auch eine Aussage darüber drinstecken, ob dieses Risiko groß oder klein ist, ansonsten ist die Aussage nämlich wertlos. Bei Homebanking wird das implizit dadurch gemacht, dass man sagt, ob Methode X ein größeres oder kleineres Risiko als Methode Y hat. Eine Aussage der Form "Risiko ABC existiert bei Methode X" sollte daher ergänzt werden durch die Bewertung, ob das gleiche Risiko ABC denn bei den Methoden Y1, Y2 und Y3 ebenfalls existiert.

Nun konkret: Der genannte Angriff auf Chipkarten-HBCI benötigt eine "passgenaue Manipulation der Bankingsoftware auf dem PC", so dass sie was anderes anzeigt, als sie tatsächlich von der Chipkarte signieren lässt und an die Bank schickt. Der gleiche Angriff (mit passgenauer Software-Manipulation auf dem PC) könnte bei jeglichem PIN/TAN-Web-Banking durchgeführt werden, indem der Browser des Users die angezeigte Bank-Webseite verändert und dadurch einen anderen Auftrag abschickt als angezeigt. Schwachstelle ist hier immer das Vertrauen in die "Anzeige am PC" - die zu manipulieren ist ein erfolgreicher Angriff. Der Einwand oben, man könne dies durch "m-TAN" umgehen, also die Anzeige der Auftragsdaten in einer SMS ans Handy, stimmt insofern, als dass die Manipulation der "Anzeige am PC" hier nicht ausreicht. Aber man kann das Szenario problemlos erweitern und an dieser Stelle eben hinzufügen, dass ein Angriff halt auch das Handy mit einer "passgenauen Manipulation der Handy-SMS-Anzeigesoftware" verändern müsste. Ist prinzipiell genauso wenig unmöglich wie die "passgenaue Manipulation der Bankingsoftware"; vielleicht ein bisschen schwieriger, aber keineswegs unmöglich.

Der Punkt ist doch: So einen Angriff wird es nie geben. Was es geben wird, sind Standard-Keylogger und Man-in-the-middle, denn nur dort lohnt sich der Angriffs-Aufwand im Verhältnis zur Beute von denen, die drauf reinfallen. Deswegen muss eine Homebanking-Technik diese Angriffe abwehren und alles weitere ist definitiv zu viel des Guten. Signierung via Chipkarte wie in HBCI vorgesehen ist dabei eine von mehreren Möglichkeiten. Der hypothetische Angriff mit der manipulierten Bankingsoftware ist dagegen einerseits unwahrscheinlicher als zehn andere Risiken und andererseits keineswegs HBCI-spezifisch. Also soll er auch nicht so dargestellt werden. --Cstim 09:32, 8. Feb. 2007 (CET)

Das ist ja schön. Standard-Keylogger und Man-in-the-middle dürften bei HBCI per Diskette schon nicht viel bringen. Kann ich das ja beruhigt weiternutzen. :) --217.84.44.68 15:13, 13. Jun. 2007 (CEST)

Ich bin neu im Thema HBCI, aber ich stelle das einfach mal in Frage. Erstmal gibt es bereits erfolgreiche Angriffe auf mobile TANs. Erst kürzlich war das hier zu lesen: http://heise.de/-1661773. Ich glaube, es gab auch schon erfolgreiche Angriffe auf Kartenleser. Dort wurde einfach eine neue Firmware aufgespielt. Kürzlich wurde ja auch bekannt, dass EC-Karten-Geräte auch manipulierbar waren. Natürlich muss man als Angreifer so ein Gerät erstmal erreichen können, aber wenn man das geschafft hat, ist die Manipulation vielleicht sogar einfacher als die von komplexen Desktop- oder Webanwendungen und werden vielleicht auch viel später bemerkt und behoben. Außerdem frage ich mich, ob es nicht reicht, die Kommunikation mit der zwischen der Software und der HBCI-Schnittstelle anstatt der GUI zu manipulieren. Ich kann das alles jetzt nicht abschließend beurteilen, aber wollte dem ganzen kritisch auf den Zahn fühlen. --79.226.153.232 11:47, 12. Aug. 2012 (CEST)

Es gibt keine erfolgreichen Angriffe auf mTans außer der Benutzer ist so doof die Medien nicht getrennt zu halten. Und ja man kann HBCI manipulieren. Das wären aber gezielte Angriffe, nicht das große Abschöpfen und mit Malware um sich werfen dass man bei anderen Verfahren benutzt. Denn es gibt erst mal nichts dass verhindert dass die Überweisungsdaten die ich am PC eingebe nicht bereits dort verfälscht werden. --95.88.225.48 11:05, 21. Mär. 2015 (CET)

Welche Banken benutzen das denn noch beim Homebanking?

Gibt viele Listen dafür. Als Beispiel unter vielen sei http://linuxwiki.de/OpenHBCI/GetesteteBanken genannt. Die Angabe im Artikel unter "Geschichte" ist weiterhin korrekt. --Cstim 09:45, 26. Mär. 2007 (CEST)

Im Kapitel Geschichte steht: [...]blieb HBCI rein auf den deutschen Bankenmarkt beschränkt. Die Schweizer UBS benutzt dieses Verfahren oder ist das etwas anderes? http://www.ubs.com/2/g/ebanking_help/Menues/Login/LoginContract.htm Wernfried 17:21, 21. Mai 2007 (CEST)

Häh? Die genannte URL beschreibt ein Banking-Verfahren, dass ja noch abstruser ist als alles, was ich bisher gehört habe (Zahlencode von Webseite in einen Chipkartenleser eingeben und Resultat vom Chipkartenleser wieder auf Webseite angeben???!?). Jedenfalls ist das garantiert kein HBCI. --Cstim 13:09, 23. Mai 2007 (CEST)

Richtig, es ist kein HBCI. Sondern ein TAN Verfahren mit einem TAN-Generator. Anstatt daß die Bank ständig neue TAN Listen zuschickt werden die mit einem externen Taschenrechnergroßen Gerät, dem TAN-Generator selbst erzeugt. Cortal Consors wäre z.B. eine Bank, die so ein Verfahren anbietet. Siehe auch: TAN-Generator --109.193.36.240 02:20, 9. Apr. 2010 (CEST)

Manipulierte Chipkartenleser

Am 02.06.2010 berichtete heise.de über eine Sicherheitslücke bei Chipkartenlesern der Fa. Kobil: http://www.heise.de/security/meldung/Kartenleser-von-Kobil-gehackt-1013021.html Über die Lücke konnte eine manipulierte Firmware aufgespielt werden. Hat dies auch Auswirkungen auf die Sicherheit von HBCI? (nicht signierter Beitrag von 195.140.44.146 (Diskussion) 12:00, 21. Jun. 2010 (CEST))

Einstellung ab 2021

Meine Bank (Sparkasse) hat mich heute (15.10.2019) darüber informiert, dass das HBCI-Verfahren im Jahr 2021 eingestellt wird. --77.21.185.91 10:13, 15. Okt. 2019 (CEST)