Thread: Re: [Hbci4java-help] InfoPoint-Server-Abfrage (Page 2)
Brought to you by:
kleiner77
Menu
▾
▴
hbci4java-help
|
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: 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: 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: 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: 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: 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: 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X