Hallo!

Nach kleineren Problemen beim Schlüssel erstellen (openhbci.conf hat nach dem Schlüsselerstellen 210 angezeigt, dabei muss ich bei meiner VB bei hbci.gad.de mit 220 oder 300 arbeiten und habe nachher umgestellt auf 220, dafür hatte ich auch hashwerte und mein mit cups eingerichteter drucker wird nicht gefunden) habe ich heute versucht die kontenliste abzurufen, leider erfolglos mit der Meldung:
Fehler : 9150 Kundensystem-ID = 0 nur bei erstmaliger Schlüsseleinreichung

der ist mir so erstmal nicht klar....

aber der hier sagt bei eigenem öffentlichen Schlüssel senden:
9010 Vertriebsweg nicht freigeschaltet.

ganz klar, dass noch nicht freigeschaltet wurde, obwohl er gesagt hat, dass er die hashwerte direkt eingibt, als ich den ini-brief abgegeben hab...

Oder er hat tatsächlich nen 210 Schlüssel erstellt und falsche hashwerte ausgedruckt, sodass nicht freigeschaltet werden kann....ne auswahl welche hbci version erstellt werden soll vor dem erstellen wäre nett, auch wenn es so funktioniert hat.

Also hab ich das Konto erstmal manuell angelegt, suche jetzt aber vergeblich nach ner möglichkeit das auch wieder zu löschen, finde aber nix, noch nichtmal ne möglcihkeit die kontonummer zu ändern, nur die beschreibung...iv.dat, moneypenny.bf und pwmd.dat auf der diskette löschen und schlüssel neu einlesen?

mfg tyler

Zu MoneyPenny kann ich nichts sagen, aber zu OpenHBCI:
Die Schluessel werden nicht fuer eine bestimmte Version erstellt, wenn Du eine andere Protokoll-Version verwendest aendert sich dadurch nicht der Hash... Schliesslich kann man auch nachtraeglich noch das Protokoll wechseln, ohne das der Schluessel gleich ungueltig wird...


Gruss
Martin

Das denke ich aber schon...

Die GAD arbeitet bei FinTS3 mit 1024bit langen Schlüsseln, bei HBCI 2.2 und kleiner mit 786bit.
Man muss also schon ein wenig differenzieren...

Das ist zwar richtig, aber FinTS3 unterstuetzt OpenHBCI gar nicht, hat also bei MoneyPenny keine Relevanz. Alle HBCI-Versionen kleiner 300 verwenden 768-bit Schluessel.


Gruss
Martin

Hallo Tyler,

das Problem ist die Meldung "Vertriebsweg nicht freigeschaltet". Der Kollege bei der VB soll sich die Kontoverschlüsselungen ansehen und überprüfen, da fehlt etwas.
Es kann aber sein, das der Vertriebsweg erst eingerichtet wird, wenn du deinen HBCI-Vertrag unterschrieben bei deiner Bank abgegeben hast.

Solange der Vertriebsweg nicht eingerichtet ist, kannst du deinen öffentlichen Schlüssel nicht zur Bank übertragen und der Kollege kann die Hashwerte nicht in unser System eingeben, weil....da ist noch nichts übertragen.

Also morgen zur Bank gehen oder dort anrufen und lasse dich mit den Kollegen der Abteilung EBL verbinden. Die wissen, was zu tun ist.

Schreibe mal, ob alles geklappt hat.

Nabend!

Erstmal danke für die rege teilnahme

Also da musste ich mich heute auch erstmal schlau machen...denn die Meldung kenn ich schon....nur nicht genau was das bedeutet, also hab ich die bank angerufen...
Es ist der Vertrag für die Nutzung HBCI, den ich allerdings unterschrieben habe, als ich die Benutzerkennung abgeholt habe....vor ca 2 monaten....
Die Freischaltung hat daher anscheinend jetzt funktioniert, denn meinen offentlichen Schlüssel senden war erfolgreich, nur die System-ID hängt noch mit:

da ich ihn erfolgreich gesendet habe fehlt jetzt die freigabe, d.h. Eingabe der hash werte

oder es sind tatsächlich keine gültigen hash werte, aber wenn Martin sagt das geht, auch wenn er als 210 erstellt wurde, dann geht das schon....zu meiner schande muss ich eingestehen, dass es noch eine weitere Fehlerquelle gibt...ich hab kurz davor ein weiters linux installiert, was mir die hardwarezeit verstellt hat und damit ist meine uhr bei der schlüsselerstellung leider eine stunde vorgegangen, soweit ich weiß ist die systemzeit bei der verschlüsselung nicht unerheblich.

Aber warten wir mal morgen ab - ich berichte.

mfg tyler

