Hi,
da jetzt der hibiscus-server läuft habe ich noch ein paar fragen zur sicherheit mit der schlüsseldatei.
Ich habe bereits aus dem wiki herausgelesen, dass passwörter nur für die dauer einer sitzung gespeichert werden. dies gilt aberscheinbar nur für den hibiscus client, da ich mit zwei rechnern (aber an der gleichen ip) mit dem hibiscus-server synchronisieren konnte wobei man das passwort beim zweiten rechner nicht erneut eintippen mußte.
aus einem anderem thread wurde gewarnt den server aus dem öffentlichen netz zugänglich zu machen, da mit der schlüsseldatei als sicheheitsmedium ein vollzugriff auf das konto droht.

- Gibt es ein möglichkeit den server komplett auf manuelle synchronisation zu stellen und das passwort für die schlüsseldatei bei einer manuellen schynchronisation jedes mal zu erfragen, ohne die schlüsseldatei jedes mal neu hochzuladen und löschen zu müssen?

In meiner anwendung werden per rpc überweisungen erstellt und umsätze abgefragt. Nach dem Löschen der der schlüsseldatei schien diese funktion noch zu gehen (ein glück), weswegen mein plan jetzt erstmal war z.B. einmal täglich auf dem server die datei hochzuladen, passwort einzutippen und zu synchronisieren, wobei die umsätze auch aktualisiert würden. Würde man die schlüsseldatei nicht neu hochladen müssen sondern nur das passwort dafür wär das schonmal etwas praktischer. Zudem wär es vielleicht etwas sicherer, da ich die datei nicht jeden tag hochladen müsste.

- Da ich dann täglich bevor ich die synchro machen würde,würde ich gerne direkt auf dem hibiscus server prüfen welche überweisungen ausgeführt werden sollen (ggf welche stornieren, wobei das zur not per rpc gehen würde). Diese möglichkeit habe ich noch nicht entdeckt. brauch ich da noch irgend ein plugin? muss ich mir da noch ein plugin coden?

Da ich ja den hibiscus-server ohnehin per php anspreche könnte ich die manuelle synchro über meine palttform durchführen (bei der ich mich selber um die sicherheit kümmere).

- wäre es möglich eine RPC anweisung für die synchro einzurichten mit passwort als parameter für die schlüsseldatei? ich könnte mich dem code auch selbst annehmen sobald ich mehr luft hab. dann bräucht ich nur den einstiegspunkt ...

last but not least

- kann ich dem server irgendwie beibringen nur verbindungen von localhost anzunehmen? zur not sperr ich nur den port in der firewall.

Vielen dank im Voraus. Ich find hibiscus echt klasse gemacht und auf sehr hohem niveau. :thup:

Eine Schluesseldatei ist nicht dafuer gedacht, zwischen mehreren Rechnern hin- und herkopiert zu werden. Du kriegst sonst regelmaessig Doppel-Einreichungs-Fehler von der Bank wie in http://www.onlinebanking-forum…hp?t=14352 beschrieben. Siehe auch http://www.onlinebanking-forum…hp?t=11547

Hier ist es besser, bei der Bank eine zweite Benutzerkennung zu beantragen, damit du dir eine zweite Schluesseldatei erzeugen kannst und sie nicht mehr hin- und herkopieren musst.

Den TCP-Port 8080 des Webservers kannst du in der Config-Datei "cfg/de.willuhn.jameica.webadmin.Plugin.properties" an localhost binden. In der Datei findest du bereits entsprechende Kommentare.

Unabhaengig davon: Wofuer brauchst du eigentlich noch den Payment-Server, wenn du es alles manuell machen willst? Dann kannst du das doch auch gleich vom Hibiscus-Client aus machen und im Server die Synchronisierung abschalten, damit der lediglich dazu dient, die neuen Auftraege via XML-RPC entgegenzunehmen und in die Datenbank einzutragen. Das eigentliche Senden an die Bank machst du dann vom Client aus.

Hi,

danke für die antwort. die cfg datei schau ich mir an.

Ich will die signatur nur auf einem rechner verweden, jedoch nicht auf ihm samt passwort belassen, da es sich um einen webserver bei hetzner handelt.

Gibt zwei Gründe:
A. Ich will mir erst sicher sein, dass er sicher genug konfiguriert ist. Da das system noch recht jung ist und ich ein debian frischling bin, bin ich mir da noch nicht 100% sicher.
B. Die signatur ist eine persönliche signatur auch wenn es sich um das GmbH Konto handelt. Bis alle Haftungsfragen geklärt sind oder wir eine GmbH-signatur haben soll nur die Preson der die aktuelle Signatur gehört die Transaktionen absegnen.

Das System soll natürlich später vollautomatisch arbeiten wie gedacht.
Über die Möglichkeit von einem anderem anderem Client die Synchronisation mit Hibiscus Client ausszuführen habe ich noch nicht nachgedacht.
laut skizze


könnte das ja gehen.

Trotzdem wäre es nett den paymentserver in unsere Plattform zu integrieren, da wir einen Adminbereich haben, deswegen werde ich später die zwei featurerequests (rpc synchro und password on demand) in bugzilla mal eintragen, vielleicht läßt sich das als cfg oder plugin realisieren. ich kann mich ja auch mal versuchen an der weiterentwicklung zu beteiligen

Und warum schriebst du dann, dass du die Schluesseldatei immer wieder neu hochgeladen hast?



Und dennoch willst du das auf einem oeffentlich zugaenglichen Webserver laufen lassen? Ich kann nur nochmal betonen, dass ich dir dringend davon abrate. Der Payment-Server ist dafuer konzipiert, in einer gesicherten Umgebung - also einem LAN - betrieben zu werden.




