DBMemo Text vorm speichern verschlüsseln

[Alterauge]

Hallo,

möchte gerne den DBMemo Text (Inhalt) vorm speichern verschlüsseln!

Delphi-Quellcode:

procedure TForm1.Timer7Timer(Sender: TObject);
var
i : integer;
s : string;
begin
  if filelistbox1.Count > 0 then
  fileListbox1.ItemIndex:=0;
 if filelistbox1.ItemIndex= 0 then
 begin
DBMemo1.Lines.LoadFromFile(filelistbox1.FileName);
MyTable1.FieldByName('Status').Text:='Eingang';
MyTable1.FieldByName('Meldung').AsString := DBMemo1.Text;
DBMemo1.Lines.SaveToFile(FormatDateTime('yyyy-mm-dd_hh-nn-ss__',now)+('MySQL')+ '.asc');
MyTable1.Post;
MyTable1.Refresh;
MyTable1.Insert;
DBMemo1.Clear;
i := 0;
while i < fileListBox1.Items.count do begin
deletefile (filelistbox1.FileName);
 inc ( i );
FileListBox1.Update;
MyConnection1.Connected:=false;
MyTable1.Active:=false;
  end;
 end;
end;

Zurzeit wird der TEXT unverschlüsselt gespeichert!
Wie könnte ich es umsetzen!
Kann ein einfacher Schlüssel sein, der auch nicht so sicher ist!
Möchte nur das der Text halt verschlüsselt ist.

Wenn ich die Daten mit einem DBGrid lese,
müssen diese natürlich wieder entschlüsselt werden.
Hier brauche ich auch eine Idee!

Danke

[Luckie]

Forensuche schon bemüht?

[Bernhard Geyer]

Nimm halt die möglichkeiten der DB http://dev.mysql.com/doc/refman/5.1/...functions.html

[Furtbichler]

Datenfelder (TField) bieten die Möglichkeit, über die OnGetText/OnSetText-Ereignisse, Verschlüsselungen transparent und Datenbankunabhängig zu implementieren.

Nachteil, die Verschlüsselung ist durch Reverse-Engineering knackbar.

[Bernhard Geyer]

Zitat:

Zitat von Furtbichler (Beitrag 1177118)

Nachteil, die Verschlüsselung ist durch Reverse-Engineering knackbar.

Weiterer Nachteil: Du kannst keine SQL mehr verwenden da ja deine DB von der Verschlüsselung nix weiss

[p80286]

Naja wenn sowas wie die Cäsar"Verschlüsselung" genutzt wird dann könnte man SQL noch nutzen. Nur was soll dieses

Zitat:

Zitat von Alterauge (Beitrag 1177104)

Kann ein einfacher Schlüssel sein, der auch nicht so sicher ist!
Möchte nur das der Text halt verschlüsselt ist.

Entweder macht man's richtig oder läßt die Finger davon.

Gruß
K-H

[Perlsau]

Zitat:

Zitat von Alterauge (Beitrag 1177104)

Hallo, möchte gerne den DBMemo Text (Inhalt) vorm speichern verschlüsseln!
Zurzeit wird der TEXT unverschlüsselt gespeichert! Wie könnte ich es umsetzen! Kann ein einfacher Schlüssel sein, der auch nicht so sicher ist! Möchte nur das der Text halt verschlüsselt ist.

Also wenn ich dich richtig verstanden habe, möchtest du den Inhalt eines Blob-Text-Feldes verschlüsseln (encode) und vor dem Anzeigen wieder entschlüsseln (decode). Weil aber DB-Memo direkt auf das entsprechende DataSource zugreift, kommst du da nur schwer ran. Ich verwende in solchen Fällen kein DBMemo, sondern ein "normales" TMemo. In der Ereignisbehandlung des entsprechenden Datasets OnAfterScroll kannst du dann die Entschlüsselung starten.

Aber bevor ich dir das jetzt lang und breit auseinandersetze, stelle ich hier lieber ein Beispiel-Projekt rein, das ich einmal für einen skeptischen Kunden angefertigt hatte, der meinte, MS-Access sei als Datenbank nicht sicher genug (siehe Anhang).