P.S.: kann openhci2 eigentlich 300....ob das jetzt hbci oder fints heißt ist ja vollkommen egal, die verschlüsselung ist wichtig und die unterstützen geschäftsvorfälle

P.P.S: wie man ein konto löscht weiß ich immer noch nicht...denke mal ich warte auf die freischaltung und dann lösch ich mal das verzeichnis auf der festplatte mit den logs und den configs und die datenbanken auf der diskette, bis auf den key und eine bak (der legt mir tatsächlich 3 .bak dateien an) und lese dann den schlüssel neu ein um zu testen, ob das konto automatisch angelegt wird.

Nein, und es wird es auch nicht mehr lernen...

Der Nachfolger allerdings wird ueber kurz oder lang 3.00 unterstuetzen (zunaechst erst mal nur die Geschaeftsvorfaelle und die bisherigen Sicherheitsmedien, die auch von 3.00 noch unterstuetzt werden).

Ich benoetige nur halt eine Bank, die auch 3.00 anbietet, um das ganze testen zu koennen. Solange ich das nicht habe kann ich nichts machen.


Gruss
Martin

Ich denke eine beliebige VR-Bank an der GAD kann mit FinTS3 aushelfen.

Nabend!

und hier die versprochene Rückmeldung:

Alles O.K. System-ID erhalten und Umsätze abgerufen - ÜW liegt gerade nicht an, das teste ich zum ersten.

Aber mal ne ganz andere Frage: Verschlüsselt aqbanking, bzw aqmoney und falls das jemand weiß GnuCash seine Datenbanken auf der Festplatte auch nicht, sondern verlässt sich auf die Benutzerberechtigungen von Linux?

Erst hatte ich ja gedacht dass moneypenny seine Datenbanken auch verschlüsselt auf der Diskette/USB-Stick ablegt und war begeistert von dieser idee, da immer dabei mit der knoppix version in der tasche (könnte man auch mit auf den USB-Stick packen, wenn der groß genug ist und das MB vom USB-Stick bootet) und supersicher.
Leider musste ich meine Buchungen im Klartext auf der Festplatte finden, d.h. wenn ich nur ein anderes Linux von meiner Festplatte boote kann ich die Benutzerberechtigungen überschreiben und habe die Daten...klar lässt sich alles sichern, trotzdem Klartext ist nicht gut....SSL ist doch eh benötigt, da könnte man doch leicht ne verschlüsselung implementieren (naja ich kann gar nicht coden, daher weiß ich nicht wie leicht das ist...).

mfg tyler

nun, ssl benötigt HBCI nicht, nur für HBCI mit PIN&TAN, aber es müsste doch unter Linux auch möglich sein, ganze Verzeichnisse zu verschlüsseln, oder? Irgendwo hab ich mal was von cfs gelesen..

ich da mal das gegoogelt: http://devil.linux-site.net/~tom/zeugs/cfs.htm
k.A. ob das übertragbar und hier hilfreich ist.

Gruß
Raimund

Hallo!

Alle benötigten Programme für moneypenny und moneypenny selbst ist abhängig von openssl (also auch openhbci2), d.h. sowieso installiert, wobei es denke ich auch kaum eine distri gibt, die openssl nicht installiert im standard, wobei ich nicht weiß, ob man damit eine verschlüselte datenbank realisieren kann.

cfs ist sicher ne gute idee (ich nehme zwar LUKS und DM-crypt) aber von Windows Zahlungsverkehrsprogramen kenne ich das, dass die Datenbanken nicht vom user noch über exterene tools verschlüsselt werden müssen, sondern vom Programm verschlüselt werden.
LUKS als benötigtes Programm (dm-crypt ist im kernel ab 2.6) und das Programm verwenden für die verschlüsselung des moneypenny_data verzeichnisses würde ja auch durchaus der unix idee entsprechen vorhanden programme zu nutzen und einzubauen, nur sollte das im standard passieren und nicht erst durch zutun des users, denn der möchte installieren und arbeiten, ohne sich noch lange mit verschlüsselten verzeichnissen zu beschäftigen.

mfg tyler

http://luks.endorphin.org/

edit: Irgendwas stimmt hier auch nicht - ich hatte doch im Kopf, dass die Datenbanken verschlüsselt werden und auf Wechselmedium gespeichert werden, wie hier zu lesen ist:
http://www.onlinebanking-forum…php?t=2729
nur habe ich im heimatverzeichnis des moneypenny users nen moneypenny_data verzeichnis und da sind die buchungen im klartext drin.
und jetzt habe ich das Verzeichnis im homeverzeichnis gelsöcht, moneypenny neu gestartet und die Datenbanken sind noch da, d.h. doch auf der Diskette gespeichert (dort auch verschlüsselt) nur werden die daten nach dem start des programms unverschlüsselt auf die festplatte gepackt und nicht wieder gelöscht bei beenden des programms, nen rm -rf auf dieses verzeichniss beim beenden würde das problem beheben

