Thread: Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine
Brought to you by:
kleiner77
Menu
▾
▴
hbci4java-help
|
From: Rolf V. <ro...@we...> - 2009-04-26 20:58:38
|
> -----Ursprüngliche Nachricht----- > Von: "Marcus Wolschon" <Ma...@Wo...> > Gesendet: 26.04.09 21:15:38 > An: hbc...@li... > Betreff: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine > Hello, > > I'm getting my transactions just fine but the saldo-values > I get in the org.kapott.hbci.GV_Result.GVRKUms.UmsLine > instances are just crazy. > Sometimes they are right but sometimes they are lie > -8094 eur while the account actually was way > 0 and > has never ever been below zero. > > Did anyone else get this? > What is the best strategy to trace this issue to > it`s source? > btw, my bank is Comdirect Bank AG. Hallo, (Zunächst: Ich antworte einfach mal auf deutsch, weil das auf dieser Mailingliste so üblich ist, und es ja laut deiner Homepage sowieso deine Muttersprache ist, ich hoffe, damit ist jeder einverstanden.) Zum eigentlichen Problem: Ich würde testweise mal ein anderes Programm einsetzen, aber den gleichen HBCI-Zugang (gleiches Konto, gleiche Zugangsdaten etc.). Dann dürfe sich schnell zeigen, ob die Daten ganz einfach falsch von der Bank geliefert werden, oder ob HBCI4Java die Bankdaten nur falsch auswertet. Spontan würden mir die Subsembly FinTS Tools einfallen, die gibt es auf http://fints-api.de/fintstools.html, und die sind laut der Homepage für private Zwecke kostenlos (wenn auch nicht im Quellcode verfügbar). Man muss zunächst mit dem FinAdmin den Zugang einrichten, und kann dann z. B. mit dem FinPad auf das Konto zugreifen. Hierbei wird auch ein Trace erstellt, der die Kommunikation mit der Bank auf niedriger Abstraktionsebene beschreibt. Falls die Software die gleichen Werte liefert, wie HBCI4Java, kann es sich eigentlich nur um einen Fehler der Bank handeln, in dem Fall müsste man halt Kontakt zu dieser aufnehmen, und hoffen, dass die Bank sich nicht querstellt. Falls die Software alles richtig abrufen sollte, hat HBCI4Java evtl. einen Bug. > Marcus Rolf |
|
From: Rolf V. <ro...@we...> - 2009-04-29 21:46:55
|
> -----Ursprüngliche Nachricht----- > Von: "Marcus Wolschon" <Ma...@Wo...> > Gesendet: 28.04.09 09:29:19 > An: "HBCI4Java (Stefan Palme)" <hbc...@ka...> > CC: hbci4java-help <hbc...@li...> > Betreff: Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine > On Tue, 28 Apr 2009 09:05:05 +0200, "HBCI4Java (Stefan Palme)" > <hbc...@ka...> wrote: > >> FinPad zeigt nur ein Endsaldo an, unter "Kontoumsätze" sind keine > >> Saldi am Ende eines Tages zu sehen. Wo müssten diese auftauchen? > > > > Kann ich nicht sagen, ich kenne FinPad nicht. > > Ich dachte auch eher an eine Antwort von Rolf. ;) Hmm, so gut kenne ich die Anwendung leider auch nicht, dass ich das komplett aus dem Kopf wüsste. Ich dachte, das Programm würde die nötigen Infos anzeigen, aber dann habe ich mich wohl geirrt. Aber drei Punkte würden mir spontan einfallen: - Die Anwendung ist ja nur ein Beispiel für die Verwendung der Library, daher gibt sie evtl. nicht alle Infos aus, die die Library zur Verfügung stellt. Aber da ja der Quellcode für diese Beispielprogramme mitgeliefert wird, könnte man die Ausgabe evtl. erweitern, sofern die Library die Infos geparst bereit stellt. Falls jemandem damit geholfen ist, kann ich das in den nächsten Tagen mal machen (in dem Fall einfach Bescheid sagen). Man kann die Quellen der Beispielprogramme mit dem Visual Studio, aber auch mit SharpDevelop (OpenSource) bearbeiten. Die Library selbst gibt es nicht im Quellcode, aber es gibt Doku dazu. - Man könnte mal als Startdatum und Enddatum den gleichen Tag eintragen (am besten nicht den aktuellen Tag), dann sollte man ja sehen, welchen Endsaldo man für diesen Tag bekommt. Ob der angezeigte Endsaldo direkt von der Bank stammt, oder vom Programm selbst berechnet wird, weiß ich jedoch nicht auswendig. - Man könnte sich mal das Trace anschauen, dass das Programm im Hintergrund erzeugt. Wenn die Bank einen Wert fertig errechnet liefert, sollte der ja im Trace zu lesen sein. Leider ist das Trace nicht sehr gut menschenlesbar. Eher was für Leute, die die HBCI-Spezifikation immer griffbereit haben :( Rolf |
|
From: Marcus W. <Ma...@Wo...> - 2009-04-28 14:42:08
|
Ich bekomme immer "org.kapott.hbci.exceptions.ProcessException: Fehler beim Ermitteln einer neuen System-ID" kann das mal jemand in`s Deutsche übersetzen? ;) Marcus |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-28 15:17:58
|
> Ich bekomme immer > "org.kapott.hbci.exceptions.ProcessException: Fehler beim Ermitteln > einer neuen System-ID" > > kann das mal jemand in`s Deutsche übersetzen? ;) Wenn Du einen komplettes Log (am besten Level 5) liefern kannst, ist das sicherlich möglich ;-) -stefan- |
|
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: Marcus W. <Ma...@Wo...> - 2009-04-28 17:27:06
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 HBCI4Java (Stefan Palme) schrieb: >> Ich bekomme immer "org.kapott.hbci.exceptions.ProcessException: >> Fehler beim Ermitteln einer neuen System-ID" >> >> kann das mal jemand in`s Deutsche übersetzen? ;) > > Wenn Du einen komplettes Log (am besten Level 5) liefern kannst, > ist das sicherlich möglich ;-) Verbesserungsvorschlag erstmal: Bessere Fehlermeldungen die a) ein User verstehen würde und b) genau genug sagen was kaputt ist ohne die Situation mit erhöhrem Log-Level nochmal provozieren zu müssen. (Das kann ich machen, ein normaler User aber nicht.) Marcus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkn3PDkACgkQf1hPnk3Z0cQxRACgoDNSxEIie/lYaz8mydcwFVN0 NAQAnj+n6SYn6FwN5jUUXotzMI8gh30u =B7aF -----END PGP SIGNATURE----- |
|
From: Marcus W. <Ma...@Wo...> - 2009-04-28 17:39:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 HBCI4Java (Stefan Palme) schrieb: > > Wenn Du den kompletten Exception-Trace geschickt hättest, wüsste > ich wohl eher was kaputt sein könnte. Der von Dir genannte Fehler > trat auf, als HBCI4Java versucht hat, die System-ID zu > synchronisieren. > > Das kann viele Ursachen haben: die Bank antwortete nicht, die Bank > hat mir einer Nachricht geantwortet, die HBCI4Java nicht parsen > konnte, die Bank hat gerade selbst ein Problem, Du hast die falsche > HBCI-Version verwendet, Du hast die falsche PIN eingegeben, ... > > Ist ungefähr so als gehst Du in die Auto-Werkstatt und sagst "Hier > blinkt ein rotes Licht. Wo liegt der Fehler?" ;-) mmh... Wenn der Stack-Trace das verrät, warum wird dann an den verschiedenen Stellen die gleiche Message in die Exception gepackt. ;) Ich schau mal obs an der DSL-Leitung auch auftritt. Log wird nicht gehen, da ich das in der Entwicklungs- Umgebung nur per remote-debugging starten kann (das Java Plugin Framework spielt viel mit den Classloadern rum.) aber den Stack-Trace müsste ich liefern können. Hat HBCI irgendwelche Timing-Einschränkungen? Das war mal wieder GPRS im ICE bei 120+, da dauert alles etwas länger. Marcus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkn3PzAACgkQf1hPnk3Z0cRUvgCeJsaGS7+jhkUEgpx6hU2QF6NT 2rEAoN9ddCztxUYC/qTwf51O8M0rXuIo =NW5n -----END PGP SIGNATURE----- |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-28 17:45:35
|
> mmh... Wenn der Stack-Trace das verrät, MUSS nicht, KÖNNTE aber. Hängt vom Fehler ab... > warum wird dann an den verschiedenen Stellen die gleiche > Message in die Exception gepackt. ;) Erwischt. Das Error-Handling-System in HBCI4Java-2 ist... - sagen wir mal, "suboptimal" ;-) Ich verspreche Besserung in HBCI4Java-3. > Hat HBCI irgendwelche Timing-Einschränkungen? Ja, aber die liegen eher im Minuten-Bereich - sollte als nicht wirklich ein Problem werden... Grüße -stefan- |
|
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- |
|
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: 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 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 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: 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 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: 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: 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: 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-28 17:32:48
|
> Verbesserungsvorschlag erstmal: > Bessere Fehlermeldungen die > a) > ein User verstehen würde und > > b) > genau genug sagen was kaputt > ist ohne die Situation mit erhöhrem > Log-Level nochmal provozieren zu > müssen. (Das kann ich machen, ein > normaler User aber nicht.) Wenn Du den kompletten Exception-Trace geschickt hättest, wüsste ich wohl eher was kaputt sein könnte. Der von Dir genannte Fehler trat auf, als HBCI4Java versucht hat, die System-ID zu synchronisieren. Das kann viele Ursachen haben: die Bank antwortete nicht, die Bank hat mir einer Nachricht geantwortet, die HBCI4Java nicht parsen konnte, die Bank hat gerade selbst ein Problem, Du hast die falsche HBCI-Version verwendet, Du hast die falsche PIN eingegeben, ... Ist ungefähr so als gehst Du in die Auto-Werkstatt und sagst "Hier blinkt ein rotes Licht. Wo liegt der Fehler?" ;-) Grüße -stefan- |
|
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: 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: <mic...@fa...> - 2009-04-29 12:30:28
Attachments:
signature.asc
|
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: 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: 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 |
×
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