MySQL verschlüsselte Spalten

Question

Angenommen, jede Zeile in einer Tabelle enthält Daten zu einem bestimmten Benutzer. Der Benutzer hat ein Passwort, um auf das System zuzugreifen.

Wie kann ich eine Datenspalte mit InnoDB verschlüsseln, so dass niemand anderes als der Benutzer, der Daten ist, die Daten lesen kann? Ich dachte an etwas wie die Verwendung einer der MySQL-Verschlüsselungsfunktionen (zB AES) mit einem Schlüssel basierend auf einem Hash, der aus dem Passwort des Benutzers berechnet wurde.

Hat jemand irgendwelche Hinweise, wie ich das tun könnte? Bin ich auf dem richtigen Weg?

Eine der Antworten unter

Das Problem Kennwort des Benutzers zu modifizieren, beinhaltet die Umschlüsselung den Benutzerschlüssels mit Hilfe des neuen Passwortes, das gerade viel mehr nach vorne als die ganzen Reihe von Benutzerdaten erneut zu verschlüsseln das kann beliebig groß sein. Der Benutzerschlüssel bleibt über die Lebensdauer der Benutzerdaten im System gleich.

Wie hilft das? Angenommen, das Passwort lautet pass1. Und es gibt eine Reihe von Datensätzen, die mit einem daraus generierten Schlüssel verschlüsselt sind. Wenn der Benutzer das Passwort jetzt auf pass2 zurücksetzt, kann ich die Daten, die mit pass1 verschlüsselt wurden, nicht entschlüsseln. Im Falle, dass ein Benutzer das Passwort vollständig vergessen hat, sind alle seine verschlüsselten Daten verloren.

Answer 1

Ich weiß nicht, ob es viel Sinn bei der Verschlüsselung von Daten mit Benutzer-Passwort-Hash, vor allem, wenn Sie Hash selbst in der Datenbank halten. In diesem Fall kann jeder, der auf die verschlüsselten Daten zugreifen kann, auch auf den Passwort-Hash zugreifen und die Daten entschlüsseln.

Ein anderer Ansatz wäre die Verschlüsselung der Daten mit dem anwendungsspezifischen Schlüssel, der mit einigen benutzerspezifischen Daten gesalzt wird. Sie stehen jedoch vor einem anderen Problem: Wie kann der Anwendungsschlüssel sicher gespeichert werden? Zu dieser Frage weiß ich keine einfache Antwort, aber es in Ihrem Quellcode zu behalten ist wahrscheinlich gut genug, wenn Sie befürchten, dass Ihre Datenbankdaten kompromittiert werden können, aber nicht der Quellcode selbst, z. wenn Ihre Datenbank extern gespeichert ist (denken Sie an Amazon S3). Der App-Schlüssel mit dem Benutzerpasswort zu salzen hilft, wenn Sie nur den Hash-Wert des Passworts in der Datenbank behalten, aber einen weiteren Sicherheitsfehler einführen können: Sie müssen das Benutzerpasswort in der Anwendungssitzung in Klartext halten.

Als technische Lösung ist es sehr einfach und sample code is available. Man könnte es wie folgt ändert die Daten mit der Anwendung Passwort mit Passwort-Hash gesalzen zu verschlüsseln:

INSERT INTO secure_table VALUES (
    1, 
    AES_ENCRYPT(
    'plain text data', 
    CONCAT(@application_password, @user_password)) 
); 

In jedem Fall würden Sie Ihre Anwendung Passwort speichern müssen irgendwo so glaube ich nicht, dass es ein einfacher Ansatz ist das bietet perfekte Sicherheit.

Ein weiterer Ansatz, den ich mir vorstellen kann, besteht darin, den Benutzer nach einer kurzen PIN zu fragen, die Sie als Verschlüsselungsschlüssel verwenden könnten. Die PIN wird nicht in der Datenbank gespeichert, aber müssen Sie bei jedem Zugriff auf ihre Daten nach dem Benutzer fragen.

Und natürlich müssen Sie an die Machbarkeit der Verschlüsselung denken. Sie können es nicht indexieren oder ohne Entschlüsselung durchsuchen. Es ist wahrscheinlich für eine begrenzte Menge von Daten (z. B. Kreditkartennummer) erforderlich, aber ich würde nicht zu weit gehen.

Answer 2

Ich glaube nicht, dass dies der beste Ansatz ist, es sei denn, Sie erzwingen, dass Benutzer ihr Kennwort nie ändern können, oder Sie haben die Möglichkeit, jedes Mal, wenn ein Benutzer sein Kennwort ändert, alles neu zu verschlüsseln.

Answer 3

Sie könnten einen anderen Schlüssel zum Verschlüsseln/Entschlüsseln benutzerspezifischer Daten speichern, die beim Erstellen eines neuen Benutzers generiert werden könnten. Nennen wir diesen neuen Schlüssel für den Benutzer. Dieser Benutzerschlüssel sollte ebenfalls in der Datenbank verschlüsselt sein und der direkteste Ansatz wäre, ihn mittels des Benutzerpasswortes oder anderer Daten zu verschlüsseln, die das Passwort bildeten (wie das Passwort und die Erstellungs-/Änderungszeit usw.).