Zitat:

Zitat von Alterauge (Beitrag 1177104)

Wenn ich die Daten mit einem DBGrid lese, müssen diese natürlich wieder entschlüsselt werden. Hier brauche ich auch eine Idee!

Da machst du das genauso wie beim Memo: Kein DBGrid verwenden, sondern ein TStringGrid und in der Ereignisbehanldung für OnAfterScroll die Befüllung des StringGrid auslösen.

P.S.: Ich verwende zum Ver- und Entschlüsseln TJvVigenereCipher aus der Jedi-Komponentenpalette JvEncrypt, Compress.

[Furtbichler]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1177124)

Weiterer Nachteil: Du kannst keine SQL mehr verwenden da ja deine DB von der Verschlüsselung nix weiss

Du meinst bei Reports?

Zitat:

Zitat von Perlsau (Beitrag 1177137)

...in der Ereignisbehanldung für OnAfterScroll die Befüllung des StringGrid auslösen.

Gefällt Dir OnGetText/OnSetText nicht?

[Perlsau]

Zitat:

Zitat von Furtbichler (Beitrag 1177140)

Du meinst bei Reports?

Ich glaube, er meint, daß man z.B. keine WHERE-Klausel mehr verwenden kann, weil man ja nicht weiß, wie die verschlüsselten Daten in der DB aussehen. Aber ich meine, man kann doch, indem man nämlich den Parameter z.B. in der WHERE-Klausel zuvor verschlüsselt. Danach müßte die DB den korrekten Wert finden ...

Zitat:

Zitat von Furtbichler (Beitrag 1177140)

Gefällt Dir OnGetText/OnSetText nicht?

Stimmt, wäre auch eine Möglichkeit ...

[Furtbichler]

Zitat:

Zitat von Perlsau (Beitrag 1177141)

Ich glaube, er meint, daß man z.B. keine WHERE-Klausel mehr verwenden kann, weil man ja nicht weiß, wie die verschlüsselten Daten in der DB aussehen. Aber ich meine, man kann doch, indem man nämlich den Parameter z.B. in der WHERE-Klausel zuvor verschlüsselt. Danach müßte die DB den korrekten Wert finden ...

Na, das Problem ist ja generell, das man die Daten des Feldes nur mit spezieller Software verwenden kann.

Es ist generell nicht leicht, in einem verschlüsselten Text einen anderen zu finden, wenn die Verschlüsselung nicht trivial ist, denn ein Wort XY wird in einem Text anders verschlüsselt als wenn das Wort solo verschlüsselt würde.

Denk einfach mal an einfache XOR-Verschlüsselung mit einem Key:

[Perlsau]

Zitat:

Zitat von Furtbichler (Beitrag 1177143)

Na, das Problem ist ja generell, das man die Daten des Feldes nur mit spezieller Software verwenden kann.

Das ist doch kein Problem, sondern Absicht ?!?

Zitat:

Zitat von Furtbichler (Beitrag 1177143)

Es ist generell nicht leicht, in einem verschlüsselten Text einen anderen zu finden, wenn die Verschlüsselung nicht trivial ist, denn ein Wort XY wird in einem Text anders verschlüsselt als wenn das Wort solo verschlüsselt würde.

Da muß ich dir allerdings zustimmen: Vielleicht könnte man ja auch die entschlüsselten Daten im Arbeitsspeicher spiegeln und nur bei Änderungen an den Daten im Speicher in die Datenbank zurückschreiben. Das ließe sich sicher irgendwie mit einem Clientdataset lösen ...

Zitat:

Zitat von Furtbichler (Beitrag 1177143)

Denk einfach mal an einfache XOR-Verschlüsselung mit einem Key:

Ich glaube, der TjvCipher macht was Ähnliches ...

[Bernhard Geyer]

Zitat:

Zitat von Perlsau (Beitrag 1177141)

