Inoffizielles deutsches Xbase-Forum

Wenn es hier nicht hingehört bitte verschieben.
Ich möchte/muss Telefonnummern und Mail Adressen auf unserem Server speichern.
Die Daten sollten ja verschlüsselt werden (Achtung: kein SQL und kein ADS).
Was wäre die beste Methode dafür ?

Ich würde das gute alte Crypt nehmen, in Verbindung mit einem möglichst langen Passwort, ggf. ergänzt um ein datensatzbezogenes "Salz" (also ein Add-On zum Passwort, das nur für diesen Eintrag gilt, so dass das Passwort je Datensatz anders ist). Das ist zwar nicht übermäßig sicher, aber man muss schon ein wenig Energie aufwenden, um das zu dechiffrieren. Ergänzend würde ich das Ergebnis in Hex umwandeln und so speichern.

Die Hashes, die man auch mit Xbase++ in sehr sicherer Form erzeugen kann, dienen nur der Ein-Weg-Verschlüsselung. Man kann also prüfen, ob eine Eingabe dem verschlüsselten Datum entspricht, aber aus dem verschlüsselten Datum nicht mehr das Original restaurieren. Weil es eigentlich kein verschlüsseltes Datum ist, sondern eben nur ein Hash - ein Wert, der u.a. aus dem Datum erzeugt wurde.

Ergänzung: Alaska hat das im April-Newsletter thematisiert und dafür drei Wege vorgeschlagen: RDP (App remote zur Verfügung stellen), die PGDDBE und Impersonation (einfach mal hier im Forum suchen, habe ich erklärt). Meiner Erinnerung nach kann man außerdem DBFs (aber nur FOX) AES-verschlüsseln, out of the box. Aber für einzelne Felder in einer Tabelle würde ich tatsächlich wie oben erläutert verfahren.

Tom,
Danke an Crypt habe ich auch schon gedacht.
Schade das Xdot Crypt nicht kennt.

Hallo Freunde,
eine Frage, die mich schon länger interessiert:
Gibt es eine Verpflichtung zur Verschlüsselung von Daten nach DSGVO.

LG
Otto

Hallo, Klaus.

Du musst Xdot einfach nur mit den Tools (xbtbase1.lib/xbtbase2.lib) verlinken, als #pragma in der XDOT.PRG oder direkt in der XPJ, dann kann der auch Crypt(). Wenn die XbTools mit Deiner Anwendung verlinkt sind, kann DC_Dot() das auch, weil DC_Dot alle nichtstatischen Funktionen kennt, die Deine Anwendung auch kennt.

Hallo, Otto.

Nein, es gibt keine explizite Verpflichtung zur Verschlüsselung bzw. verschlüsselten Speicherung personenbezogener Daten. Der Dateninhaber (also Dein Softwarenutzer) muss nur technische und organisatorische Maßnahmen (TOMs) treffen oder treffen lassen, um diese Daten gegen Angriffe und Entwendung zu schützen, und dazu kann gehören, dass sie grundsätzlich verschlüsselt werden, aber es gibt auch andere Mechanismen, die den Zugang zu diesen Daten so erschweren, dass Datenlecks unwahrscheinlich(er) werden. Etwa die Absicherung der Infrastruktur, das vollständige Sperren der Datenbank für Zugriffe außerhalb der Anwendung, die wiederum so abgesichert ist, wie nur vorstellbar usw. usf. Verschlüsselung ist eines von vielen Mitteln, aber eine Verpflichtung besteht nicht. Sollte es aber zu einem Datenproblem kommen, kann es passieren, dass die Strukturen untersucht werden, und dass jemand feststellt, dass man die Daten aus Deiner Anwendung einfach so gut wie klarschriftlich mitgehen lassen kann, indem man eine DBF kopiert, die in einem für jedermann sichtbaren Verzeichnis auf dem Server liegt. Nicht die Wahl der Mittel ist vorgeschrieben, aber ihre Wirkung.

