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

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...

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

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

MfG Andy

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...

es ist möglich das zwei verschiedene Strings wenn sie gehasht worden den gleichen hash ergeben.
Dies muss auch so sein weil egal wie lang die zu hashende Zeichenkombination ist der Hash bleibt immer gleich lang (ich mein bei md5 sinds 16 Zeichen).
Es wurden nur besher noch keine zwei Zeichenkombinationen gefunden, die den gleichen hash ergeben (obwohl einige Rechner daran arbeiten)!

Ein Chinese hat den Code letztes Jahr mal geknackt und auch Formeln dazu geliefert, mit welchen es knapp ne Stunde dauert einen Hash mit einem anderen "input" zu rekonstruieren.

Quelle?

Ein Chinese ist nämlich letztes Jahr auch in einer umgebauten Waschmaschine zum Mars geflogen - in einer Stunde. Vielleicht war's ja der selbe

richtig.
völliger quatsch. nimm die funktion 'function(x) { return x; }' mal als hashfunktion - diese gibt bei verschieden langen strings garantiert verschiedene ergebnisse zurück. es muss also nicht so sein.
guck lieber nochmal nach.
guck lieber hier auch nochmal nach.

ja, und drachen gibt's wirklich ...