hibiscus-server sicherheit bei schlüsseldatei

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:

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

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

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.

Signatur ID synchronisieren hat's gefixt