Ich finde es sinnvoller, ein verschluesseltes Dateisystem zu verwenden. Das ist die einzige Garantie, dass die Daten gut geschuetzt sind.

Wenn beispielsweise MoneyPenny waehrend des Programmlaufes die Daten unverschluesselt auf der Festplatte ablegt (und diese Daten somit waehrenddessen angreifbar sind), ist das genau der Punkt den ich meine: Es ist einfach besser, fuer die Verschluesselung auf Tools zurueckzugreifen, deren originaere Aufgabe die Verschluesselung ist, denn offensichtlich ist das ja trotz Verschluesselung durch MoneyPenny zusaetzlich noch noetig...

Gruss
Martin

Soweit ich weiss ist MoneyPenny nicht Open Source, oder? Also könnte ich auch gar nicht die Qualität der Verschlüsselung beurteilen (lassen), wobei das mit einem verschlüsselten Dateisystem einfacher wäre, wenn die Quellen zu bekommen sind.
Zusätzlich muss ich mich nicht auf die Programmierer verlassen, wenn sich mal eine Verschlüsselung als schwach herausstellt, dann kann ich unabhängig von der Software wechseln. Ein paar Gründe sprechen also schon dafür, auf ein Filesystem zu setzten.

Ein Nachteil: Ist mein verschlüsseltes System geknackt worden, dann ist auch sofort die Datenbank meine Bank-Software offen. Was allerdings nach Murphy dann eh keine große Rolle mehr spielt.

Gruß
Raimund

1. MoneyPenny ist durchaus OpenSource; der Quellcode liegt hier zum runterladen. Ich glaub sogar, der Code ist GPL, aber da irre ich mich vielleicht auch.

2. Wenn wir hier über Verschlüsselung reden, müssten die jeweiligen Daten ("was soll denn verschlüsselt werden") bitte säuberlich getrennt werden: Einerseits gibt es den hoch sensitiven RSA-Schlüssel für die HBCI-Operationen, andererseits gibt es den eigentlichen Datenbestand der Finanzverwaltung.

3. Der RSA-Schlüssel wird ja von allen HBCI-Anwendungen seinerseits beim Speichern auf Diskette/USB-Stick/Platte verschlüsselt. Das ist auch sinnvoll und wirkungsvoll, aber eben auch nur deswegen, weil die Datenmenge überschaubar ist und weil der Verwendungszeitpunkt jener Daten auch eng begrenzt ist. Da muss man auf solche Sachen achten wie daß der Teil des Speichers, wo der Klartext-RSA-key rumliegt, nicht in die Auslagerungsdatei auf Platte geschrieben wird usw. Das geht für den RSA-key, weil das eben überschaubare Datenmengen sind.

4. In der Tat verschlüsselt GnuCash seinen eigenen Datenbestand gar nicht. Die Frage ist nämlich, *gegen was* will man eine Verschlüsselung einsetzen. Gegen einen Angreifer, der auf meiner Maschine root werden konnte? Da hilft mir die Verschlüsselung der Datei eh nix mehr, weil der Angreifer während der laufenden Finanzsoftware kurzerhand den Speicher auslesen kann und darüber auch die Daten kriegt. Den Rest dieser Diskussion hab ich gerade vergessen (die FAQ von GnuCash hat auch nur diese kurze Antwort), aber es lief darauf hinaus, dass eine *wirkungsvolle* Sicherung der Daten viel zu umfangreich ist, als dass eine Finanzsoftware alleine das für seine Daten auch korrekt hinkriegen kann. Und eine halb-korrekte Implementierung davon ist völlig wirkungslos, also lässt man es lieber gleich. Und genau das ist auch die Wahl, die GnuCash getroffen hat. Bei KMyMoney gibt es die Option, dass die Daten-Datei kurzerhand via gpg verschlüsselt wird -- ob das ausreichend hilft, wage ich zu bezweifeln, aber es ist zumindest möglich. Bei MoneyPenny weiß ich die Details nicht.

cstim

Morgen,

Klar hast du recht, wenn der Angreifer root geworden ist auf einer laufenden Maschine ist alles gelaufen, nur muss man dafür erstmal root werden. Wenn wie in diesem Fall, die Daten aber auf der Festplatte verbleiben bleibt die erwähnte Möglichkeit nen Knoppix zu booten und schon ist das dein Rechner (Obwohl man dafür bei mir auch nen passwort braucht um von CD zu booten) und das ist um einiges leichter, als den user account zu hacken, oder die Festplatten auszubauen und mit Wiederherstellungs-tools die Daten wiederherzustellen, die zwar gelöscht sind, aber noch nicht oft genug überschrieben wurden.
Damit meine ich dass man zumindestens versuchen sollte für mehr Sicherheit zu sorgen, als zu sagen das wird eh nicht perfekt, dann lassen wirs einfach.