Hallo Tom,
vielen Dank.
Interessant finde ich deinen Vorschlag mit dem 'datensatzbezogenen "Salz"'.

Mit freundlichem Gruß
Otto

Tom,
leider bringt Crypt mir ein falsches Ergebnis.
Laut Hilfe The function Crypt() encrypts or decrypts a string using the same password.

? crypt("12345678", "87654321")
? crypt("SÐz¦Îaþü", "87654321")

Als Ergebnis bekomme ich
SÐz¦Îaþü -> im Original (Dot Window) OEM, hier wohl Ansi, deshalb anders als im Dot
123P5678 -> müsste 12345678 sein

Wenn Deine Anwendung auf OEM läuft, und Du rufst DC_Dot() auf, erfolgt eine Vor-Rückwärts-Konvertierung OEM-ANSI-OEM. Alles außerhalb des 7-Bit-Bereichs stimmt dann ggf. nicht mehr. Aber wenn Du das hier:
kompilierst und laufen lässt, zeigt es Dir "12345678" an. Wenn Du das Ergebnis von Crypt() speichern willst, dann wende ein StrToHex() auf das Ergebnis an - und umgekehrt, bevor Du diese Info wieder entschlüsseln willst.

Koverhage hat geschrieben: ↑Mi, 11. Aug 2021 8:46 Die Daten sollten ja verschlüsselt werden (Achtung: kein SQL und kein ADS).
Was wäre die beste Methode dafür ?

Ein verschlüsseltes Laufwerk!

Tom,
StrToHex hat den Nachteil das ich alle Feldgrößen verdoppeln müsste.
Das Ergebnis von Crypt bringt vermutlich Probleme in der DBF.

hi,

ramses hat geschrieben: ↑Do, 12. Aug 2021 7:39 Ein verschlüsseltes Laufwerk!

wohl möglich mit TPM v2.0 und Bitlocker ...

ich halte mehr von eine Crypt-Controller wo der Code nicht von Microsoft kommt ...

---

"eigentlich" müsste man auch die Datenübertragung verschlüsseln.
die Ryzen "Pro" Modell sollen sogar "innerhalb" der CPU verschlüsselt arbeiten

Hallo, Klaus.

StrToHex hat den Nachteil das ich alle Feldgrößen verdoppeln müsste.
Das Ergebnis von Crypt bringt vermutlich Probleme in der DBF.

Beides ist zutreffend. Aber es geht out-of-the-box - und wenn Du wirklich nur Telefonnummern und Mailadressen verschlüsseln willst, hält sich der Aufwand möglicherweise in Grenzen. Alternativ könntest Du mit AES herumspielen, oder mit Impersonation. Oder Du baust Dir einen eigenen, simplen Mechanismus (also eine Funktion "MyCrypt"), der im zulässigen Zeichenbereich Buchstaben und Ziffern verdreht, vertauscht oder in Abhängigkeit von irgendwas umpositioniert, aber auf eine Weise, die eben reversibel ist. Verschlüsseln heißt ja nicht, dass man irgendein anerkanntes Verfahren nutzen müsste - das hätte sogar den Nachteil, dass es ja bekannt wäre. Wenn Du was vollständig Propreitäres machst, das nicht auf den ersten bis vierten Blick zu durchschauen ist, hast Du die Sicherheitslatte schonmal etwas höher gelegt. Und Du kannst guten Gewissens behaupten, dass Du verschlüsselst.

So werde ich es vermutlich realisieren.
Danke.

Die "Caesar-Verschlüsselung" ist ein einfacher Algorithmus, den man schnell hinkriegt, und der so etwas macht. https://de.wikipedia.org/wiki/Caesar-Ve ... %BCsselung

AUGE_OHR hat geschrieben: ↑Do, 12. Aug 2021 8:21
wohl möglich mit TPM v2.0 und Bitlocker ...

ich halte mehr von eine Crypt-Controller wo der Code nicht von Microsoft kommt ...

Nein, sicher nicht mit Bitlocker.
Besser ist z.B. PEFS

Runs on top of your file system. No messing around with complex configuration and additional storage devices.