Die Synchronisierung wird hierbei nicht vom Client aus auf dem Server angestossen. Stattdessen greifen lediglich Server und Client(s) auf die selbe MySQL-Datenbank zu, sodass sie sich einen gemeinsamen Datenbestand (Auftraege, Umsaetze, etc.) teilen koennen. Mehr nicht.




Die Synchronisierung kannst du auch einfach durch Aufruf der URL



manuell starten. Und das mit dem Passwort on demand ist zum einen gar nicht so einfach. Denn man kann im Server ja mehrere Bankzugaenge hinterlegen. In dem Fall weiss der Server ja nicht, fuer welchen Bankzugang das Passwort gelten soll (die Bankzugaenge haben keine eindeutigen Identifier, die man mitgeben koennte, um das Passwort zuzuordnen). Zum anderen halte ich diese Variante fuer noch unsicherer, weil das Passwort dann jedesmal ueber die Leitung geschickt werden muss. Wenn es auf dem Server gespeichert ist, dann ist es dort wenigstens verschluesselt abgelegt.

Ich denke, du suchst hier bei deinem Problem nach der falschen Loesung.

Weil die datei immer mit passwort gespeichert wird. Da ich momentan keine möglichkeit sehe das passwort nicht speichern zu lassen, ausser das sicherheitsmedium nach der synchro zu löschen, erschien mir das als einzige Lösung.


Es ist halt meine Aufgabe den Server sicher zu machen. Wäre das Shopsystem (auf der Grafik als externes System) nicht sicher. Könnten Angreifer per rpc bzw sql genauso den paymentserver komprimitieren, auch wenn er nicht direkt am www hängt. Die Verbindung zwischen externem system und payment server ist ja ada und das externe system kennt entweder die sql zugangsdaten oder die hibiscus zugangsdaten.
Die einzige sichere alternative wäre wenn täglich jemand die Transaktionen nach einer Prüfung auf einem USB-Stick vom shopsystem zum Paymentserver trägt. Dann relativiert sich auch schon die existenzberechtigung des Servers.
Ich würde die Risiken minimieren von Seiten der Bank: Keine Auslandsüberweisungen, Lastschrift begrenzen falls überhaupt nötig etc.


Momentan seh ich das auch als einzige Lösung kein großes Risiko mit der Schlüsseldatei einzugehn. Dan brauch ich den payment server momentan nur um die rpc requests in SQL zu übersetzen. Sollte das eine dauerhafte Lösung werden würde ich direkt auf die Datenbank zugreifen und den payment server weglassen.


Danke für den tipp, darauf hätt ich auch kommen können ops:


Wie funktioniert das eigentlich mit PIN/TAN Verfahren?

Dass für das passwort on demand keine einfache Lösung gibt hab ich mir schon gedacht.
Falls das weiter verfolgt wird würde folgende Lösung vorschlagen:
1. hibiscus.xmlrpc.sicherheitsmedium.list (optional param für typ):
listet alle sicherheitsmedien ids oder hashes
2. hibiscus.xmlrpc.sicherheitsmedium.authenticate (parameter passwort bei schlüsseldatei)
3. hibiscus.xmlrpc.sicherheitsmedium.unauthenticate (kein param)
passwort wird gelöscht



Ich habe es eingesehn, dass in meinem Fall einfach der hibiscus client vorübergehent die bessere Wahl wäre. Die Lösung nach der ich suche würde es mir jedoch ermöglichen etwas mehr Kontrolle über die arbeitsweise in unser administrations system zu integrieren und würde den hibiscus client entbehrlich machen. so kann z.b. der schlüsseldatei-verantwortliche auch von seinem smartphone ausm urlaub die transaktionen absegnen. Die Sicherheit des ganen Systems ist in jedem Fall in meiner Verantwortung. aber irgendwas ist immer...
Selbst wenn ein Panzerknacker irgendwo ne sicherheitslücke findet, ist es dennoch nicht so, dass er seine Taschen konsequenzlos mit Goldbarren füllen und unbemerkt verschwinden kann. zumindest nicht im Inland

Mann das mit der sicherheit endlos weiterspinnen. z.B. wär ein mögliches feature eine simple emailbenachrichtigung bei einer bestimmten aktion. zb synchronisation. :shock:

übrigens danke für die geduldigen antworten

ist das jetzt der doppeleinreichungsfehler oder ist es eher was hibiscus internes?

die signatur funktioniert aber noch mit nem anderem programm.

ich hab jetzt hibiscus nochmal auf nem client installiert und mit der alten datenbank verbunden, damit die synchronisierung von dort ausgeführt werden kann.

es könnt höchstens irgendwas von der alten sig in der db gespeichert sein.

was steht in der tabelle 'version'?
da ist ein eintrag mit name:upd.... und version 6

ich spekulier jetzt nur rum


edit:
bank ist GLS btw

Das sind Fehlermeldungen von der Bank. "9210:Signature Id 6 was already used" hab ich zwar noch nie von einer Bank gesehen (meist schicken die da auf Deutsch "Doppeleinreichung") - aber ich denke, es handelt sich hier in der Tat um eine Doppeleinreichung.



Ja natuerlich. In dem Programm, in dem die Datei zuletzt erfolgreich benutzt wurde, funktioniert sie auch weiterhin. Weil dort der Counter auf dem aktuellen Stand und synchron mit der Bank ist.



Nein. Hibiscus cached BPD/UPD zwar in der Datenbank. Die werden aber nicht fuer Bank-Kommunikation verwendet.



Die Versionsnummer der Datenbank selbst sowie die Versionsnummern der BPD/UPD. Das hat alles nichts mit deinem Fehler zu tun. Du hast die Schluesseldatei doppelt eingereicht.

danke!

Signatur ID synchronisieren hat's gefixt