Ich würde in Benutzersitzung den entschlüsselten Benutzer-Schlüssel, um auf Benutzerdaten zu jeder gewünschten Zeit innerhalb der Sitzung zugreifen. Das Problem der Änderung des Benutzerpassworts besteht darin, den Benutzerschlüssel mit Hilfe des neuen Passworts erneut zu verschlüsseln, was sehr viel einfacher ist als das erneute Verschlüsseln der gesamten Gruppe von Benutzerdaten, die beliebig groß sein können. Der Benutzerschlüssel bleibt über die Lebensdauer der Benutzerdaten im System gleich.

Natürlich kann diese Methode nur verwendet werden, wenn die Authentifizierung ausgeführt wird, indem das tatsächliche Benutzerkennwort beim Anmelden an den Server gesendet wird, da die Datenbank nur wünschenswerterweise den Hash des Kennworts enthält.

Answer 4

Angenommen, das Passwort lautet pass1. Und es gibt eine Reihe von Datensätzen, die mit einem daraus generierten Schlüssel verschlüsselt sind. Wenn der Benutzer nun das Passwort zurückgesetzt pass2, habe ich keine Möglichkeit, die Daten zu entschlüsseln, die verschlüsselt wurde pass1 mit

Der Schlüssel müßte in einer umkehrbar Weise verschlüsselt werden, so dass es pass1 entschlüsselt werden konnte und mit pass2 erneut verschlüsselt werden.

Fassen wir zusammen:

in der Datenbank gespeichert ist: die Einweg-verschlüsselte Passwort (für die Kennwortüberprüfung), der Verschlüsselungsschlüssel für andere Daten, reversibel mit dem klaren Passwort verschlüsselt (oder jedenfalls die Passwort verschlüsselt auf eine andere Weise als in der Datenbank gespeichert) und die anderen Daten, die reversibel mit dem eindeutigen Verschlüsselungsschlüssel verschlüsselt wurden.

Immer wenn Sie die anderen Daten benötigen, müssen Sie das klare (oder anders als in der Datenbank gespeicherte) Passwort haben, den Verschlüsselungsschlüssel lesen, ihn mit dem Passwort entschlüsseln und damit die anderen Daten entschlüsseln.

Wenn ein Passwort geändert wird, wird der Verschlüsselungsschlüssel mit dem alten Passwort entschlüsselt, mit dem neuen Passwort verschlüsselt und gespeichert.

Answer 5

Um eine der in der Frage genannten Antworten zu klären: "Benutzer/App-Schlüssel" ist ein zufällig generierter privater Schlüssel, der zum Verschlüsseln der Daten verwendet wird. Der private Schlüssel ändert sich nie (es sei denn, er ist kompromittiert). Sie verschlüsseln und speichern den privaten Schlüssel mit einem Passwort. Da der private Schlüssel viel kleiner als die Daten ist, ist es viel billiger, das Passwort zu ändern: Sie entschlüsseln einfach den privaten Schlüssel mit dem alten Passwort und verschlüsseln ihn erneut mit dem neuen Passwort.

Answer 6

Wenn Sie ohne Benutzerinteraktion auf die Daten zugreifen müssen (z. B. für die Datenbankmigration), haben Sie nicht den Schlüssel zum Entschlüsseln.

Answer 7

Für Daten, die nicht benutzerspezifisch (global) sind, könnten Sie vielleicht eine Kombination aus symmetrischer und asymmetrischer Verschlüsselung verwenden.Sie könnten ein extra password Feld haben, das alle Benutzer eingeben müssen, damit auch wenn ein Benutzer sein Passwort ändert, die globalen Daten weiterhin für andere Benutzer mit unterschiedlichen Passwörtern verwendbar sind.

Die extra password kann im Quellcode mit einem anderen salt-like string bitweise xoriert werden. Zusammen kann es den symmetrischen Schlüssel bilden, um eine private key zu entschlüsseln, die in der Datenbank gespeichert wird (die sich nie ändert). Nachdem private key mit der extra password entschlüsselt wurde, kann der private Schlüssel alle Daten in der Datenbank entschlüsseln und read. Der private Schlüssel kann als Sitzungsvariable gespeichert werden.

Die public key, wie der Name schon sagt, kann als Klartextzeichenfolge in der Datenbank gespeichert werden. Wenn Sie write in db benötigen, verwenden Sie den öffentlichen Schlüssel zum Verschlüsseln der Daten.

Sie können routinemäßig den Anwender mit einer neuen extra password liefern und erneut verschlüsseln die statischen private key, gefolgt von einer XOR-Verknüpfung mit salt-like string.

Wenn die Daten benutzerspezifische Daten sind und nicht für andere Benutzer bestimmt sind, können Sie das Kennwort des Benutzers ohne das Feld für zusätzliche Kennwörter verwenden, um den privaten Schlüssel zu verschlüsseln. Der Administrator könnte eine weitere Kopie der privaten Schlüssel für bestimmte Benutzer haben, die mit seinem Passwort entschlüsselt werden können.