Inhalte in DB verschlüsselt ablegen

[sunside]

Hallo,

der Knackpunkt vorweg: Wie sicher ist es, einen OpenSSL Public- UND Private-Key auf dem gleichen Server zu speichern, und nur die (gute) Passphrase geheim zu halten und bei Bedarf vom Nutzer eingeben zu lassen und über eine SSL-verschlüsselte Verbindung zu übertragen?

Das Szenario ist Folgendes: Es sollen Formulardaten von einem Webserver verschlüsselt in einer Datenbank abgelegt werden, und bei Bedarf von mehreren berechtigten Benutzern im Klartext wieder angezeigt werden können.

Symmetrische Verschlüsselung fällt schon mal aus, weil dann nur ein Schlüssel zum Ver- und Entschlüsseln benutzt wird, und das Verschlüsseln der irgendwann ankommenden Formulardaten soll ja ohne Benutzereingriff direkt auf dem Server geschehen. Der Schlüssel als "Master Secret" müsste also auf dem Server gespeichert sein, was eine schlechte Idee ist.

Es bleibt Public Key Kryptographie mit OpenSSL. Ich könnte natürlich nur den Public Key auf den Server legen und die eingehenden Daten damit verschlüsseln. Nachteil: Zum Lesen der Daten müsste der Private Key auf jedem Benutzer-Rechner gespeichert werden, und bei jedem Entschlüsselungsvorgang hochgeladen werden. Das halte ich für noch unsicherer als den Private Key nur einmal auf den Server zu legen, und ihn mit einer Passphrase zu schützen. Diese würde dann bei Bedarf durch den Nutzer in ein SSL-verschlüsseltes Formular eingegeben, und damit der auf dem Server gespeicherte Private Key entschlüsselt, der wiederum zum Entschlüsseln der Daten in der DB benutzt wird.

Daher die Frage: Wie gut ist der Schutz durch die Passphrase? Kann man sich die Übung dann auch gleich schenken, oder ist das ein Sicherheitsgewinn? Die DB-Daten tauchen in mehreren Backups auf und werden auch unverschlüsselt übertragen, sind also per se der verwundbarste Punkt.

Falls jemand noch bessere Ideen hat, immer gerne her damit

Viele Grüsse
Sunside

[Carsten Eilers]

Hallo,

der Knackpunkt vorweg: Wie sicher ist es, einen OpenSSL Public- UND Private-Key auf dem gleichen Server zu speichern, und nur die (gute) Passphrase geheim zu halten und bei Bedarf vom Nutzer eingeben zu lassen und über eine SSL-verschlüsselte Verbindung zu übertragen?

Das kommt drauf an, was vor wem geschützt werden soll.

Das Szenario ist Folgendes: Es sollen Formulardaten von einem Webserver verschlüsselt in einer Datenbank abgelegt werden, und bei Bedarf von mehreren berechtigten Benutzern im Klartext wieder angezeigt werden können.

Die Private Key wird also nicht zum signieren, sondern nur zum Entschlüsseln benötigt. Falls ein Angreifer an den Key kommt, kann er also "nur "die verschlüsselten Daten lesen, aber keine Identität fälschen, weil sowieso niemand der Signatur vertraut?

Es bleibt Public Key Kryptographie mit OpenSSL. Ich könnte natürlich nur den Public Key auf den Server legen und die eingehenden Daten damit verschlüsseln. Nachteil: Zum Lesen der Daten müsste der Private Key auf jedem Benutzer-Rechner gespeichert werden, und bei jedem Entschlüsselungsvorgang hochgeladen werden. Das halte ich für noch unsicherer als den Private Key nur einmal auf den Server zu legen, und ihn mit einer Passphrase zu schützen. Diese würde dann bei Bedarf durch den Nutzer in ein SSL-verschlüsseltes Formular eingegeben, und damit der auf dem Server gespeicherte Private Key entschlüsselt, der wiederum zum Entschlüsseln der Daten in der DB benutzt wird.

Das klingt soweit plausibel.

Daher die Frage: Wie gut ist der Schutz durch die Passphrase? Kann man sich die Übung dann auch gleich schenken, oder ist das ein Sicherheitsgewinn? Die DB-Daten tauchen in mehreren Backups auf und werden auch unverschlüsselt übertragen, sind also per se der verwundbarste Punkt.