mfg tyler

Was Festplattenverschlüsselung unter Linux angeht, so ist Loop-AES zu empfehlen. Den Rest kann man eh vergessen. Unter dm-crypt oder ähnlichen sind Watermarking Attacks möglich.

Loop AES Project HP

Bei Fragen oder sonstigem, kurze PN

Moin,

sorry, für den ziemlich späten Einstieg in die Diskussion, aber auch ich brauchte ein paar Tage Urlaub



In der Tat ist es so, dass MoneyPenny zur Laufzeit Klartextdaten im Homeverzeichnis ablegt. Da wir auf die Benutzung einer Live-CD zielen,
die diese Klartextdaten in der RAM-Disk, also im flüchtigen Speicher ablegt, haben wir uns bisher nicht die Mühe gemacht, diese Daten separat zu verschlüsseln, sondern verlassen uns dort vollständig auf die interne Datenhaltung von OpenHBCI, die unverschlüsselt ist. Da Swapping auf der Live-CD deaktiviert ist, landet definitiv nichts auf der Festplatte.

Nach Beendigung des Programms, werden diese Klartextdateien vollständig von der Festplatte gelöscht, das ist bisher die maximale Sicherheit, die wir den Benutzern der Installations-Version bieten können. Das ist nicht sonderlich schön, allerdings denke ich, daß die Leute, die sich selbst ein Linux-System installieren, auch wissen was sie tun.

Wer die Live-CD benutzt, kann sicher gehen, dass nach der Beendigung des Programms keine Daten mehr auf der Maschine verbleiben. Linux-Anwender müssen (und können in der Regel) selbst Hand anlegen, wobei MoneyPenny natürlich bei sachgerechtem Beenden den zwischengespeicherten Klartextbestand von der Festplatte löscht.




MoneyPenny ist Open Source und unterliegt der GPL.



Um den auf der Platte gepufferten Datenbestand zu verschlüsseln, müssten wir nicht MoneyPenny ändern, sondern ein paar Stufen tiefer, an OpenHBCI handanlegen. Da dieses Projekt allerdings eh tot ist und nicht weiterentwickelt wird, sehe ich selbst wenig sinn darin, die Bibliothek noch um ein einziges Feature zu erweitern, zumal wir sie selbst nicht geschrieben haben und zu viel Einarbeitungszeit brauchen würden. Tatsächlich wollen wir, wenn es die Zeit irgendwann mal erlaubt, auf die Nachfolgebibliothek umstellen. Wenn es daran etwas zu verbessern gibt, macht das durchaus mehr Sinn, weil auch andere Clients (z.B. GnuCash) von diesen Änderungen profitieren können.


Viele Grüße,

Marcel

Moin,


Tatsaechlich ist es nicht OpenHBCI sondern eher die verwendete libaqmoney, und hier waere eine solche Aenderung gar kein Problem: In src/libaqmoney/storage ist die derzeit zur Datenspeicherung verwendete Klasse "storagefile" zu finden. Dies koennte man ganz einfach als Muster nehmen und darauf aufbauend die Verschluesselung einbauen.

Aber wie gesagt, ich finde eine solche Aufgabe gehoert nicht in eine Banking-Anwendung, denn gerade hier fallen doch mitunter viele Daten an, und dann wird eine eigene Crypt-Logik doch schnell unuebersichtlich... (es sei denn, man speichert wie KMyMoney alles in einer Datei, aber davon sind wir ja wegen der langen Startup-Zeiten bei AqMoney und QBankManager weg).



Gibt es da eigentlich schon konkrete Plaene?


Gruss
Martin

Hi,



soweit ich mich erinnern kann, wird aber nicht der gesamte Datenbestand von AqMoney verwaltet. Zum Beispiel der Teil, der die Kundeninformationen und Bankparameterdaten enthält, gehört noch OpenHBCI, wobei insgesamt noch fraglich ist, wie sicherheitsbedenklich die Informationen darin sind.




Nunja, in der Planung ist ein solcher Umstieg natürlich schon. Da sich die Anpassung der Live-Cd allerdings nach wie vor als abenteuerlich herausstellt, haben wir dieses Vorhaben ersteinmal zurückstellen müssen.

Gruss Marcel

Hallo Tyler,
Konto löschen ging wirklich nicht. War in OpenHBCI nicht vorgesehen. Das heben wir jetzt in MoneyPenny 1.0.0.4rc nachgerüstet. Die neue Version steht auf dem Server zum Download zur Vrfügung.
Gruß
Walter