Verschlüsselung Datenbankfelder

[nchristoph]

Hallo Zusammen,

Ich werkle gerade an einer Webseite und habe da die "Blödsinninge" Idee, die Datenbankfelder zu verschlüsseln.

Ich habe schon mit hash versucht, aber die kann man ja nur vergleichen und nicht entschlüsseln und daher für Abfragen mit WHERE Klausel nicht verwendbar.
Dann habe ich noch OpenSSL Verschlüsselung versucht nur da wird empfohlen, nie den gleichen IV doppelt zu verwenden, was das entschlüsseln bzw. WHERE Klauseln sehr schwer macht.

Passwörter habe ich bereits mit Password_hash und BCRYPT gespeichert.

Wir würdet Ihr da dran gehen?

Ob es sinnvoll ist oder nicht sei dahingestellt ist auch nicht das Thema.

 

[Sprint]

Sinnvoll ist es wirklich nicht, denn so einfach mal suchen in der DB fällt damit natürlich weg. Aber gut.

Ich habe das hier für mein letztes Projekt genutzt. Da ging es zwar mehr um die Verschlüsselung von Dateien, aber sowohl die Datei als auch das jeweils kundenspezifische Kennwort wurden mit diesem Script verschlüsselt.

Wie auch immer du das handhabst, wirst du nicht um Kennwörter in Klarschrift rumkommen. Du kannst die natürlich auch wieder mit einem Masterkey verschlüsseln, aber der muß in Klarschrift vorliegen. Ich habe den damals per ionCube verpacken lassen, so daß auch bei einem direkten Zugriff auf die Datei niemand so schnell an den Masterkey kommt.

Eine weitere Möglichkeit wäre noch, die Verschlüsselung der Datenbank selbst zu überlassen. Für MariaDB gibt es z.B. eine solche Erweiterung. Ob das von deinem Provider aber schon angeboten bzw. unterstützt wird, ist im Moment noch fraglich.

 

[ComFreek]

Wie auch immer du das handhabst, wirst du nicht um Kennwörter in Klarschrift rumkommen.

Nein, das stimmt nicht. Deswegen gibt es ja gerade "password hashing".

Wir würdet Ihr da dran gehen?

Was ist dein attack model? Ohne zu wissen, gegen was du dich schützen möchtest, kann ich keine Empfehlungen geben.

 

[Sprint]

Nein, das stimmt nicht. Deswegen gibt es ja gerade "password hashing".

Was das Speichern von Login Passwörtern geht, hast du recht. Und wenn nur der jeweilige User auf seine eigenen Daten zugreift, dann ginge es, wenn das beim Login eingegebene PW dann zum Entschlüsseln der anderen Daten verwendet wird. Sollen die Daten aber ohne den jeweiligen User bzw. ganz ohne einen menschlichen Zugriff verarbeitet werden, braucht es einen Master Schlüssel in Klarschrift. Aber dazu bräuchte es mehr Infos über den Hintergrund der Anfrage.

 

[ComFreek]

@Sprint Wieso sollte man das Nutzer-PW für die Ver/Entschlüsselung von den Nutzerdaten hernehmen? Warum nicht einfach einen (kryptographisch starken) zufälligen Key wählen?

 

[Sprint]

@Sprint Wieso sollte man das Nutzer-PW für die Ver/Entschlüsselung von den Nutzerdaten hernehmen? Warum nicht einfach einen (kryptographisch starken) zufälligen Key wählen?

Die Verschlüsselung von Tabellenfeldern macht mMn ja nur Sinn, wenn jemand direkten Zugriff auf die Datenbank hat. Jedes Anwenderprogramm muß die Daten ja entschlüsselt vorliegen haben. Wer also Zugriff auf die Anwendung hat, bekommt die Daten frei geliefert.

Wo aber wird der zufällige Schlüssel abgelegt? Egal ob in der Datenbank oder in einer Datei, er liegt immer in Klarschrift vor. Und aus der Struktur oder Feldnamen einer Tabelle läßt sich schon mehr oder weniger leicht das Feld mit dem Kennwort herausfinden. Wenn ich jetzt aber das Nutzerkennwort hernehme, lassen sich die Felder nicht entschlüsseln, weil ich nicht an das echte Kennwort komme. Denn aus einem Hash läßt sich das nicht rausrechnen.

 

[nchristoph]

@ComFreek
Schützen will ich eigentlich nur die Daten für den Fall, das jemand an die Datenbank kommt.
Das ich vorher noch einige Layer brauche, die den Zugriff verhindern bzw. zumindest stark vermehren ist mir bewusst.

