DBMemo Text vorm speichern verschlüsseln

[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%';