Nun, es geht in Klaus' Fall darum, Daten zu schützen, an die die, vor denen sie geschützt werden sollen, sowieso rankommen, weil sie als DBFs irgendwo im Netz herumfliegen. Ein verschlüsselndes Dateisystem wie PEFS oder ähnliche Mechanismen setzen eine Ebene zu tief an. Ich würde eher zu Impersonation raten, das ist sehr elegant und auch nicht allzu kompliziert. Dann muss es zwar mindestens einen Account geben, der auf die Daten auch auf Dateiebene zugreifen kann, aber im täglichen Normalzugriff sind die Daten sicher.

Hallo Tom

bei "Impersonation" liegen die Daten dummerweise doch im Klartext auf Festplatte und Sicherung ....
Bei der Verschlüsselung von Datenfelder hast du dann ein Problem mit den Index-Files.
Hier hilft dann z.B. PEFS welches alle Dateien eines Pfades Transparent verschlüsseln kann ohne änderung am Programmcode und auch die Datensicherung z.B. ein Datenset in der Cloud oder sonst wo perfekt schützt.

Hallo, Carlo.

Aber auf Telefonnummer oder Mailadresse legt man üblicherweise keinen Index, oder? Und, klar, bei Impersonation hast Du immer noch den Zugriff auf Administratorebene. Aber den hast Du bei einem SQL-Server ja auch. Und ein verschlüsseltes Dateisystem hilft Dir nicht, wenn die Nutzer - wie bei DBF-Datenbanken üblich - Vollzugriff auf die Datenverzeichnisse haben müssen. In diesem Fall wäre eine Dateisystem-Verschlüsselung in Verbindung mit Impersonation vermutlich die beste Wahl. Aber, wie gesagt - es geht hier um Telefonnummern und Mailadressen. Und wenn es nicht um hunderttausende von Kontakten geht, tut's da im Zweifelsfall auch ein Filter.

wie auch immer, ich muss die Datenfelder in der DBF verschlüsselt ablegen. Darauf erfolgt dann auch im Zweifel ein Index.

Es ist ja auch kein Problem.
Beispiel TelNr. die verschlüsselt in der DBF steht.
Der Suchbegriff wird vor dem Seek verschlüsselt und danach gesucht.
Im Quellcode kann ich nach

replace kd->telnr with Crypt(TelKlartext) suchen und einfach ädern
oder
m_TelNr := Decrypt(kd->telnr) // Die Funktion gibt es nicht. Ist nur zum besseren Verständnis.

Wenn ich die in der Anwendung im Klartext brauche, decodiere ich diese.
Was bei mir ein wenig mehr Aufwand ist: ich muss z.B. ein
dcbrowsecol field kd->telnr oder ein dcget kd->telnr entsprechend anpassen.

Tom hat geschrieben: ↑Do, 12. Aug 2021 14:27 Und ein verschlüsseltes Dateisystem hilft Dir nicht, wenn die Nutzer - wie bei DBF-Datenbanken üblich - Vollzugriff auf die Datenverzeichnisse haben müssen.

Da hast du recht. Daran habe ich gar nicht mehr gedacht!
Ich war in Gedanken beim Schutz der Daten gegenüber Aussenstehenden Dritten.
Die Betriebsangehörigen haben durch die vielen Listen/Export/Transferfunktionen sowieso Zugriff auf die Daten.
Da bringt es nicht viel z.B. die Telefonnummer in einer DBF zu Verschlüsseln und daneben bestehen die Umfangreichen Listen/Transferfunktionen.
Bei uns ist der gewollte Schutz der die Daten vor Diebstahl der Datenträger usw. durch Aussenstehende zu schützen

Bei den neueren Web-Apps sehen die User die Datenverzeichnisse gar nicht mehr, da ist es einfacher mit einem verschlüsselten Dateisystem zu arbeiten weil Softwaremässig gar kein Aufwand mehr anfällt und auch die PG Datenbanken automatisch voll verschlüsselt sind.