FinCmd Schlüsseldatei ohne Contactfile

Ich fürchte, das wird mit der derzeitigen Philosophie nicht klappen...

Bei div. Herstellern muß ins Keyfile geschrieben werden können. Dort werden dann die Zähler hinterlegt ect. Besonders auffällig war das zu Diskettenzeiten, wenn das Laufwerk so lange auf einer Stelle der Diskette rumgeschrubbt hat, bis die hin war und das File dann nicht mehr lesbar.

Bei Subsembly ist das anders. Das Keyfile wird nach der Erstellung (oder PW-Ändeurng) nicht mehr beschrieben. Schau Dir mal das Dateidatum an. Alle sich ändernden Dinge werden im Contactfile abgelegt. Im Keyfile sind nur die sensiblen Dinge und die werden nur gelesen. Ich finde diese Handhabung eigentlich klüger... aber das schließt eben das von Dir gewünschte aus.

Workaround: Du kannst doch das Contactfile mit auf das Keymedium legen, das kann ja liegen, wo Du es haben willst. Damit wäre doch quasi das gleiche erreicht, auf dem Rechner liegt garnix...!?

Ich versteh das Problem noch nicht ganz!

Das Contactfile kann ja liegen, wo es mag. Den Pfad hierzu gibt man einfach direkt mit an. Also "FinCmd -contactfile X:\Verzeichnis\Sonstwo\Gartenbank.xml". Damit hat FinCmd erst mal alles was es braucht, das Contactfile muß also nicht irgendwo speziell hingespeichert sein.

Im Contactfile steht der Pfad drin, wo die Schlüsseldatei gelesen werden kann. Entweder der übliche USB-Stick oder ein Pfad im User-Home oder was weiß ich. Dort liest FinCmd die Datei und gut is. Einzig wäre es ein Problem, wenn der Pfad der Schlüsseldatei jedes Mal ein anderer wäre. Dann müßte man tricksen.

Den einzigen Holzweg den ich nach mehrmaligem Durchlesen Deines Posts jetzt sehe ist, dass Du offenbar das GLEICHE Contactfile für Dich UND die Gattin verwenden willst? Das dürfte sowieso nicht gehen. Denn das Contactfile gehört zwingend zur benutzten Schlüsseldatei, da darin ja Parameter zu dieser Schlüsseldatei hinterlegt sind. Vorgangszähler zu der Benutzerkennung DIESES Schlüssels usw.

Wie wäre es also folgendermaßen: Ein Contactfile und eine Schlüsseldatei jeweils für dich und für die Gattin, und die beiden jeweils zusammen im jeweiligen Userverzeichnis abgelegt. Wenn Du was machst, gibst Du als Parameter den Contactfile samt Pfad in DEIN Usererzeichnis an, und dann wird der Schlüssel aus Deinem Userverz. gelesen, das in Deinem Contactfile drinsteht. Und wenn die Gattin was macht, gibt man beim gleichen FinCmd das Contactfile im Userverzeichnis der Gattin an, und darin ist der Schlüssel samt Pfad der Gattin hinterlegt...

Das wär doch genau das, was Du brauchst!?

Schlüsseldatei mitgeben und danach löschen kannste ja machen, da darin nichts geändert wird.

Nur die Contactfiles müssen entweder auf dem ausführenden Rechner liegenbleiben (sollte kein Problem sein, da ja nichts Sicherheitsrelevantes drin ist) oder aber zurückgegeben und aufbewahrt werden, fürs nächste Mal. Denn wenn Du das nicht machst, wird das nächste Mal der Auftrags-Zähler nicht stimmen und eine Doppel- oder was auch immer Einreichungskontrolle des Bankrechners zuschlagen und der Bankkontakt muß neu synchronisiert werden...

Ja genau, das liegt im Verfahren begründet. Sowohl das Kundensystem als auch der Bankrechner führen einen Zähler, der mit zählt, die wievielte Signatur mit diesem Schlüssel gemacht wurde. Ich weiß jetzt nicht, ob das Stückgenau synchron gehen muß oder ob da eine Toleranz dabei ist, wie bei ChipTAN. Und selbst im Toleranz-Fall klappt es eben nicht auf Dauer. Wohlgemerkt, auch Umsatzabrufe werden signiert und erhöhen den Zähler, nicht nur Aufträge. Du kommst also systembedingt nie um die "Aufbewahrung" eines veränderten Elements herum.

Und vor diesem Hintergrund finde ich es sogar viel cleverer, die sicherheitsrelevante Key-Datei NICHT zu beschreiben (die notfalls noch auf eier Dampfdiskette residiert) und die Zähler wo anders unterzubringen, wo nichts sicherheitsrelevantes drin ist.

Das klappt dann aber ja wohl auch nur für Listen-TAN oder SMSTAN oder so... ChipTAN kriegste ja in dem textbasierten Umfeld (zumindestens optisch) auch nicht hin. Und ChipTAN manuell ist ja wohl kein gangbarer Weg auf Dauer?