hbci4java-help Mailing List for HBCI4Java (Page 7)
Brought to you by:
kleiner77
Menu
▾
▴
hbci4java-help — all questions concerning hbci4java
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(21) |
Jun
|
Jul
(9) |
Aug
(2) |
Sep
(16) |
Oct
(9) |
Nov
(10) |
Dec
(31) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(16) |
Feb
(43) |
Mar
(11) |
Apr
(4) |
May
(2) |
Jun
(7) |
Jul
|
Aug
(5) |
Sep
(2) |
Oct
(20) |
Nov
(32) |
Dec
(10) |
| 2005 |
Jan
(15) |
Feb
(15) |
Mar
(20) |
Apr
(19) |
May
(1) |
Jun
(5) |
Jul
(1) |
Aug
(9) |
Sep
(6) |
Oct
(5) |
Nov
(2) |
Dec
(1) |
| 2006 |
Jan
(34) |
Feb
|
Mar
(9) |
Apr
|
May
(12) |
Jun
(27) |
Jul
(2) |
Aug
(1) |
Sep
(11) |
Oct
(11) |
Nov
(7) |
Dec
(1) |
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(23) |
| 2008 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
(32) |
May
(29) |
Jun
(22) |
Jul
(3) |
Aug
(5) |
Sep
(25) |
Oct
(30) |
Nov
(25) |
Dec
(1) |
| 2009 |
Jan
(23) |
Feb
(20) |
Mar
(20) |
Apr
(72) |
May
(9) |
Jun
(3) |
Jul
(18) |
Aug
|
Sep
(6) |
Oct
(7) |
Nov
(10) |
Dec
|
| 2010 |
Jan
(19) |
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
(11) |
Jul
(3) |
Aug
(19) |
Sep
(7) |
Oct
|
Nov
|
Dec
(2) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(14) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
|
From: Rolf V. <ro...@we...> - 2009-04-29 20:53:04
|
> -----Ursprüngliche Nachricht----- > Von: "HBCI4Java (Stefan Palme)" <hbc...@ka...> > Gesendet: 29.04.09 21:19:24 > An: hbci4java-help <hbc...@li...> > Betreff: Re: [Hbci4java-help] InfoPoint-Server-Abfrage > > Die Liste ist aber sehr kuemmerlich, da die meisten User > > halt reine "Consumer" sind. Die holen sich die Daten aus > > dem Wiki, passen sie fuer ihre Bank etwas an (z.Bsp. andere > > BLZ) und tragen das in Hibiscus ein. Den Weg zurueck ins > > Wiki findet dann nur ein Bruchteil. > > Das ist es was ich meine. > > Wenn man die Nutzer dabei nicht unterstützt (mit "diese funktionierenden > Daten an den InfoPoint-Server senden"), werden wahrscheinlich nur die > wenigsten tatsächlich irgendwelche WIKIs aktualisieren (zumal ich die > Erfahrung gemacht habe, dass viele Leute gar nicht in WIKIs schreiben > WOLLEN, auch wenn sie DÜRFTEN und KÖNNTEN...) > > -stefan- Das denke ich auch. User sind bequem, aber es gibt ja schon einige Beispiele dafür, dass Programme nützliche Daten automatisch (nach Bestätigung durch den User) an den Server schicken (z. B. bei Abstürzen). Wenn man den User also zu gegebenem Zeitpunkt um Erlaubnis bittet, und gleichzeitig zusichert, dass keine privaten/persönlichen Daten mitgeschickt werden, sondern nur unkritische Daten, wird es sicherlich einige User geben, die das zulassen. Man kann ja in der Dialogbox extra betonen, dass der User mit diesem Feature einen nennenswerten Beitrag zur Weiterentwicklung der Software leistet, um ihm einen Anreiz zu bieten. Ich denke, man kann durchaus progressiv an die Sache herangehen, und ein derartiges Feature standardmäßig aktivieren, aber natürlich sollte der User jedesmal vorher um Erlaubnis gebeten werden, und außerdem sollte man das Feature (Daten an InfoPoint schicken) auch dauerhaft komplett deaktivieren können. Das könnte etwa so aussehen [mit nichtproportionalem Font anschauen]: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Möchten Sie einen Beitrag zur Weiterentwicklung dieses Programmes leisten, | | indem Sie die folgenden, anonymen Informationen zu den Systemen Ihrer Bank | | zur Aufnahme in unsere Online-Datenbank freigeben? | | ---technische Daten--- | | ---technische Daten--- | | ---technische Daten--- | | Die Daten enthalten keine Informationen zu Ihren Konten, Salden oder | | Zugangsdaten und können nicht verwendet werden, um Ihnen zu schaden. | | Hier finden Sie weitere Infos zur Verwendung der Daten: [Link] | | [Ja, Infos senden] [Nein, diesmal nicht senden] [Nein, niemals senden] | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Falls es wieder Erwarten doch zu viele User geben sollte, die das gar nicht gut finden, könnte man die Defaulteinstellung noch mal überdenken. Aber ich denke nicht, dass es zu viele User gibt, die damit ein Problem haben. Wenn die Defaulteinstellung lautet, die Daten nicht zu schicken, gibt es vermutlich zu wenige, die NICHT zu faul sind, um die Defaulteinstellung zu ändern. Rolf |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-29 19:18:21
|
> Die Liste ist aber sehr kuemmerlich, da die meisten User > halt reine "Consumer" sind. Die holen sich die Daten aus > dem Wiki, passen sie fuer ihre Bank etwas an (z.Bsp. andere > BLZ) und tragen das in Hibiscus ein. Den Weg zurueck ins > Wiki findet dann nur ein Bruchteil. Das ist es was ich meine. Wenn man die Nutzer dabei nicht unterstützt (mit "diese funktionierenden Daten an den InfoPoint-Server senden"), werden wahrscheinlich nur die wenigsten tatsächlich irgendwelche WIKIs aktualisieren (zumal ich die Erfahrung gemacht habe, dass viele Leute gar nicht in WIKIs schreiben WOLLEN, auch wenn sie DÜRFTEN und KÖNNTEN...) -stefan- |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-29 19:14:39
|
> Wie waere es also, wenn man einfach die Adresse aus dieser DB herauslaesst - > die kann der Benutzer ja nun wirklich dem Brief entnehmen - und stattdessen > nur die anderen beschriebenen Parameter speichert? > > Dann haette man zum einen das Problem mit der noetigen Aktualitaet der Server- > Adressen gar nicht erst, und zum anderen ist die Spamgefahr niedriger (denn > mit dem mutwilligen Unterschieben falscher Angaben zur HBCI-Version etc kann > man zwar die Nuetzlichkeit so einer DB auf 0 reduzieren, aber nur schwerlich > eine boesartige Umleitung erzeugen). > > Und dann koennte man die DB auch weiterhin automatisch aktualisierbar lassen > (und hier dann die beschriebenen anderen Sicherheitsmechanismen einbauen). Auch wenn ein Angreifer durch Fälschen der restlichen Daten (HBCI- Version, Filter, ...) dafür sorgen kann, dass ein Nutzer seinen HBCI- Zugang nicht mehr nutzen kann (außer, dieser überschreibt die falschen Daten manuell, wenn er die richtigen weiß), kann der Angreifer sich zumindest nicht mehr ohne weiteres als MITM etablieren... - klingt also nach einem guten Plan! Ich denk mal drüber nach... -stefan- |
|
From: Philipp E. <de...@ke...> - 2009-04-29 16:30:09
|
Am 29.04.2009 um 18:21 schrieb Olaf Willuhn: > On Wednesday 29 April 2009 18:17:15 Martin Preuss wrote: > >> Wie waere es also, wenn man einfach die Adresse aus dieser DB >> herauslaesst >> - die kann der Benutzer ja nun wirklich dem Brief entnehmen - und >> stattdessen nur die anderen beschriebenen Parameter speichert? >> >> Dann haette man zum einen das Problem mit der noetigen Aktualitaet >> der >> Server- Adressen gar nicht erst, und zum anderen ist die Spamgefahr >> niedriger (denn mit dem mutwilligen Unterschieben falscher Angaben >> zur >> HBCI-Version etc kann man zwar die Nuetzlichkeit so einer DB auf 0 >> reduzieren, aber nur schwerlich eine boesartige Umleitung erzeugen). >> >> Und dann koennte man die DB auch weiterhin automatisch aktualisierbar >> lassen (und hier dann die beschriebenen anderen >> Sicherheitsmechanismen >> einbauen). > > Find ich ne gute Idee. Reicht die BLZ dann als Identifier fuer > die Bank-Daten aus? Das sollte für die Identifikation ausreichen, die Datenbanken sollte idealerweise schlau genug sein, Daten von Banken mit mehreren Bankleitzahlen nur einmal vorzuhalten. Viele Grüße, Philipp |
|
From: Olaf W. <hbc...@wi...> - 2009-04-29 16:22:05
|
On Wednesday 29 April 2009 18:17:15 Martin Preuss wrote: > Wie waere es also, wenn man einfach die Adresse aus dieser DB herauslaesst > - die kann der Benutzer ja nun wirklich dem Brief entnehmen - und > stattdessen nur die anderen beschriebenen Parameter speichert? > > Dann haette man zum einen das Problem mit der noetigen Aktualitaet der > Server- Adressen gar nicht erst, und zum anderen ist die Spamgefahr > niedriger (denn mit dem mutwilligen Unterschieben falscher Angaben zur > HBCI-Version etc kann man zwar die Nuetzlichkeit so einer DB auf 0 > reduzieren, aber nur schwerlich eine boesartige Umleitung erzeugen). > > Und dann koennte man die DB auch weiterhin automatisch aktualisierbar > lassen (und hier dann die beschriebenen anderen Sicherheitsmechanismen > einbauen). Find ich ne gute Idee. Reicht die BLZ dann als Identifier fuer die Bank-Daten aus? Gruss Olaf |
|
From: Martin P. <aqu...@gm...> - 2009-04-29 16:17:29
|
Moin, On Mittwoch, 29. April 2009, HBCI4Java (Stefan Palme) wrote: [...] > Das Problem ist halt die Pflege. Wenn die Banken kein Interesse > daran haben, ihre Daten an einer zentralen Stelle sauber gepflegt > zu sehen (das Argument ist immer "wir schreiben doch die richtigen > Daten in den Brief rein, den die Nutzer bei der Registrierung be- > kommen!"), fällt diese eigentlich sehr schöne Informationsquelle > schon mal weg. [...] Das ist eigentlich ein ganz gutes Argument: Die Serveradresse liefert die Bank ja tatsaechlich im INI-Brief. Nur die anderen Informationen u.U. nicht (Sicherheitsmedium, unterstuetzte Versionen etc). Wie waere es also, wenn man einfach die Adresse aus dieser DB herauslaesst - die kann der Benutzer ja nun wirklich dem Brief entnehmen - und stattdessen nur die anderen beschriebenen Parameter speichert? Dann haette man zum einen das Problem mit der noetigen Aktualitaet der Server- Adressen gar nicht erst, und zum anderen ist die Spamgefahr niedriger (denn mit dem mutwilligen Unterschieben falscher Angaben zur HBCI-Version etc kann man zwar die Nuetzlichkeit so einer DB auf 0 reduzieren, aber nur schwerlich eine boesartige Umleitung erzeugen). Und dann koennte man die DB auch weiterhin automatisch aktualisierbar lassen (und hier dann die beschriebenen anderen Sicherheitsmechanismen einbauen). Gruss Martin -- "Things are only impossible until they're not" Martin Preuss - http://www2.aquamaniac.de/ AqBanking - http://www.aqbanking.de/ LibChipcard - http://www.libchipcard.de/ |
|
From: Jan B. <ja...@mu...> - 2009-04-29 15:44:32
|
Hallo, Danke für den Überblick, Stefan. Aus Olafs Wiki hatte ich sogar die Informationen für mein persönliches Konto, habe es dann aber wieder aus den Augen verloren. :/ Du hast Recht, das ist schon nahe dran, an dem was mir vorschwebt (jedenfalls viel eher als das etwas verkrustet wirkende Verfahren unter http://www.hbci-zka.de/institute/institut_hersteller.htm ) Wenn man dieses Konzept in die Richtung erweitern würde, die Philipp beschreibt, d.h. maschinenlesbar und trusted editing, wäre glaube ich sehr viel gewonnen. Zu definieren wäre eine einfache Sprache für diese Domäne (möglichst etwas bereits vorhandenes, die beschreibt, wie man von den Informationen, die die Bank in ihrem Infobrief bereitstellt zu den HBCI-Parametern gelangt. Ganz grob etwa so: ---8<--- 20041133.bankinfo --- // Informationen, die die Bank in Briefform mitteilt a = "Onlinebanking Zugangsnummer" b = "Kontonummer" c = "Filialnummer" d = "Bankleitzahl" e = "Gehaimzahl" ... // Werte für HBCI-Parameter USERID = a + "00" CUSTOMERID = c + b PT_PIN = e.substr(0,5) // nur die ersten 5 Zeichen BLZ = d // kann auch hardcoded sein, wenn die Bank nur eine BLZ hat ---8<--- Der HBCI Client wüsste dann: a) Wie er die Eingabefelder beschriften soll, um beim User Verwirrungen zu minimieren. b) Wie sich die HBCI-Parameter zusammen setzen. Der Syntax soll nur die Idee illustrieren. Für eine reale Umsetzung würde ich aber tatsächlich ein Subset von Javascript oder Python Expressions bevorzugen. Oder ähnliches. Grüsse! Jan On 29.04.2009, at 17:08, Philipp Erler wrote: > Hi, > > ich halte eine Datenbank mit den zur Zugangseinrichtung benötigten > Eckdaten für eine sehr gute Idee, an der wir uns gerne beteiligen. Wir > versuchen bei der Kontoeinrichtung auch von den Begrifflichkeiten > möglichst nah an dem zu sein, was der Nutzer aus Online-Banking oder > von seinem Zugangsbrief kennt, und können daher sicherlich eine Menge > an Informationen beitragen. > > Neben den von Jan vorgeschlagenen Parametern würde ich zusätzlich noch > die Codierung (obgleich eher selten ein Thema) und die Länge der PIN > hinterlegen. Wir erleben es leider häufiger, dass Banken ihren Kunden > längere PINs zuweisen, davon aber beispielsweise nur die ersten 5 > Zeichen beim HBCI-Login verwendet werden dürfen. Suffixe sind aus > unserer Erfahrung ebenfalls relevant, Präfixe sind uns (sieht man > einmal von der Kombination aus Filialnummer und Kontonummer als > Nutzerkennung bei der Deutschen Bank ab) noch nicht untergekommen. > > Um gleichzeitig möglichst umfangreiche Informationen und eine > verlässliche Datenbasis zu haben, ist aus meiner Sicht ein Modell > ähnlich der für Wikipedia bereits mehrfach diskutierten "Trusted > Editors" sinnvoll. Alle Daten können von registrierten Teilnehmern > bearbeitet und hinzugefügt werden, eine Handvoll vertrauenswürdiger > Personen kann Informationen als "überprüft" oder "vertrauenswürdig" > kennzeichnen. Ein Client kann dann beim Aufruf neben dem gewünschten > Format (XML, JSON, ...) spezifizieren, ob er den neuesten Datensatz > oder aber den jüngsten vertrauenswürdigen Datensatz erhalten möchte. > > Viele Grüße, > > Philipp > > > > Philipp Erler > kontoblick.de > > > Am 29.04.2009 um 16:53 schrieb Olaf Willuhn: > >>> Dann fällt mir noch die Wiki-Seite auf Olafs Webseite ein (Olaf, >>> hilf >>> mir mal mit dem Link bitte). Dort hat man zwar noch keine >>> automatisierbare Abfragemöglichkeit, aber vom Prinzip her wäre es >>> sicherlich das, was Du (@Jan) Dir vorgestellt hast, oder? >> >> http://hibiscus.berlios.de/doku.php?id=support:list:banken >> >> Die Liste ist aber sehr kuemmerlich, da die meisten User >> halt reine "Consumer" sind. Die holen sich die Daten aus >> dem Wiki, passen sie fuer ihre Bank etwas an (z.Bsp. andere >> BLZ) und tragen das in Hibiscus ein. Den Weg zurueck ins >> Wiki findet dann nur ein Bruchteil. >> Sicher auch deswegen, weil es nicht wirklich komfortabel >> und komplett manuell ablaeuft. >> >> Gruss >> Olaf >> >> ------------------------------------------------------------------------------ >> Register Now & Save for Velocity, the Web Performance & Operations >> Conference from O'Reilly Media. Velocity features a full day of >> expert-led, hands-on workshops and two days of sessions from industry >> leaders in dedicated Performance & Operations tracks. Use code >> vel09scf >> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf >> _______________________________________________ >> Hbci4java-help mailing list >> Hbc...@li... >> https://lists.sourceforge.net/lists/listinfo/hbci4java-help > > > ------------------------------------------------------------------------------ > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code > vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > _______________________________________________ > Hbci4java-help mailing list > Hbc...@li... > https://lists.sourceforge.net/lists/listinfo/hbci4java-help |
|
From: Philipp E. <de...@ke...> - 2009-04-29 15:08:14
|
Hi, ich halte eine Datenbank mit den zur Zugangseinrichtung benötigten Eckdaten für eine sehr gute Idee, an der wir uns gerne beteiligen. Wir versuchen bei der Kontoeinrichtung auch von den Begrifflichkeiten möglichst nah an dem zu sein, was der Nutzer aus Online-Banking oder von seinem Zugangsbrief kennt, und können daher sicherlich eine Menge an Informationen beitragen. Neben den von Jan vorgeschlagenen Parametern würde ich zusätzlich noch die Codierung (obgleich eher selten ein Thema) und die Länge der PIN hinterlegen. Wir erleben es leider häufiger, dass Banken ihren Kunden längere PINs zuweisen, davon aber beispielsweise nur die ersten 5 Zeichen beim HBCI-Login verwendet werden dürfen. Suffixe sind aus unserer Erfahrung ebenfalls relevant, Präfixe sind uns (sieht man einmal von der Kombination aus Filialnummer und Kontonummer als Nutzerkennung bei der Deutschen Bank ab) noch nicht untergekommen. Um gleichzeitig möglichst umfangreiche Informationen und eine verlässliche Datenbasis zu haben, ist aus meiner Sicht ein Modell ähnlich der für Wikipedia bereits mehrfach diskutierten "Trusted Editors" sinnvoll. Alle Daten können von registrierten Teilnehmern bearbeitet und hinzugefügt werden, eine Handvoll vertrauenswürdiger Personen kann Informationen als "überprüft" oder "vertrauenswürdig" kennzeichnen. Ein Client kann dann beim Aufruf neben dem gewünschten Format (XML, JSON, ...) spezifizieren, ob er den neuesten Datensatz oder aber den jüngsten vertrauenswürdigen Datensatz erhalten möchte. Viele Grüße, Philipp Philipp Erler kontoblick.de Am 29.04.2009 um 16:53 schrieb Olaf Willuhn: >> Dann fällt mir noch die Wiki-Seite auf Olafs Webseite ein (Olaf, hilf >> mir mal mit dem Link bitte). Dort hat man zwar noch keine >> automatisierbare Abfragemöglichkeit, aber vom Prinzip her wäre es >> sicherlich das, was Du (@Jan) Dir vorgestellt hast, oder? > > http://hibiscus.berlios.de/doku.php?id=support:list:banken > > Die Liste ist aber sehr kuemmerlich, da die meisten User > halt reine "Consumer" sind. Die holen sich die Daten aus > dem Wiki, passen sie fuer ihre Bank etwas an (z.Bsp. andere > BLZ) und tragen das in Hibiscus ein. Den Weg zurueck ins > Wiki findet dann nur ein Bruchteil. > Sicher auch deswegen, weil es nicht wirklich komfortabel > und komplett manuell ablaeuft. > > Gruss > Olaf > > ------------------------------------------------------------------------------ > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code > vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > _______________________________________________ > Hbci4java-help mailing list > Hbc...@li... > https://lists.sourceforge.net/lists/listinfo/hbci4java-help |
|
From: Olaf W. <hbc...@wi...> - 2009-04-29 14:53:42
|
> Dann fällt mir noch die Wiki-Seite auf Olafs Webseite ein (Olaf, hilf > mir mal mit dem Link bitte). Dort hat man zwar noch keine > automatisierbare Abfragemöglichkeit, aber vom Prinzip her wäre es > sicherlich das, was Du (@Jan) Dir vorgestellt hast, oder? http://hibiscus.berlios.de/doku.php?id=support:list:banken Die Liste ist aber sehr kuemmerlich, da die meisten User halt reine "Consumer" sind. Die holen sich die Daten aus dem Wiki, passen sie fuer ihre Bank etwas an (z.Bsp. andere BLZ) und tragen das in Hibiscus ein. Den Weg zurueck ins Wiki findet dann nur ein Bruchteil. Sicher auch deswegen, weil es nicht wirklich komfortabel und komplett manuell ablaeuft. Gruss Olaf |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-29 14:40:01
|
> > Solche "Faulheit" wäre aber durch keine Software der Welt zu > > unterbinden. Denn auch WENN der Nutzer den Zettel einmal auf dem > > Tisch hat, könnte er ja sagen "20 öde Zahlen-/Buchstaben- > > Kombinationen zu vergleichen ist mir jetzt zu anstrengend - wird > > schon passen"... > > Na ja, wie so oft kann man auch hier den Regler zwischen "sicher" und > "bequem" ganz bis zum Anschlag schieben. Dem User nämlich den > Fingerprint gar nicht anzeigen sondern ihn auffordern, ihn einzugeben > und bei Nicht-Übereinstimmung die Arbeit verweigern. Sicher aber > maximal unbequem. Hehe, guter Plan ;-) -stefan- |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-29 14:39:00
|
Hallo, > Das wäre also > - ein Mapping der hbci4java-internen Bezeichnung auf die > Nomenklatur der jeweiligen Bank. > - etwaige Post- oder Prefixe die bei einzelnen Felder davor oder > dahinter gehängt werden müssen (ist das überhaupt relevant?) Ich glaube, in subsembly wird das sogar gemacht. Aber wenn es keinen "Automatismus" gibt, diese Daten zu pflegen... (siehe unten) > - die unterstützten Geschäftsvorfällen wären jetzt nicht meine > Priorität, da sie zum Einrichten des Accounts nicht nötig sind und im > Anschluss dann eh abrufbar sind. Diese Daten können trotzdem nützlich sein. Zum einen könnte man damit ohne HBCI-Kommunikation bereits unterstützte GVs o.ä. abfragen. Zum anderen könnte ich anhand dieser Daten z.B. Auswertungen fahren, welche Versionen von welchen GVs von keiner einzigen Bank mehr unterstützt werden, und die entsprechenden Syntax-Specs. dann aus HBCI4Java entfernen (weit hergeholt zwar, aber mir fallen bestimmt auch noch mehr Anwendungen dafür ein ;-) > Da eine automatische, anonyme Pflege dieser Daten eher problematisch > ist (s. Michaels Mail) würde man diese Datensammlung vielleicht eher > als eine Art WIki mit begrenztem Zugriff organisieren. > Sprich, eine > kleine Gruppe von vertrauenswürdigen Personen kümmert sich um die > Updates. Ist das realistisch? Finden sich hier auf der Liste Menschen, > die ein Interesse an einer gemeinsamen Anstrengung in dieser Richtung > haben? Sowas gibt es schon. Zum einen gibt es die Bankenliste auf http://www.hbci.de. Dort kann man sich auch subscriben, um regelmäßig ein Excel-File mit allen bekannten HBCI-Bank-Daten zu erhalten (dieses wird auch zur Erzeugung der blz.properties in HBCI4Java verwendet). Allerdings werden dort nur Daten eingetragen bzw. aktualisiert, wenn die betreffende Bank die selbst dorthin meldet. Das scheint zwar eine ziemlich gute Idee zu sein (Sicherheit; Daten aus erster Hand, und zwar im Prinzip zum frühestmöglichen Zeitpunkt). Allerdings weiß ich von einigen Banken, dass die ihre Daten 2004 das letzte Mal angesehen und aktualisiert haben. Andere Banken stehen dort gar nicht drin. Dann fällt mir noch die Wiki-Seite auf Olafs Webseite ein (Olaf, hilf mir mal mit dem Link bitte). Dort hat man zwar noch keine automatisierbare Abfragemöglichkeit, aber vom Prinzip her wäre es sicherlich das, was Du (@Jan) Dir vorgestellt hast, oder? Das Problem ist halt die Pflege. Wenn die Banken kein Interesse daran haben, ihre Daten an einer zentralen Stelle sauber gepflegt zu sehen (das Argument ist immer "wir schreiben doch die richtigen Daten in den Brief rein, den die Nutzer bei der Registrierung be- kommen!"), fällt diese eigentlich sehr schöne Informationsquelle schon mal weg. Und sowas von Nutzern pflegen zu lassen ist auch schwierig. Ein "kleiner Personenkreis" hat das Problem, dass er nur mit sehr hohem Aufwand von allen Banken immer die richtigen Daten zusammen- sammelt (zumal bei vielen auch einfach "probiert" werden muss, wenn man nicht schon weiß, wie's richtig geht). Wenn man den Personenkreis vergrößert, so dass die Wahrscheinlich- keit steigt, dass auch von jeder Bank wenigstens ein Nutzer dabei ist, der weiß wie's geht, steigt auch die Gefahr von falschen / gefälschten Einträgen. > Langfristiges Ziel wäre die Schaffung eines defacto Standards. Das "InfoPoint-Protokoll" ;-) > Dann hätten die Banken ein begründetes Interesse an der Richtigkeit ihres > Eintrages, da sie hierdurch ihren Supportaufwand verringern könnten > und könnten die Pflege ihres Datensatzes selber übernehmen. Das halte ich wie gesagt für nicht sehr realistisch. So wie ich das sehe ist das Online-Banking für viele Banken eher ein Klotz am Bein als eine Möglichkeit, Geld zu verdienen. Im Web-Banking mag das ja vllt. noch gehen, aber bei HBCI kann man ja nicht mal Werbung schalten - und auch sonst ist die Bereitstellung eines HBCI-Zugangs etwas, was man halt machen "muss" (weil die anderen es auch machen), aber es bringt keine Einnahmequellen... Darum wird dieses Thema wohl oft sehr stiefmütterlich behandelt (mach Dir mal den Spaß und frag am Schalter der Bank Deiner Wahl (TM) nach, woher man den Fingerprint für die Überprüfung des SSL-Zertifikates bekommt. :-) Der erste Versuch mit dem InfoPoint-Server war ja der, dass ich versuchen wollte, zunächst Daten zu SAMMELN (was aber wohl ein Fehlschlag war). Vllt. sollte ich das Pferd von hinten aufzäumen: wenn ich zunächst die aktuelle blz.properties statisch im InfoPoint-Server hinterlege und ein API für die ABFRAGE dieser Daten schaffe, so dass Anwendungen schon mal die Einrichtung von HBCI-Zugängen bzw. die Änderung von Zugangsdaten unterstützen könnten..... Wenn diese Quasi-Datenbank noch mehr Anwender findet, könnte man vllt. nach und nach Protokolle für das Aktualisieren dieser Daten zur Verfügung stellen. Mal schauen wo das noch so hinführt... Grüße -stefan- |
|
From: Jan B. <ja...@mu...> - 2009-04-29 14:19:48
|
On 29.04.2009, at 15:34, HBCI4Java (Stefan Palme) wrote: > Solche "Faulheit" wäre aber durch keine Software der Welt zu > unterbinden. Denn auch WENN der Nutzer den Zettel einmal auf dem > Tisch hat, könnte er ja sagen "20 öde Zahlen-/Buchstaben- > Kombinationen zu vergleichen ist mir jetzt zu anstrengend - wird > schon passen"... Na ja, wie so oft kann man auch hier den Regler zwischen "sicher" und "bequem" ganz bis zum Anschlag schieben. Dem User nämlich den Fingerprint gar nicht anzeigen sondern ihn auffordern, ihn einzugeben und bei Nicht-Übereinstimmung die Arbeit verweigern. Sicher aber maximal unbequem. J |
|
From: Olaf W. <hbc...@wi...> - 2009-04-29 14:15:59
|
Hi, > Desweiteren könnte eine Anwendung ja im Falle der Erst-Initialisierung > eines Zugangs den Nutzer auffordern, die URL sowie das Zertifikat einmal > manuell zu prüfen und zu bestätigen (ich glaube, bei Hibiscus wird das > im Moment sogar so gemacht - selbst wenn das SSL-Zertifikat vertrauens- > würdig ist). Ja. Das liegt aber implizit einfach daran, dass Jameica eine eigene TrustManager-Implementierung und damit auch einen eigenen Trust-Store nutzt. Und dieser Trust-Store ist halt anfangs erstmal leer. Damit vertraut Jameica erstmal niemandem - auch nicht den cacerts der JVM ;) Gruss Olaf |
|
From: Jan B. <ja...@mu...> - 2009-04-29 14:09:14
|
Hi, ja, Michaels Sicherheitsbedenken sind sehr angebracht. Vielleicht könnten wir aber trotzdem etwas tun, um das Einrichten eines HBCI-Accounts mittels zentraler Datensammlung zu erleichtern. Die Banken haben auf ihren Hilfeseiten ja gerne für jeden populären HBCI-Client getrennt aufgeführt, wie der für ihr HBCI-Interface zu konfigurieren ist. "Tragen Sie in das Feld "Kundennummer" Ihre Online- Banking-Zugangsnummer ein und in das Feld "Passwort" Ihre 6-stellige Geheimzahl" etc. Es wäre schon hilfreich, wenn man diese simplen Informationen maschinenlesbar irgendwo abrufen könnte. Alleine schon, um Eingabefelder zu präsentieren, deren Beschriftung der Login-Seite des Web-Bankings entspricht, bzw. dem Informationsbrief der Bank. Das wäre also - ein Mapping der hbci4java-internen Bezeichnung auf die Nomenklatur der jeweiligen Bank. - etwaige Post- oder Prefixe die bei einzelnen Felder davor oder dahinter gehängt werden müssen (ist das überhaupt relevant?) - die von Michael als unbedenklich eingestuften HBCI-Parameter: Port, HBCI Version, Protokoll - die unterstützten Geschäftsvorfällen wären jetzt nicht meine Priorität, da sie zum Einrichten des Accounts nicht nötig sind und im Anschluss dann eh abrufbar sind. Da eine automatische, anonyme Pflege dieser Daten eher problematisch ist (s. Michaels Mail) würde man diese Datensammlung vielleicht eher als eine Art WIki mit begrenztem Zugriff organisieren. Sprich, eine kleine Gruppe von vertrauenswürdigen Personen kümmert sich um die Updates. Ist das realistisch? Finden sich hier auf der Liste Menschen, die ein Interesse an einer gemeinsamen Anstrengung in dieser Richtung haben? Langfristiges Ziel wäre die Schaffung eines defacto Standards. Dann hätten die Banken ein begründetes Interesse an der Richtigkeit ihres Eintrages, da sie hierdurch ihren Supportaufwand verringern könnten und könnten die Pflege ihres Datensatzes selber übernehmen. Grüsse! Jan On 29.04.2009, at 14:17, mic...@fa... wrote: > Hi, > > HBCI4Java (Stefan Palme) schrieb: >> Wenn man will, kann man auch eine gute Seite daran finden: scheinbar >> sind die Online-Banking-Nutzer hinsichtlich "Sicherheit" so >> sensibilisiert, dass niemand irgendwelche Daten freiwillig >> rausrückt ;-) > > ich habe noch etwas Bauchschmerzen mit dem InfoPoint Konzept (1), da > ich > mich frage, wie man dieses Protokoll für einen Angriff auf Nutzerdaten > ausnutzen könnte. > > Funktionalität: > --------------- > a) Der InfoPoint Server soll es dem Anwender ersparen, bei der > Ersteinrichtung die korrekte Serverkonfiguration selbst eingeben > zu müssen. > b) Weiterhin soll bei einer Änderung der Bankserverkonfiguration oder > -adresse der Zugang automatisch aktualisiert werden können. > > Sicherheit: > ----------- > Der Bankserver verschlüsste mit SSL und verwendet dabei entweder ein > c) > vertrauenswürdiges Zertifikat oder d) ein Zertifikat, dessen > Fingerprint > dem Nutzer bekannt ist. > > Die Daten, welche der InfoPoint Server ausliefert, können durch diesen > nicht überprüft werden, da entweder der Fingerprint oder der Hostname > der Bank nicht vertrauenswürdig bekannt ist. > > Szenarien > --------- > > Da der InfoPoint die Bankdaten schlecht verifizieren kann, liefert er > potentiell manipulierte Daten aus. > > Bei der (a) Ersteinrichtung mit (d) Fingerprintsicherheit muss der > Nutzer den Fingerprint des Servers bestätigen. Dazu muss der Nutzer > den > Brief der Bank heraussuchen, in welchem ihm die Serverkonfiguration > mitgeteilt wird. > > Die Hürde, den Zettel heraus zu suchen ist viel höher, als die IP und > die Protokollversion einzugeben. Während ohne InfoPoint die > Bankmitteilung dem Nutzer eh vorlag, die Fingerprintüberprüfung also > eine niedrige Hürde darstellte, wird nun die Mitteilung nur zur > Fingerprintüberprüfung benötigt und hat daher eine wesentlich höhere > Hürde. Gleichzeitig kann dem Nutzer gezielt eine geänderte Server-IP > untergejubelt werden, sodass in Verbindung mit PIN Authentifizierung > der Angreifer nun die PIN mitlesen könnte und den Traffik an die Bank > weiterleiten. > > Bei einer Aktualisierung der Bankverbindung (b) bzgl. der Server-IP > wird > sich der Fingerprint ebenfalls ändern, da das Zertifikat auch den > Hostnamen beinhaltet. Ein Angriff ist dort analog denkbar. > > Wird Ersteinrichtung mit vertrauenswürdig signierten Zertifikaten > verwendet, kann sich der Angreifer eine Domain sichern und dort einen > HBCI Server aufsetzen. Da die Zuordnung Host - Bank nicht überprüft > werden kann, muss die Anwendung auf die Zuordnung Host - Servername > vertrauen, welche aufgrund der freien Wählbarkeit des Domainnamens des > Angreifers jedoch keinen Schutz darstellt. > > Dieses Problem stellt sich auf bei einer Aktualisierung des > Bankzugangs. > > Angrenzung bestehende Lösung: verifizierte Datenbank > ----------------------------------------------------- > > In einer persönlich gepflegten und überprüften Datenbank tritt dieses > nicht so stark auf, da die Anwendung die Identität des InfoPoint > Servers > überprüfen kann und somit auch den dort hinterlegten Daten vertrauen > kann. Es ist dem Angreifer nicht mehr so leicht möglich, den > vertrauenswürdigen Ersteller der Datenbank zu manipulieren. > > Kontra > ------ > > Also Kontra-Argument ist mir bewusst, dass hier versucht wird, ein > soziales Problem technisch zu lösen. Gleichzeitig denke ich aber, dass > bei einer erfolgreichen Lösung des sozialen Problems der Vorteil der > technischen Lösung gering ist: bei PIN/TAN muss weiterhin der > Fingerprint überprüft werden und bei der Verwendung einer Chipkarte > können die Serverdaten auch auf der Chipkarte gespeichert werden. > > Problemlos verwendbar ist der InfoPoint Server aus meiner Sicht zur > Abfrage von Port, HBCI Version, Protokoll und unterstützten > Geschäftsvorfällen, da dadurch das Vertrauen in die Serveridentität > nicht verändert wird. Nicht problematisch ist außerdem die Verwendung > von SSL Client Zertifikaten (Chipkarte), da hier ebenfalls kein > MAN-in-the-Middle möglich ist. > > Vermeidbar wäre der o.g. Angriff, indem die Bankserverzertifikate > explizit eine Bankleitzahl angeben würden, welche vom Aussteller > überprüft wurde. Der Hostname oder die IP des Servers ist dagegen - > anders als bei normalen Surf-Anwendungen - weniger relevant. > > Anonymität bei der Erfassung > ---------------------------- > > Der InfoPoint-Server hat notwendiger Weise die Möglichkeit, zu > erfassen, > welche IP wann welche BPD abruft oder abliefert. Er kann daher dazu > benutzt werden, Rückschlüsse darauf ziehen, wer Kunde bei welcher Bank > ist. Allerdings ist dieses Datum selten geheim und kann nicht > automatisiert Personen zugeordnet werden. Im Einzelfall kann die > Funktion außerdem ungenutzt bleiben. > > Lastverteilung > -------------- > > Eine Anwendung sollte nicht zu oft den InfoPoint abfragen, da dieser > sonst potentiell überlastet wird. > Bei einer Änderung von automatisch erfassbaren Bankparametern wie der > BPD könnte es ebenfalls zu einem Ansturm auf den InfoPoint kommen. > > Diesem könnte man u.A. auf folgenden Wegen begegenen: > - Der InfoPoint Server kennt die Häufigkeit der Abrufe / Uploads > für eine Bankleitzahl. Er kann der Anwendung also vorgeben, mit > welcher Wahrscheinlichkeit sie eine Änderung an ihn melden soll. > Diese Wahrscheinlichkeit kann vom Server mit der Zeit dynamisch > angepasst werden. > - Aktualisierungen nur hochgeladen, wenn die Anwendung die > Bankdaten gerade vom InfoPoint aktualisiert hat. > Der Server wird also nur so viele Aktualisierungen erhalten, > wie Nutzer quasi zeitgleich mit der Bank gearbeitet haben > > Außerdem könnte der Server einen Zeitstempel mit ausliefern, damit die > Anwendung überprüfen kann, welche Aktualisierung nun aktueller ist. > > Grüße, > Michael > > (1) http://hbci4java.kapott.org/svn/hbci4java/trunk/misc/README.InfoPoint > > >> >> Aus dem Grund habe ich jedenfalls auch noch weiter an dem >> System gebastelt... >> >> Grüße >> -stefan- >> >> >> >> ------------------------------------------------------------------------------ >> Register Now & Save for Velocity, the Web Performance & Operations >> Conference from O'Reilly Media. Velocity features a full day of >> expert-led, hands-on workshops and two days of sessions from industry >> leaders in dedicated Performance & Operations tracks. Use code >> vel09scf >> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf >> _______________________________________________ >> Hbci4java-help mailing list >> Hbc...@li... >> https://lists.sourceforge.net/lists/listinfo/hbci4java-help > > > > ------------------------------------------------------------------------------ > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code > vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf_______________________________________________ > Hbci4java-help mailing list > Hbc...@li... > https://lists.sourceforge.net/lists/listinfo/hbci4java-help |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-29 14:01:34
|
Hallo Michael, danke für Dein umfrangreiches Feedback. Ich picke mal ein paar Punkte heraus, auf die ich spontan antworten möchte... ;-) > Sicherheit: > ----------- > Der Bankserver verschlüsste mit SSL und verwendet dabei entweder ein c) > vertrauenswürdiges Zertifikat oder d) ein Zertifikat, dessen Fingerprint > dem Nutzer bekannt ist. > > Die Daten, welche der InfoPoint Server ausliefert, können durch diesen > nicht überprüft werden, da entweder der Fingerprint oder der Hostname > der Bank nicht vertrauenswürdig bekannt ist. Soweit ACK. Eine URL https://www.hora-obscura.de/pintan/PinTanServlet für die BLZ 80007777 würde vom InfoPoint-Server als völlig valide und OK angesehen werden, weil das dafür verwendete SSL-Zertifikat tatsächlich validiert werden kann - der InfoPoint-Server weiß nur nicht, dass "hora-obscura" keine "richtige" Bank ist. > Da der InfoPoint die Bankdaten schlecht verifizieren kann, liefert er > potentiell manipulierte Daten aus. Theoretisch möglich. Du sprichst da schon dem Fall der "völligen Auto- matisierung" auf InfoPoint-Server-Seite. Ich hatte mir gedacht, dass der InfoPoint-Server aber frühestens dann neue Daten für eine bestimmte BLZ meldet, wenn a) diese von mehreren verschiedenen Clients als "funktionierend" an den InfoPoint-Server gemeldet wurden, und b) im selben Zeitraum auch keine Infos mehr mit den alten Daten reinkommen. Punkt a) könnte man als Angreifer natürlich leicht faken - einfach massenweise gefakte InfoPoint-Server-Infos an den Server senden, und zwar von vielen Rechnern aus. Aber um auch Punkt b) zu fälschen, müsste sich ein Angreifer schon ganz schön anstrengen ;-) [das funktioniert natürlich nur, wenn es keine oder nur eine kurze Übergangsphase gibt, bei der BEIDE Urls funktionieren...] Außerdem sollte diese Entscheidung, neue Daten für eine BLZ zu melden, auch nicht sofort geschehen, sondern erst, wenn dieser Zustand über einen gewissen Zeitraum anhält (also wenn z.B. wenigstens zwei Tage lang nur noch Infos mit einer neuen URL "URL2" reinkommen, aber keine Infos mit der alten URL "URL1" mehr... Beim Ausbalancieren dieses Zeitfensters muss man natürlich Effizient (kurzes Fenster) und Sicherheit (langes Fenster) gegeneinander abwägen... > Die Hürde, den Zettel heraus zu suchen ist viel höher, als die IP und > die Protokollversion einzugeben. Selbst wenn der Anwender die IP manuell eingibt, und das Zertifikat dem Fall (d) entsprechen soll (also nicht automatisch, sondern nur manuell über den Fingerprint verifizierbar), muss der Anwender diese Verifizierung tun - denn wer garantiert denn, dass ein Angreifer nicht den kompletten Traffic für die richtige IP an einen badboy-Server um- leitet... > Während ohne InfoPoint die > Bankmitteilung dem Nutzer eh vorlag, die Fingerprintüberprüfung also > eine niedrige Hürde darstellte, wird nun die Mitteilung nur zur > Fingerprintüberprüfung benötigt und hat daher eine wesentlich höhere > Hürde. Gleichzeitig kann dem Nutzer gezielt eine geänderte Server-IP > untergejubelt werden, sodass in Verbindung mit PIN Authentifizierung > der Angreifer nun die PIN mitlesen könnte und den Traffik an die Bank > weiterleiten. Verstehe ich Dich richtig - Du willst hier eher auf ein "psychisches" Problem hinaus? Wenn der Nutzer den Bankbrief rauskramen muss, um die richtige URL einzugeben, macht er halt die Fingerprint-Überprüfung gleich mit, weil der Zettel ja eh einmal draußen ist. Wenn die Einrichtung jedoch vollautomatisch geht, und er den Zettel NUR rauskramen muss, um diese nervige Fingerprint-Überprüfung zu machen, dann lässt er das schon eher mal sein und vertraut einfach darauf, dass das schon i.O. ist... Meinst Du das so? Solche "Faulheit" wäre aber durch keine Software der Welt zu unterbinden. Denn auch WENN der Nutzer den Zettel einmal auf dem Tisch hat, könnte er ja sagen "20 öde Zahlen-/Buchstaben- Kombinationen zu vergleichen ist mir jetzt zu anstrengend - wird schon passen"... > Bei einer Aktualisierung der Bankverbindung (b) bzgl. der Server-IP wird > sich der Fingerprint ebenfalls ändern, da das Zertifikat auch den > Hostnamen beinhaltet. Ein Angriff ist dort analog denkbar. Nein. Ein SSL-Zertifikat ist auf einen Hostnamen und nicht auf eine IP- Adresse ausgestellt. Wenn eine Bank Ihren Server auf eine andere IP- Adresse umzieht, den Hostnamen aber beibehält (also praktisch nur eine Änderung um DNS machen muss), dann ändert sich aus Sicht von HTTPS und SSL-Zertifikaten überhaupt nichts. Wenn sich auch der Hostname ändert, braucht es natürlich auch ein neues SSL-Zertifikat, welches validiert werden muss. Die Validierung mit Fingerprint wäre dabei sicherer, weil der Nutzer gezwungen wird, mal händisch draufzugucken ob alles i.O. ist (dazu muss der Nutzer aber natürlich auch eine entsprechende Info von seiner Bank bekommen, wie der neue Fingerprint denn lauten muss). Die automatischeValidierung via "vertrauenswürdiges Zertifikat" ist da wirklich kritischer, weil ein Angreifer tatsächlich eine beliebige eigene Domain mit einem gültigen SSL-Zertifikat versehen kann und eine URL innerhalb dieser Domains als "PIN/TAN-URL" ausgeben könnte. In dieser Hinsicht stimme ich Dir voll und ganz zu. Das ganze kann aber relativ einfach gelöst werden ("gelöst" immer in dem Sinne, dass es automatisierte, 100%ige Sicherheit nicht geben kann - die Anwendung und der Anwender müssen schon ein bisschen mitspielen): Zum einen sollte der InfoPoint-Server nur dann neue Daten für eine BLZ zurückgeben, wenn er selbst daran "glaubt", dass die echt sind (siehe oben). Desweiteren könnte eine Anwendung ja im Falle der Erst-Initialisierung eines Zugangs den Nutzer auffordern, die URL sowie das Zertifikat einmal manuell zu prüfen und zu bestätigen (ich glaube, bei Hibiscus wird das im Moment sogar so gemacht - selbst wenn das SSL-Zertifikat vertrauens- würdig ist). Und im Falle der Änderung von Daten könnte die Anwendung dem Anwender ja mitteilen, dass scheinbar neue Daten für seine Bank verfügbar sind, und er doch bitte überprüfen möchte, ob die "Sinn machen", ob das neue Zertifikat stimmt usw... > In einer persönlich gepflegten und überprüften Datenbank tritt dieses > nicht so stark auf, da die Anwendung die Identität des InfoPoint Servers > überprüfen kann und somit auch den dort hinterlegten Daten vertrauen > kann. Es ist dem Angreifer nicht mehr so leicht möglich, den > vertrauenswürdigen Ersteller der Datenbank zu manipulieren. Prinzipiell ACK - aber das Ziel des InfoPoint-Servers ist es ja, genau dieses manuellen Aufwand zu reduzieren. Wenn der InfoPoint- Server nur Sinn macht, wenn man die hinterlegte Datenbank pflegt, dann brauche ich ihn eigentlich gar nicht mehr - denn eine manuelle gepflegte "Datenbank" befindet sich bereits in der Datei blz.properties, die Teil von HBCI4Java ist (natürlich mit wenig weniger Daten als im InfoPoint-Server mal gespeichert werden sollen, es ging mir jetzt nur ums Prinzip) ;-) > Also Kontra-Argument ist mir bewusst, dass hier versucht wird, ein > soziales Problem technisch zu lösen. Nicht nur ein soziales, sondern auch ein technisches Henne-Ei-Problem. Ein Anwender, der völlig auf der grünen Wiese anfängt, weiß z.B. nicht, welche HBCI-Versionen er verwenden kann, welche "Filter" (laut HBCI-Standard gibt es da mehrere Möglichkeiten, die in er Praxis bloss nicht benutzt werden) usw. Diese Daten erfährt er zwar, indem er die BPD von der Bank abholt. Aber genau dafür bräuchte er die Daten ja schon... > Gleichzeitig denke ich aber, dass > bei einer erfolgreichen Lösung des sozialen Problems der Vorteil der > technischen Lösung gering ist: bei PIN/TAN muss weiterhin der > Fingerprint überprüft werden und bei der Verwendung einer Chipkarte > können die Serverdaten auch auf der Chipkarte gespeichert werden. ACK. > Problemlos verwendbar ist der InfoPoint Server aus meiner Sicht zur > Abfrage von Port, HBCI Version, Protokoll und unterstützten > Geschäftsvorfällen, da dadurch das Vertrauen in die Serveridentität > nicht verändert wird. ACK. > Vermeidbar wäre der o.g. Angriff, indem die Bankserverzertifikate > explizit eine Bankleitzahl angeben würden, welche vom Aussteller > überprüft wurde. Der Hostname oder die IP des Servers ist dagegen - > anders als bei normalen Surf-Anwendungen - weniger relevant. Stimmt, aber da begeben wir uns leider in die wünsch-dir-was-Welt - dieses Feature ist leider nicht in irgendeiner Weise standardisiert vorgesehen :) > Der InfoPoint-Server hat notwendiger Weise die Möglichkeit, zu erfassen, > welche IP wann welche BPD abruft oder abliefert. Er kann daher dazu > benutzt werden, Rückschlüsse darauf ziehen, wer Kunde bei welcher Bank > ist. Allerdings ist dieses Datum selten geheim und kann nicht > automatisiert Personen zugeordnet werden. Im Einzelfall kann die > Funktion außerdem ungenutzt bleiben. Im Prinzip könnte man damit "IP-basierte Profile" erstellen, soweit richtig. Einen Rückschluss auf einen konkreten Kunden kann man damit jedoch nicht ziehen, denn es werden nur die sowieso öffentlich verfügbaren Daten an den InfoPoint-Server übermittelt. > Eine Anwendung sollte nicht zu oft den InfoPoint abfragen, da dieser > sonst potentiell überlastet wird. > ... Die Performance-Geschichte habe ich absichtlich erst mal noch gar nicht betrachtet, um die Komplexität des Konzepts und der Implementierung nicht gleich zu hoch zu treiben. Momentan ist der InfoPoint-Server ja eigentlich auch noch in einer Proof-Of-Concept-Phase, wo es nur darum geht, zu sehen, ob sowas prinzipiell machbar ist und sinnvoll genutzt werden könnte... Letztendlich sehe ich den InfoPoint-Server also so eine Art "DNS für HBCI-Server" - also mit ähnlichen Problemen wie das DNS-System (Fälschung von DNS-Einträgen zum Zwecke der "Umleitung" von Traffic) und ähnlichen Anforderungen an die Anwender (auch wenn ich https://www.meine-bank.de manuell im Browser eingebe, sollte ich mal aufs Zertifikat gucken, um sicher zu sein, dass ich wirklich da bin wo ich hin wollte) usw... Danke jedenfalls für den Input! Grüße -stefan- |
|
From: <mic...@fa...> - 2009-04-29 12:30:28
|
Hi, HBCI4Java (Stefan Palme) schrieb: > Wenn man will, kann man auch eine gute Seite daran finden: scheinbar > sind die Online-Banking-Nutzer hinsichtlich "Sicherheit" so > sensibilisiert, dass niemand irgendwelche Daten freiwillig rausrückt ;-) ich habe noch etwas Bauchschmerzen mit dem InfoPoint Konzept (1), da ich mich frage, wie man dieses Protokoll für einen Angriff auf Nutzerdaten ausnutzen könnte. Funktionalität: --------------- a) Der InfoPoint Server soll es dem Anwender ersparen, bei der Ersteinrichtung die korrekte Serverkonfiguration selbst eingeben zu müssen. b) Weiterhin soll bei einer Änderung der Bankserverkonfiguration oder -adresse der Zugang automatisch aktualisiert werden können. Sicherheit: ----------- Der Bankserver verschlüsste mit SSL und verwendet dabei entweder ein c) vertrauenswürdiges Zertifikat oder d) ein Zertifikat, dessen Fingerprint dem Nutzer bekannt ist. Die Daten, welche der InfoPoint Server ausliefert, können durch diesen nicht überprüft werden, da entweder der Fingerprint oder der Hostname der Bank nicht vertrauenswürdig bekannt ist. Szenarien --------- Da der InfoPoint die Bankdaten schlecht verifizieren kann, liefert er potentiell manipulierte Daten aus. Bei der (a) Ersteinrichtung mit (d) Fingerprintsicherheit muss der Nutzer den Fingerprint des Servers bestätigen. Dazu muss der Nutzer den Brief der Bank heraussuchen, in welchem ihm die Serverkonfiguration mitgeteilt wird. Die Hürde, den Zettel heraus zu suchen ist viel höher, als die IP und die Protokollversion einzugeben. Während ohne InfoPoint die Bankmitteilung dem Nutzer eh vorlag, die Fingerprintüberprüfung also eine niedrige Hürde darstellte, wird nun die Mitteilung nur zur Fingerprintüberprüfung benötigt und hat daher eine wesentlich höhere Hürde. Gleichzeitig kann dem Nutzer gezielt eine geänderte Server-IP untergejubelt werden, sodass in Verbindung mit PIN Authentifizierung der Angreifer nun die PIN mitlesen könnte und den Traffik an die Bank weiterleiten. Bei einer Aktualisierung der Bankverbindung (b) bzgl. der Server-IP wird sich der Fingerprint ebenfalls ändern, da das Zertifikat auch den Hostnamen beinhaltet. Ein Angriff ist dort analog denkbar. Wird Ersteinrichtung mit vertrauenswürdig signierten Zertifikaten verwendet, kann sich der Angreifer eine Domain sichern und dort einen HBCI Server aufsetzen. Da die Zuordnung Host - Bank nicht überprüft werden kann, muss die Anwendung auf die Zuordnung Host - Servername vertrauen, welche aufgrund der freien Wählbarkeit des Domainnamens des Angreifers jedoch keinen Schutz darstellt. Dieses Problem stellt sich auf bei einer Aktualisierung des Bankzugangs. Angrenzung bestehende Lösung: verifizierte Datenbank ----------------------------------------------------- In einer persönlich gepflegten und überprüften Datenbank tritt dieses nicht so stark auf, da die Anwendung die Identität des InfoPoint Servers überprüfen kann und somit auch den dort hinterlegten Daten vertrauen kann. Es ist dem Angreifer nicht mehr so leicht möglich, den vertrauenswürdigen Ersteller der Datenbank zu manipulieren. Kontra ------ Also Kontra-Argument ist mir bewusst, dass hier versucht wird, ein soziales Problem technisch zu lösen. Gleichzeitig denke ich aber, dass bei einer erfolgreichen Lösung des sozialen Problems der Vorteil der technischen Lösung gering ist: bei PIN/TAN muss weiterhin der Fingerprint überprüft werden und bei der Verwendung einer Chipkarte können die Serverdaten auch auf der Chipkarte gespeichert werden. Problemlos verwendbar ist der InfoPoint Server aus meiner Sicht zur Abfrage von Port, HBCI Version, Protokoll und unterstützten Geschäftsvorfällen, da dadurch das Vertrauen in die Serveridentität nicht verändert wird. Nicht problematisch ist außerdem die Verwendung von SSL Client Zertifikaten (Chipkarte), da hier ebenfalls kein MAN-in-the-Middle möglich ist. Vermeidbar wäre der o.g. Angriff, indem die Bankserverzertifikate explizit eine Bankleitzahl angeben würden, welche vom Aussteller überprüft wurde. Der Hostname oder die IP des Servers ist dagegen - anders als bei normalen Surf-Anwendungen - weniger relevant. Anonymität bei der Erfassung ---------------------------- Der InfoPoint-Server hat notwendiger Weise die Möglichkeit, zu erfassen, welche IP wann welche BPD abruft oder abliefert. Er kann daher dazu benutzt werden, Rückschlüsse darauf ziehen, wer Kunde bei welcher Bank ist. Allerdings ist dieses Datum selten geheim und kann nicht automatisiert Personen zugeordnet werden. Im Einzelfall kann die Funktion außerdem ungenutzt bleiben. Lastverteilung -------------- Eine Anwendung sollte nicht zu oft den InfoPoint abfragen, da dieser sonst potentiell überlastet wird. Bei einer Änderung von automatisch erfassbaren Bankparametern wie der BPD könnte es ebenfalls zu einem Ansturm auf den InfoPoint kommen. Diesem könnte man u.A. auf folgenden Wegen begegenen: - Der InfoPoint Server kennt die Häufigkeit der Abrufe / Uploads für eine Bankleitzahl. Er kann der Anwendung also vorgeben, mit welcher Wahrscheinlichkeit sie eine Änderung an ihn melden soll. Diese Wahrscheinlichkeit kann vom Server mit der Zeit dynamisch angepasst werden. - Aktualisierungen nur hochgeladen, wenn die Anwendung die Bankdaten gerade vom InfoPoint aktualisiert hat. Der Server wird also nur so viele Aktualisierungen erhalten, wie Nutzer quasi zeitgleich mit der Bank gearbeitet haben Außerdem könnte der Server einen Zeitstempel mit ausliefern, damit die Anwendung überprüfen kann, welche Aktualisierung nun aktueller ist. Grüße, Michael (1) http://hbci4java.kapott.org/svn/hbci4java/trunk/misc/README.InfoPoint > > Aus dem Grund habe ich jedenfalls auch noch weiter an dem > System gebastelt... > > Grüße > -stefan- > > > > ------------------------------------------------------------------------------ > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > _______________________________________________ > Hbci4java-help mailing list > Hbc...@li... > https://lists.sourceforge.net/lists/listinfo/hbci4java-help |
|
From: Olaf W. <hbc...@wi...> - 2009-04-29 11:27:00
|
Hi, > Leider habe ich bisher außer meinen eigenen Daten keine Daten > bekommen. Da dieses Feature in HBCI4Java per default deaktiviert > ist, werden das wohl die wenigsten aktiv anschalten. In Hibiscus > gibt es wohl ein entsprechendes User-Interface, um dieses Feature > anzuschalten - aber trotzdem habe ich auch von Hibiscus-Nutzern > noch keine Daten bekommen... :-( Ich muss zugeben, dass der Code hierfuer bereits in Hibiscus drin ist, der Callback, mit dem HBCI4Java die Genehmigung zum Senden der Daten holt, jedoch noch mit "Nein" beantwortet wird. Grund: Ich weiss noch nicht, wie ich dem User die zu sendenden Daten so anzeigen soll, dass sein erster Gedanke nicht "Haa! Hibiscus telefoniert nach Hause!" ist ;) Gruss Olaf |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-29 11:08:27
|
Hallo, > ich finde die Idee des InfoPoint-Servers großartig! Wie weit bist Du > denn mit der Abfrageseite? Kannst Du Unterstützung gebrauchen? > Und besteht schon eine nennenswerte Datensammlung? Leider habe ich bisher außer meinen eigenen Daten keine Daten bekommen. Da dieses Feature in HBCI4Java per default deaktiviert ist, werden das wohl die wenigsten aktiv anschalten. In Hibiscus gibt es wohl ein entsprechendes User-Interface, um dieses Feature anzuschalten - aber trotzdem habe ich auch von Hibiscus-Nutzern noch keine Daten bekommen... :-( Wenn man will, kann man auch eine gute Seite daran finden: scheinbar sind die Online-Banking-Nutzer hinsichtlich "Sicherheit" so sensibilisiert, dass niemand irgendwelche Daten freiwillig rausrückt ;-) Aus dem Grund habe ich jedenfalls auch noch weiter an dem System gebastelt... Grüße -stefan- |
|
From: Jan B. <ja...@mu...> - 2009-04-29 09:33:11
|
Hallo Stefan,
ich finde die Idee des InfoPoint-Servers großartig! Wie weit bist Du
denn mit der Abfrageseite? Kannst Du Unterstützung gebrauchen?
Und besteht schon eine nennenswerte Datensammlung? Ich könnte mir
vorstellen, dass die Bereitschaft, Daten einzureichen erheblich größer
sein wird, wenn sichergestellt ist, dass man sie auch wieder heraus
bekommt :)
Ein einfaches HTTP GET auf die BLZ, das dann einfach genau das XML
zurück gibt, dass eingeschickt wurde, wäre ja schon ein Anfang!
Man könnte vielleicht noch ein ?format=raw anhängen, um zukünftig ein
besser aufbereitetes Format ohne Kompatibilitätsprobleme unterstützen
zu können.
Viele Grüsse!
Jan
On 29.04.2009, at 09:37, HBCI4Java (Stefan Palme) wrote:
>
>> Was müsste ich also am Code ändern damit die entsprechenden
>> Log-Meldungen kommen? Alles was commons logging findet bis
>> runter zu DEBUG wird ausgegeben.
>
> Wie kommst Du auf commons logging? HBCI4Java-2 verwendet
> kein commons logging.
>
> Du verwendest HBCIUtils.setParam("log.loglevel.default", "5").
> Die Log-Ausgaben erhälst Du über die Methode log(...) des
> registrierten Callback-Objektes (diese hast Du ja offensichtlich
> schon durch eine eigene Implementierung überschrieben, denn
> Deine Logausgaben haben ein mir unbekanntes Format).
>
>
> -stefan-
>
>
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code
> vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Hbci4java-help mailing list
> Hbc...@li...
> https://lists.sourceforge.net/lists/listinfo/hbci4java-help
|
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-29 07:37:17
|
> Was müsste ich also am Code ändern damit die entsprechenden
> Log-Meldungen kommen? Alles was commons logging findet bis
> runter zu DEBUG wird ausgegeben.
Wie kommst Du auf commons logging? HBCI4Java-2 verwendet
kein commons logging.
Du verwendest HBCIUtils.setParam("log.loglevel.default", "5").
Die Log-Ausgaben erhälst Du über die Methode log(...) des
registrierten Callback-Objektes (diese hast Du ja offensichtlich
schon durch eine eigene Implementierung überschrieben, denn
Deine Logausgaben haben ein mir unbekanntes Format).
-stefan-
|
|
From: Marcus W. <Ma...@Wo...> - 2009-04-29 07:22:53
|
On Wed, 29 Apr 2009 08:40:02 +0200, "HBCI4Java (Stefan Palme)" <hbc...@ka...> wrote: > Außerdem ist es kein Level-5-Log - bei einem Level-5-Log würde > man auch die Klartext-HBCI-Nachrichten sehen können - und die > brauche ich, um zu sehen, wie die ursprünglich von der Bank > gelieferten MT940-Daten aussehen. Was müsste ich also am Code ändern damit die entsprechenden Log-Meldungen kommen? Alles was commons logging findet bis runter zu DEBUG wird ausgegeben. > Evtl. kannst Du diese ja auch einfach mal selbst ausgeben: > > ... > HBCIExecStatus status=hbci.execute(); > HBCIJobResult result=job.getJobResult(); > result.getResultData().list(new PrintWriter(System.out)); System.out gibt es hier leider nicht. Nur Logging, keine Konsole (Windows). Aber ich kann man sehen, dass ich das auf der Zugfahrt heute Nachmittag in eine Datei schreibe und dir schicke. Marcus |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-29 06:40:09
|
Hallo, On Wed, 2009-04-29 at 06:23 +0200, Marcus Wolschon wrote: > Update: Der Saldo in BTag.start ist gleich dem in BTag.end. > Kein Wunder, das er da massiv aus dem Tritt kommt. Der Saldo BTag.end wird direkt aus den von der Bank gelieferten Daten extrahiert. Es ist also sehr wahrscheinlich, dass die Bank hier einfach falsche Daten liefert. Dein geliefertes Log ist zwar schön lang (und schlecht lesbar), aber die relevanten Daten, die man zur Klärungs dieses Problems benötigt, enthält es nicht. Einerseits ist dort nicht zu sehen, wie der GV "Kontoumsätze abrufen" überhaupt ausgeführt wird (das Log endet nach der Dialog-Initialisierung). Außerdem ist es kein Level-5-Log - bei einem Level-5-Log würde man auch die Klartext-HBCI-Nachrichten sehen können - und die brauche ich, um zu sehen, wie die ursprünglich von der Bank gelieferten MT940-Daten aussehen. Evtl. kannst Du diese ja auch einfach mal selbst ausgeben: ... HBCIExecStatus status=hbci.execute(); HBCIJobResult result=job.getJobResult(); result.getResultData().list(new PrintWriter(System.out)); Das Durcheinander mit der Rechnerei erklärt das allerdings NICHT. Denn der Endsaldo (also BTag.end) wird überhaupt nicht weiter verwendet. Die Saldo-Berechnung zu einer Buchung verwendet nur BTag.start als Anfangswert für einen Tag und addiert dort die Beträge der jeweiligen Buchungen drauf. Wenn also BTag.start richtig ist und die Buchungsbeträge selbst auch richtig sind, dann sollten auch die Saldi, die an den Buchungen dran stehen, richtig sein - völlig unabhängig davon, dass in BTag.end evtl. Schrott steht. -stefan- |
|
From: Marcus W. <Ma...@Wo...> - 2009-04-29 04:23:39
|
Update: Der Saldo in BTag.start ist gleich dem in BTag.end. Kein Wunder, das er da massiv aus dem Tritt kommt. Marcus |
|
From: Marcus W. <Ma...@Wo...> - 2009-04-29 04:20:09
|
Update: Mit org.kapott.hbci.status.HBCIExecStatus status = handler.execute(); org.kapott.hbci.GV_Result.HBCIJobResult result = job.getJobResult(); BTag[] dataPerDay = ((org.kapott.hbci.GV_Result.GVRKUms)result).getDataPerDay(); bekomme ich bei der Comdirect FAST die richtigen Saldi. Fast weil BTag.end den Endsaldo des VORTAGES = das was in BTag.start sein sollte enthält. Um zu schauen was in BTag.start steht ist meine Verbindung grad zu schlecht. Marcus |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-28 17:55:11
|
> HBCI error code: 9050:Die Nachricht enthält Fehler. > HBCI error code: 9010:Benutzer unbekannt. > HBCI error code: 9340:Ungueltige Auftragsnachricht: Ungueltige > Signatur. > HBCI error code: 9000:Weitere Verarbeitung des Auftrags aufgrund > interner Probleme fehlgeschlagen. > (5: Synch.Sync) Das und schon eher auftretende Fehler der Art > HBCI error code: 9010:Die angegebene Bankreferenz ist nicht gueltig. deuten darauf hin, dass irgendetwas falsch konfiguriert ist. Richtige BLZ, richtige Benutzerkennung, richtige Pin verwendet? Diese Fehlermeldungen werden jedenfalls nicht von HBCI4Java, sondern von der Bank generiert. HBCI4Java bricht beim Empfangen solcher Fehlermeldungen die Verarbeitung mit der von Dir beobachteten Exception ab. Grüße -stefan- |
23 messages has been excluded from this view by a project administrator.
