DBMemo Text vorm speichern verschlüsseln

[Perlsau]

Zitat von Iwo Asnet:

Nein, das ist Verschlüsselung einzelner Felder.

Code:

select * from MyTable where Decrypt(CryptedField,MyKey) Like '%foo%';

Dann meinst du sicher das hier:

"Third, since Firebird is open source, you can alter the code that reads and writes pages to the disk to encrypt and decrypt them. Of course, you would have to find a suitable way for client to send the decryption key to the engine. Please note that this means that all users use the same key."

Frei übersetzt heißt das wohl:
"Drittens kann man, seit Firebird Open Source ist, den Code ändern, der die DB-Seiten auf Datenträger liest und schreibt, indem man dort eine Ver- und Entschlüsselung implementiert. Natürlich muß man dann noch eine geeignete Methode finden, den Schlüssel zum Entschlüsseln an die Engine (damit ist wohl die DB-Engine gemeint) zu senden. Hinweis: Das bedeutet, daß alle Benutzer denselben Schlüssel verwenden."

Keine Ahnung, womit Firebird entwickelt wurde und wird und wie ich selber erfolgreich am Firebird-Code rumfummeln sollte ... Ich kann leider nur Delphi, und damit bin ich im Grunde voll ausgelastet – Genies und jungen frischen Gymnasiasten und Akademikern mag es sicher anders ergehen ...

Die anderen beiden Methoden, die auf der von dir verlinkten Seite stehen, sind auch nicht gerade das Gelbe vom Ei:

"One is to encrypt all the data on the client before saving to database columns, and decrypt while reading."

Frei übersetzt:
"Eine [Lösung] wäre die Verschlüsselung der Daten in der Client-Anwendung vor dem Speichern in und die Entschlüsselung beim Lesen aus der Datenbank."

"Second solution is to encrypt the filesystem where Firebird database is stored. There are cross-platform solutions like TrueCrypt, EncFS or BestCrypt that do this ..."

Frei übersetzt:
"Die zweite Lösung besteht darin, das Dateisystem, auf dem die Datenbank sich befindet, zu verschlüsseln. Es gibt Lösungen für mehrere Betriebssysteme, die da wären TrueCrypt, EncFS oder BestCrypt ..."

[Iwo Asnet]

Nein, ich meine "One is to encrypt all the data on the client before saving to database columns, and decrypt while reading."

Man muss doch nur eine UDF-DLL für Firebird mit den Routinen Encrypt/Decrypt erstellen und registrieren. Und wie man eine UDF-DLL für Firebird schreibt, steht hier

http://www.firebirdsql.org/en/writin...base-firebird/

Und hier ist sogar ein Beispiel, das Du fast 1:1 übernehmen könntest (Must halt nur Encrypten und Decrypten einbauen).

[Perlsau]

Zitat von Iwo Asnet:

Nein, ich meine "One is to encrypt all the data on the client before saving to database columns, and decrypt while reading."

Man muss doch nur eine UDF-DLL für Firebird mit den Routinen Encrypt/Decrypt erstellen und registrieren. Und wie man eine UDF-DLL für Firebird schreibt, steht hier

http://www.firebirdsql.org/en/writin...base-firebird/

Und hier ist sogar ein Beispiel, das Du fast 1:1 übernehmen könntest (Must halt nur Encrypten und Decrypten einbauen).

Okay, auch wenn ich das wohl eher nicht ausprobieren werde: Der Knackpunkt, daß man die verschlüsselten Strings in der Firebird-DB nicht durchsuchen kann, bleibt aber doch bestehen, wenn ich das richtig verstanden habe, oder? Bei einer guten Verschlüsselung wird ja nicht jedes Wort einzeln verschlüsselt und ergibt somit auch nicht immer denselben verschlüsselten String, sonst wäre die Verschlüsselung ja relativ leicht zu knacken ...

[DeddyH]

Erst entschlüsseln, dann durchsuchen, so wird es ja auch im Beispiel weiter vorn gemacht. Abgesehen von der Performance sehe ich persönlich da jetzt kein Problem.

[Perlsau]

Zitat von DeddyH:

Erst entschlüsseln, dann durchsuchen, so wird es ja auch im Beispiel weiter vorn gemacht. Abgesehen von der Performance sehe ich persönlich da jetzt kein Problem.

