Mir stellt sich gerade die Frage, in wie fern man die Datenbank sicher verschlüsseln kann, ohne jedoch die Funktionalität einzuschränken. Gute Verschlüsselungstechniken sind nämlich nicht linear, das bedeutet das man wahrscheinlich auf Suchfunktionen verzichten muss.

Mal angenommen in der DB steht folgenders:

Herr Prof. Dr. Max Mustermann
Musterweg 44
44444 Musterstatt
Musterland

nach der Chiffrierung steht da:

564gvf5rag23z6Fdahd56gfFhaeWdhfdca5DbggrSewgds8etu gRTrte3shSre3
7Sfseasrrztz523ggrtwgg4wfHgssetHgsrZHf3q3gfSdhjgzh huzkhtJujhJdrFGj6
744fGqw3yGqH4Stfw3SqqasVyXyyCVj23ufvaJhdtz854FhkMb DMlOzhjSDsD
Fgr338auz1

nun habe ich eine Suchfunktion die mit ... LIKE '%$suchstring%' arbeiten soll. Man müsste nun den Suchstring chiffrieren damit es bei der Suche nach "Max Mustermann" einen match geben kann - was z.b. bei linearer monoalphabetischer Substitution (exrem unsicher) gehen müsste. Wie ist das aber bei nonlinearer polyalphabetischer Verschlüsselung?

Dann noch eine Frage, die ich mal so in den Raum stellen möchte: Bringt es überhaupt etwas, sich um die Verschlüsselung der DB gedanken zu machen? Gedanke: Wenn jemand an meine DB kommt, kommt er auch an meine Skripte. Und damit hat er dann auch das Werkzeug zum dechiffrieren. Was spricht dafür, die DB zu verschlüsseln, und was dagegen?

Wie macht ihr das - verschlüsselt ihr eure DB? Warum? Warum nicht?

Ich freue mich über sachliche Kommentare.

Mister Ad

a) Wenn jemand an deine db kommt heisst das noch lange nicht, das er auch an deine scripte kommt
b) Verschlüsselung der DB verlangsamt eher alles mögliche - was soll es bringen?
c) Verschlüsselung macht bei einem passwort sinn, da vergleicht man aber meist direkt

Ich glaube eher, das du dir mit der Verschlüsselung steine in den Weg legst... .

Na ja, was mir u.a. Kopfschmerzen macht sind die Fälle aus der Vergangenheit, wo es Hacker immer wieder geschafft haben (weis nicht wie) die Adressdaten von grossen Firmen im Internet offenzulegen. Wäre da die DB verschlüsselt, hätte man nur den Spaghetti-Code vorgefunden.

Ein weiteres Sicherheitsrisiko besteht beim Provider selbst. Heutzutage kann man niemandem mehr trauen, und wer garantiert einem das beim Provider nicht jemand angestellt ist, der sich an den Daten der Kunden bedient um damit Geld zu verdienen. Ich bin zwar bei 1&1, habe aber trotzdem ein komisches Gefühl. Schließlich haben die Admins dort auf alles Zugriff. Ist alles nicht ausgeschlossen. Mit einer Verschlüsselung würden diesen Leuten schon mal Steine in den Weg gelegt werden.

Aber ich sehe das auch so, das man sich selbst massiv Steine in den Weg legt. Vor allem auch wenn man mal ein par Fehler in der DB hat die behoben werden müssen. Ist alles verschlüsselt, kann man die Arbeit mit dem Telnet Client in vielen Fällen knicken, wenn es nicht nur um Datenbankdesign geht sondern um Suche nach verwaisten Datensätzen etc.

Hinzu kommt, das man in vielen Fällen wohl auf BLOB anstatt auf z.B. varchar(20) zurück greifen muss, weil der Code einfach viel länger wird.

Passwörter sind MD5() verschlüsselt, aber die will man ja auch nicht durchsuchen oder irgendwo anzeigen. In dem Fall stört es nicht

Nur musste ich bisher die Erfahrung machen das Seitens der Kundschaft immer wieder nach Verschlüsselung gefragt wird. Die Leute fühlen sich einfach sicherer, wenn ihre sensiblen Daten auf dem Server nich in Klartext gespeichert werden. Aber im Moment sehe ich da noch massive Schwierigkeiten was die Umsetzung angeht, und glaube auch das die Performance spürbar darunter leidet. Bin aber kein Experte, bestimmt weis es jemand besser

Matthias959

Wenn ich mich nicht täusche kann man mitt MD5() Verschlüsselte Texte nicht wieder entschlüsseln lassen. Wäre also für eine Datenbank mit Kundendaten weniger sinnvoll.
Die Frage ist ob sich der Aufwand überhaupt lohnt. Ich kann mir nämlich nicht vorstellen das die Provider die Daten ihrer Kunden ausspähen.

das ist richtig. MD5 ist eine one-way Chiffrierung. Verschlüsselung ist das falsche Wort, da hab ich mich falsch ausgedrückt

MD5 nehme ich nur wenn ich ein Login-Passwort speichern will. Bei Eingabe des Passwortes wird auf den Input md5() angewandt damit man in der DB vergleichen kann.

Ausschließen kann man es aber auch nicht. Nach dem Prinzip: Wo kein Kläger, da kein Richter. Und wer würde es schon merken wenn seine DB ausgelesen wird und die Adressen an Spammer oder an die Konkurrenz verkauft werden. Beweisen kann man das sowieso nicht. Da liegt es nahe das man sich Gedanken zur Vorsorge macht. Beste Lösung ist wahrscheinlich immer ein eigener Server in einem Kellerverlies, der direkt an ein Backbone angeschlossen wird, aber wer kann sich das schon leisten...

tapferesschneiderlein

zur Sache mit der Suche:

Wenn du dem Hoster nicht traust, dann gibt es für dein Problem keine Lösung. Denn der Hoster kommt nicht nur an deine Datenbank, er kommt auch an dein Script, mit dem du die Daten codierst und decodierst.

Gruß
phpfan

gutes Argument... wie ist es wenn die Skripte nun kompiliert sind (z.b. Zend)?

macht das sinn? Wer Zugriff auf die DB bekommt, wendet auf die verschlüsselten Daten dann einfach das mysql-interne decode an

Thice

md5() ist eine Prüfsummen-Funktion, KEINE Verschlüsselung.

MfG Andy

__________________
kintzebros.de | KintzeBros Home Entertainment
2061. Nach dem Frieden | kurzfilm
Paula | spielfilm

stimmt. Schlüssel gibts ja nicht. Gibt es eigentlich einen Fall, wo zwei unterschiedliche strings nach md5() Anwendung den selben String ergeben? Nicht, oder? Wenn das so wäre, und die Sache eine eineindeutig (kein Tippfehler) ist, müsste es doch theretisch möglich sein den md5-String zurück in den Ursprungsstring zu bringen...