Passwortübergabe

E

eisenkannte

Neues Mitglied
Hy,

ich bin neu hier im Forum und ein blutiger Anfänger.
Ich habe folgendes Problem:
In einer bestehenden Desktop Anwendung soll ein System Encryption Key (SEP), für eine Verschlüsselte Interbase 2020 Datenbank, eingebettet werden.
User-Name und User-Passwort sind schon eingebettet, möchte der Chef so, nur meckert die Anwendung über das fehlende SEPasswort.
Ich habe leider keinen Ansatz gefunden wo und wie ich das im Programmcode einbetten kann.
Code ausschnitte kann/darf ich leider nicht Posten, wenn Angaben fehlen seid bitte Nachsichtig mit mir.
Das Programm wurde in C++ geschrieben. Die DB-Verbindung, abfrage, ect. wurde mit den Komponenten der Tool-Palette (IBDatabase, IBDataSet, IBQ, ect.) erreicht.
Man kommt auch an die Daten, sofern man vorher das SEP in der IBConsole eingibt. Das sollte allerdings über das Programm laufen...
Mir ist bewusst dass das ein Sicherheitsrisiko ist, aber wie gesagt, der Chef möchte das so.

Vielen Dank für eure Hilfe.

Freundliche Grüße

eisenkannte
 
Zuletzt bearbeitet:
Ich nehme an, das ist der Delphi-Kram? Wenn ich das richtig sehe, sagt dir die Doku, was du nicht tun solltest. Und das ist vermutlich genau das, was du machen möchtest. Also nach dem Motto: "Ich rate davon ab, eine Bombe zu bauen. Hier sind die genauen Schritte, wie du dafür vorgehen musst" ;)

Setting the System Encryption Password (SEP) - InterBase

docwiki.embarcadero.com docwiki.embarcadero.com
The external form of setting the SEP requires the first database attach to pass the isc_dpb_sys_encrypt_password parameter with the value of the password, or to set the environment variable isc_system_encrypt_password. Subsequent database attachments are not required to pass the SEP as the database server already has it in memory.

For security reasons, programs should not hardcode the SEP with isc_dpb_sys_encrypt_password but query the user, then generate this database attachment parameter dynamically. The isc_system_encrypt_password environment variable should never be hardcoded in scripts and if entered at the console should be unset as soon as possible.
Zum Vergrößern anklicken....

Kannst ja mal gucken, ob die Interbase-API das direkte Setzen von isc_dpb_sys_encrypt_password ermöglicht. Sonst kannst du natürlich auch das Passwort über Umgebungsvariablen hinterlegen. Schön ist das alles aber nicht.

ACHTUNG:​

Achja.. und bitte arbeite auf einer Kopie der DB. Nicht, dass du sie kaputt-verschlüsselst.
 
Danke erstmal für die schnelle Antwort.
Klaro. Die Anwendung und die DB laufen gerade in einer Testumgebung.

Ich werde das morgen mal ausprobieren und dann rückmeldung geben.

Ich denke, wenn alles erstmal läuft, kann man den Chef auch auf andere Möglichkeiten aufmerksam machen, aber für's erste möchte er es so.

Freundliche Grüße

eisenkannte
 
Kannst dich ja melden, wenn es läuft. Vielleicht kann man sich dann noch eine sicherere Methode überlegen.

So wie es aussieht, braucht Interbase das SEP nur am Anfang der Session und die (Umgebungs-)Variable kann dann gelöscht werden. Der Desktop-Client könnte sich Benutzername, Passwort und SEP aus einem sicheren Verzeichnis oder sogar aus dem Passwort-Tresor des Betriebssystems holen, die Verbindung herstellen, und dann die Variablen wieder löschen (wenn sie nicht weiter benötigt werden). Wäre immerhin ein kleines Bisschen sicherer und hätte trotzdem hinterlegte Zugangsdaten.

Ob das überhaupt Sinn macht, hängt natürlich vom Arbeitsprozess ab und wie der Client genutzt werden soll usw.
 
Es hat funktioniert.
Vielen Dank, ich hatte das zwar in der Doku gelesen, war mir aber zu unsicher 😅.
Chef ist jetzt eh erstmal im Urlaub und damit alles weitere erstmals eh ganz entspannt.
Danke dir nochmal
 
Bei mir auf der Arbeit verwenden wir eine Micro-Service-Architektur und sichern die Credentials eines Services, wenn er deployed wird, mit AWS. Dadurch bleiben die Credentials intern dynamisch. Dann kann jeder andere Service sich die Credentials derjenigen Services, mit denen er reden können muss, aus dem Parameterstore holen. Die werden dann in einer .env gespeichert, auf die die Instanz des Services dann zugreifen kann.
Da kommt zwar noch etwas Komplexität durch Kubernetes, Docker, Pulumi etc. hinzu, aber im großen und ganzen funktioniert das so bei uns. Nur so als Inspirationsquelle gedacht :)

Wenn in deinem Fall das Passwort statisch bleiben soll, kannst du das natürlich an einem sicheren Ort ablegen. Hardcoden ist aber natürlich nie ne gute Idee, wie du ja auch schon angemerkt hast :) Ein gewiefter Hacker kann da halt u.U. durch Speicherlecks an das Passwort rankommen.

Wir fahren grundsätzlich die Strategie "Infrastructure-as-code". Dann kannst du die Credentials nämlich im Deployment-Code hinterlegen (der irgendwo komplett abgesichert durch Zugriff von außen gespeichert ist). Der kann das dann nämlich für dich im Zielsystem an einem sicheren Ort abspeichern, auf den der Service dann Zugriff hat. Z.B. eine .env. Dann müsstest du nicht selbst Hand anlegen, wenn das Zielsystem resetted wird.
 
Zurück
Oben Unten