Wenn ich das richtig verstehe, manipuliert diese UDF-Dll den Speicherbereich, in den Firebird nach dem Auslesen eines Zellen-Inhalts (eines Wertes aus einer Spalte) diesen Wert abgelegt hat? Die Methoden z.B. zum Vergleichen von Zellinhalten mit einem gegebenen Parameterwert (z.B. bei einer Where-Klausel) finden ja irgendwo in der Firebird-Engine statt ... aber lassen wir das, ich warte lieber auf das stable Release von Firebird 3 ...

[Iwo Asnet]

Zitat von DeddyH:

Abgesehen von der Performance sehe ich persönlich da jetzt kein Problem.

Na, das "Problem" ist, das die Sicherheitsstufe nicht erhöht wird. Die Daten sind zwar verschlüsselt, aber der Verschlüsselungsschlüssel ist im SELECT-Statement im Klartext sichtbar.

Allerdings könnte man sich da auch perverse Geschichten ausdenken, um das nicht so offensichtlich zu machen. Man könnte z.B. der Crypt-UDF-DLL über andere Kanäle (SSL) einen Schlüssel übergeben. Aber auch das ist nur ein 'security by obscurity', denn da die UDF meines Wissens nach für jeden Sichtbar ist, könnte ein Angreifer in jedem Fall (sofern ein Feldinhalt im Klartext bekannt ist) den Schlüssel brutfortzen (Achtung! Wechstaben nicht verbuckseln!).

Als Spielerei, und um Kunden zu beeindrucken, sollte das aber allemal reichen. Nebenbei ist es auch halbwegs sicher, also man kann nicht einfach in die Daten reinglotzen.

[Perlsau]

Zitat von Iwo Asnet:

Zitat von DeddyH:

Abgesehen von der Performance sehe ich persönlich da jetzt kein Problem.

Na, das "Problem" ist, das die Sicherheitsstufe nicht erhöht wird. Die Daten sind zwar verschlüsselt, aber der Verschlüsselungsschlüssel ist im SELECT-Statement im Klartext sichtbar.

Allerdings könnte man sich da auch perverse Geschichten ausdenken, um das nicht so offensichtlich zu machen. Man könnte z.B. der Crypt-UDF-DLL über andere Kanäle (SSL) einen Schlüssel übergeben. Aber auch das ist nur ein 'security by obscurity', denn da die UDF meines Wissens nach für jeden Sichtbar ist, könnte ein Angreifer in jedem Fall (sofern ein Feldinhalt im Klartext bekannt ist) den Schlüssel brutfortzen (Achtung! Wechstaben nicht verbuckseln!).

Als Spielerei, und um Kunden zu beeindrucken, sollte das aber allemal reichen. Nebenbei ist es auch halbwegs sicher, also man kann nicht einfach in die Daten reinglotzen.

Eine andere Möglichkeit wäre die Verwendung von virtuellen Tabellen, wenn es sich nicht um allzu große Datenbestände handelt. Ich hab diese Technik mal bei einem Passwort-Manager eingesetzt (da gibt's in der Regel keine Tausende von Einträgen), der mit einer Firebird-Embedded arbeitet:

Du hast in der DB alles verschlüsselt. Bei Programmstart werden virtuelle Tabellen mit den entschlüsselten Daten angelegt, um die Daten durchsuchen zu können. Bei Programmende werden die Daten der virtuellen Tabelle wieder verschlüsselt und in die ursprünglichen Tabellen zurückgeschrieben, die virtuellen Tabellen werden entfernt. Ein abschließendes Backup und Restore sorgt für eine aufgeräumte Datenbank.

Größere Firmen bzw. die gebräuchlichsten ERP-Systeme verwenden in der Regel sowieso keinen Firebird-Server, soweit ich das überhaupt beurteilen kann. Was mir bislang an Firmen-DBs untergekommen ist, war ausnahmslos nicht verschlüsselt.

[Iwo Asnet]

Die Sicherheit sollte über Benutzerkonten hinreichend geregelt sein. Verschlüsseln ist immer mit einem Performanceverlust verbunden.

Also getackerte Hosenträger zum Gürtel muss natürlich ein Crypten herhalten, aber i.A. reichen dann TrueCrypt etc. aus.