Übertragung per GET oder POST?
Bei GET stehen sie als Klartext in den Logfiles, dann kann man sich die ganze Verschlüsselung sowieso schenken.
Bei POST kann sie z.B. ein Man-in-the-Middle lesen.
Die Frage ist also: Vor wem sollen die Daten geschützt werden?

Falls jemand noch bessere Ideen hat, immer gerne her damit

Auf den ersten Blick sieht das Konstrukt etwas merkwürdig, aber brauchbar aus. Wenn die Daten verschlüsselt übertragen werden. Unverschlüsselt übertragene Daten verschlüsselt in die Datenbank zu schreiben ist etwas ungewöhnlich. Warum werden die nicht über SSL übertragen?

MfG
Carsten

[sunside]

Hallo Carsten,

vielen Dank für Deine Antwort.

Die Private Key wird also nicht zum signieren, sondern nur zum Entschlüsseln benötigt. Falls ein Angreifer an den Key kommt, kann er also "nur "die verschlüsselten Daten lesen, aber keine Identität fälschen, weil sowieso niemand der Signatur vertraut?

Genau. Wobei ich diesen "nur"-Fall eben auch gerne ausschliessen will.

Übertragung per GET oder POST? [...] Die Frage ist also: Vor wem sollen die Daten geschützt werden?

Passwörter grundsätzlich per POST, ja. Und über eine SSL-verschlüsselte Verbindung werden die Daten jetzt auch schon übertragen.

Das Risiko, das verringert werden soll, bezieht sich aber nicht auf den Übertragungsweg - daran würde sich nichts ändern - sondern auf das Speichern der Daten auf dem Server.

Sagen wir z.B., es handelt sich - fast schon ein Worst Case Szenario - um Kreditkartendaten in einer Shared Hosting-Umgebung, und es ist grundsätzlich nicht auszuschliessen, dass andere Benutzer (fremde Admins sowieso) auf dem Server an die Dateien/Datenbank kommen.

Unverschlüsselt übertragene Daten verschlüsselt in die Datenbank zu schreiben ist etwas ungewöhnlich. Warum werden die nicht über SSL übertragen?

Werden sie, sowohl bei der Ein- als auch bei der Ausgabe; hatte das nur vergessen zu erwähnen. Möchte aber gar nicht wissen, wie viele Leute sich die Daten aus ihren SSL-verschlüsselt übertragenen Formularen per unverschlüsselter E-Mail zuschicken lassen...

Also ist der Schutz des Private Key durch so eine Passphrase mit polynomiellem Aufwand nicht zu knacken, vorausgesetzt dass die Implementierung in OpenSSL fehlerfrei ist? Das ist ja der einzige zusätzliche Schutz, den diese Lösung bietet.

Danke und viele Grüsse
Sunside

[Carsten Eilers]

Hallo Sunside,

Sagen wir z.B., es handelt sich - fast schon ein Worst Case Szenario - um Kreditkartendaten in einer Shared Hosting-Umgebung, und es ist grundsätzlich nicht auszuschliessen, dass andere Benutzer (fremde Admins sowieso) auf dem Server an die Dateien/Datenbank kommen.

Davon würde ich bei Shared Hosting ausgehen, z.B. Directory Traversal wird ja immer mal gerne irgendwo eingebaut.

Werden sie, sowohl bei der Ein- als auch bei der Ausgabe; hatte das nur vergessen zu erwähnen. Möchte aber gar nicht wissen, wie viele Leute sich die Daten aus ihren SSL-verschlüsselt übertragenen Formularen per unverschlüsselter E-Mail zuschicken lassen...

Ich schätze mal so zwischen 99,990% und 99,990%, Rundungsfehler inbegriffen. ;-)

Also ist der Schutz des Private Key durch so eine Passphrase mit polynomiellem Aufwand nicht zu knacken, vorausgesetzt dass die Implementierung in OpenSSL fehlerfrei ist? Das ist ja der einzige zusätzliche Schutz, den diese Lösung bietet.

Das scheint noch niemand probiert zu haben. Jedenfalls habe ich nichts darüber gefunden. Weder ein Knackprogramm noch eine Untersuchung.

Eine Verschlüsselung erhöht auf jedem Fall den Aufwand für einen Angreifer, selbst wenn der vollen Zugriff aufs System hat. Und falls jemand z.B. über Directory Traversal alle DB-Dateien kopiert fehlt ihm der Private Key.

Ich würde die Daten verschlüsseln und eine möglichst gute Passphrase wählen.

MfG
Carsten