@Sprint
An das Passwort als IV bzw. Schlüssel habe ich natürlich auch gedacht ABER was ist, wenn der Benutzer sein Passwort ändert. Reintheoretisch müsste ich alles mit dem alten PW auslesen und entschlüsseln und mit dem neuen wieder verschlüsseln und in die Datenbank speichern. Ist nicht gerade Effizient. Dein Link ist auch das, was ich schon probiert habe nur wie du bereits gesagt hast ist dann Sense mit einfacher DB Arbeit.

Da es auch um PM's geht, die der Empfänger lesen können soll, müsste es fast so was wie Private und Public key alá RSA sein nur da wüsste ich nicht, wie ich das mit PHP umsetzen sollte.

Eine andere Idee, die ich noch habe ist das MySQL Native AES_ENCRPYT /AES_DECRYPT.

Ist ein ziemlich umfangreiches Thema, wenn man es 99,9% sicher haben will.

Aktuell habe ich folgende Sicherheitsvorkehrungen

HTTPS(Besser als gar nichts)
MySQL Verschlüsselung mit SSL verschlüsselt(Ich weis, eher Sinnfrei weil die Kommunikation beim selben Server über einen Socket geht und nur sinnvoll bei externen Servern wirklich sinnvoll ist)

PHP mässig:

Jede ID wird mittels intval geprüft und zusätzlich noch durch Filter_var und Striptags gefiltert und bereinigt.
Für die Datenbankabfragen habe ich Prepared statements bzw. Myslqi_Real_Escape_String im Einsatz.
Das Passwort wird gesaltet und dann mit password_hash gehasht.

Das ist so ziemlich alles, was mir einfällt was ich machen kann zum Absichern.

Vielleicht hat hier der eine oder andere auch noch ein paar Tips.

 

[ComFreek]

und zusätzlich noch durch Filter_var und Striptags gefiltert und bereinigt.

Alles nach intval ist unnötig. intval liefert immer ein int zurück, was möchtest du da noch tun?

Das Passwort wird gesaltet und dann mit password_hash gehasht.

Ist dein Salt user-spezifisch?

Schützen will ich eigentlich nur die Daten für den Fall, das jemand an die Datenbank kommt.

Meinst du, dass jemand SQL Queries ausführen kann? Falls ja, kannst du auch mal dir Pepper ansehen: Pepper (cryptography) - Wikipedia.

 

[Sprint]

An das Passwort als IV bzw. Schlüssel habe ich natürlich auch gedacht ABER was ist, wenn der Benutzer sein Passwort ändert. Reintheoretisch müsste ich alles mit dem alten PW auslesen und entschlüsseln und mit dem neuen wieder verschlüsseln und in die Datenbank speichern. Ist nicht gerade Effizient.

Das ist richtig, aber wie oft kommt das vor? Ich habe sowas ähnliches auch schon mal machen müssen, als ich die PW Verschlüsselung selbst geändert hatte. Ist von Aufwand her gering und wird von der zeitlichen Seite her wahrscheinlich gar nicht bemerkt. Und es müssen ja auch nicht alle Daten verschlüsselt werden.

Andererseits müssen wir doch mal überlegen, wie jemand an einen DB Dump kommt. Da die ja hoffentlich nicht so offen auf deinem Webspace rumliegen, muß er die Zugangsdaten zu deinem Serverlogin haben. Und dann hast du ein ganz anderes Problem. Denn dann kommt er auch an deine PHP Dateien und kann die in aller Ruhe zerlegen und analysieren. Eventuelle Pepper oder OpenSSL Kennwörter liegen da ja auch irgendwo offen im Quelltext rum. Eine Verschlüsselung mit ionCube macht das zumindest deutlich schwerer.

Viel eher ist meiner Ansicht nach ein Einbruch über unsichere Formulare oder vergessene Testprogramme usw. Ich würde eher da ansetzen und sicherstellen, daß da nichts passieren kann bzw. über geklaute Zugangsdaten eines Users nur dessen Daten abgegriffen werden können.

Bzgl. DB würde ich eher mal nachsehen, was für einen Typ Datenbank du hast und dann mal suchen, ob es dafür eine DB eigene Verschlüsselung gibt. Sprich dann mal mit deinem Provider, ob man die installieren kann.

 

[nchristoph]

Ich z.b. ändere 3 - 4 x im Jahr alle meine Passwörter.

Zurück zum Thema:

Wie meinst du über unsichere Formulare? $_POST Variablen nicht gefiltert?