Aber ich meine, man kann doch, indem man nämlich den Parameter z.B. in der WHERE-Klausel zuvor verschlüsselt. Danach müßte die DB den korrekten Wert finden ..

Und was machst du mit Like oder SoundEx-Abfragen?

[Perlsau]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1177147)

Zitat:

Zitat von Perlsau (Beitrag 1177141)

Aber ich meine, man kann doch, indem man nämlich den Parameter z.B. in der WHERE-Klausel zuvor verschlüsselt. Danach müßte die DB den korrekten Wert finden ..

Und was machst du mit Like oder SoundEx-Abfragen?

Die kann ich dann natürlich nicht verwenden. Mein Verschlüsselungskonzept ist zugegebenermaßen unausgegoren, weil ich das eigentlich noch nie benötigt habe außer für Passwort- und Username-Endoding ...

[Iwo Asnet]

Ich persönlich würde die Verschlüsselungsmöglichkeiten der Zieldatenbank verwenden. Es gibt kaum Gründe, die dagegensprechen. Wenn man unterschiedliche RDBMS unterstützen möchte, muss man eine Zwischenschicht einziehen, die die spezielle SQL-Syntax für das Ver-/Entschlüsseln bereitstellt und u.U. auf die bequeme TxTable-Komponente verzichten.

[Perlsau]

Zitat:

Zitat von Iwo Asnet (Beitrag 1177193)

Ich persönlich würde die Verschlüsselungsmöglichkeiten der Zieldatenbank verwenden. Es gibt kaum Gründe, die dagegensprechen. Wenn man unterschiedliche RDBMS unterstützen möchte, muss man eine Zwischenschicht einziehen, die die spezielle SQL-Syntax für das Ver-/Entschlüsseln bereitstellt und u.U. auf die bequeme TxTable-Komponente verzichten.

Geht aber auch nur, wenn deine Datenbank Verschlüsselung unterstützt. Bei Firebird und bei MS-Access geht das nicht. Da mußt du dir dann was anderes einfallen lassen ...

[Iwo Asnet]

Bei Firebird kann man das per UDF erledigen, Access güldet nicht (geht aber, zumindest die ganze DB, ab 2007). :mrgreen:

[mkinzler]

Vulcan kann Verschlüsselung und FireBird 3 wird es wohl auch können, wenn es irgendwann mal kommt. Aber es ist ja bald wieder September :mrgreen:

[Perlsau]

Zitat:

Zitat von Iwo Asnet (Beitrag 1177220)

Bei Firebird kann man das per UDF erledigen,

Du meinst Dateiverschlüsselung ...

Zitat:

Zitat von Iwo Asnet (Beitrag 1177220)

Access güldet nicht (geht aber, zumindest die ganze DB, ab 2007). :mrgreen:

Was glaubst du, wie häufig ich erlebe, daß Kleinunternehmer, die sich gerade mal mit Access auskennen, darauf bestehen, daß ich eine Datenbank-Anwendung entwickle, die ebenfalls auf Access basiert?

Doch ist die Dateiverschlüsselung bei Access für die Katz, wenn das Passwort geknackt wird, wozu es bereits diverse Tools gibt.

Bin mal gespannt auf Firebird 3 ...

[mkinzler]

http://www.firebirdsql.org/en/roadmap/

[Iwo Asnet]

Zitat:

Zitat von Perlsau (Beitrag 1177224)

Zitat:

Zitat von Iwo Asnet (Beitrag 1177220)

Bei Firebird kann man das per UDF erledigen,

Du meinst Dateiverschlüsselung ...

Nein, das ist Verschlüsselung einzelner Felder.

Code:

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

[Perlsau]

Zitat:

Zitat von Iwo Asnet (Beitrag 1177440)

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:

Zitat von Iwo Asnet (Beitrag 1177449)

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:

Zitat von DeddyH (Beitrag 1177458)

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:

Zitat von DeddyH (Beitrag 1177458)

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 :stupid: 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:

Zitat von Iwo Asnet (Beitrag 1177461)

Zitat:

Zitat von DeddyH (Beitrag 1177458)

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