Security of DBF Files

Beitrag von **Manfred** » Mi, 25. Okt 2006 7:47

Moin,

ich lese gerade die Beiträge in den newsletter (p.x.gui) über oben genanntes Thema.

Hat jemand von euch mit dem Vorschlag von Hannes, oder generell, Erfahrung gemacht, oder sich einmal damit beschäftigt?

Beitrag von **Jan** » Mi, 25. Okt 2006 8:17

Moin Manfred,

wenn ich mich richtig erinnere ist in der Prof. Subscription eine Verschlüsselungsfunktion dabei.

Ansonsten: Ich arbeite mit umbenannten Datenbanken, Indizee und Memodateien. Funktioniert einwandfrei, aber wenn jemand versucht daranzukommen und wieder zurück-umbenennt (aufwändig, weil er ja nicht die korrekte Endung kennt), dann liegen die Daten natürlich offen vor ihm.

Jan

Beitrag von **brandelh** » Mi, 25. Okt 2006 9:04

Hi Martin,

es kommt darauf an, welche Sicherheit du meinst:

1. Garantierte Sicherheit

wie schon geschrieben bietet Alaska eine AES verschlüsselte Variante von dem DBF Treiber an. AES ist anerkannter Standard und sehr sicher (wie bei HTTPS).
Den Preis und die genauen Bedingungen kenn ich jetzt nicht.

2. Einiger Maßen sicher

in den Tools gibt es die Crypt Funktion. Alle Strings kann man damit verschlüsseln. Ich habe mal versucht anhand von Test die alte Clipper Version (Xbase++ bietet auch noch eine bessere) zu brechen, hatte aber keinen Erfolg. Bei kurzen Feldern, die auch oft leer sind und man weiß was vorher drin war, kann man einiges erraten ...
Vor normalen Anwendern und normalen Programmierern (wie mich

) bist du damit auf der sicheren Seite. Wenn es aber jemand wirklich interessiert was drin steht und der Geld in die Hand nimmt, wird es wohl nicht lange geheim bleiben. Ich hatte früher ein Programm so geschützt, leider konnte man nach Fehlern die Datei nicht einfach mit DBU reparieren

Einen Nachteil will ich nicht verschweigen, man muss alles in Strings konvertieren.

3. DAUs vom Editieren mit Excel etc. abhalten.

Man kann ...
Endungen ändern - Texteditor liest und schreibt trotzdem.
Beim Schließen das READONLY Flag setzen - lesen geht noch, schreiben nimmer.
Verzeichnisse verstecken - je nach Einstellung kein Hinderniss, eventuell aber auch kein Backup, da Verzeichnis nicht gefunden wird.

4. Andere DLL nehmen

Es gibt eine normale Windows DLL - cheetah (ich hoffe ich habs noch richtig im Kopf - Gepard ist die Übersetzung), die man auch von Xbase ansprechen könnte (wenn man weiß wie). Normalerweise wird die in PowerBasic verwendet (dafür gibt es Unterstützung) und hat die normalen Clipper Befehle als DLL Funktionen. Kostet nix mehr und kann DBF direkt verschlüsseln. Meine PowerBasic Experimente waren gut.
Mit Xbase++ und auch mit der Verschlüsselungsfunktion habe ich aber keine Erfahrung in dem Zusammenhang.

5. ADS soll sowas auch können

... keine Ahnung, wohl aber nicht billig ...

6. SQL-Server

... keine Ahnung wegen der Verschlüsselung, wird es wohl aber geben ...

Beitrag von **Manfred** » Mi, 25. Okt 2006 9:07

Hi Hubert,

was macht mich an Deinen Beiträgen teilweise echt strubbelig..... Ich überlege noch.

Beitrag von **brandelh** » Mi, 25. Okt 2006 9:14

Manfred hat geschrieben:was macht mich an Deinen Beiträgen teilweise echt strubbelig..... Ich überlege noch.

Muss ich das jetzt verstehen ?

Wenn meine Haare strubbelig werden, sind sie zu lang und ich geh mal wieder zum Frisör

Aaah vielleicht weil ich versehentlich gleich abgeschickt hatte statt erst auf Vorschau zu gehen und dann noch 2x korrigiert habe

Beitrag von **Manfred** » Mi, 25. Okt 2006 9:16

Hi Hubert,

nagut, ich helfe Dir auf die Sprünge....

Ich bin nicht der Martin, ne, ich bin der Manfred....

Beitrag von **brandelh** » Mi, 25. Okt 2006 9:34

Manfred hat geschrieben:Hi Hubert,
nagut, ich helfe Dir auf die Sprünge....
Ich bin nicht der Martin, ne, ich bin der Manfred....

oh nein, ich habs schon wieder getan ...

Ich wusste ich hätte heute im Bett bleiben sollen.

Sorry Manfred und Sorry Martin, ich weiß schon wer wer ist,
aber manchmal schreiben meine Finger (10x blind) schneller als mein Hirn mitkommt, speziell morgens

Beitrag von **Martin Altmann** » Mi, 25. Okt 2006 11:17

Hallo Hubert,
ist schon OK - bist halt ein Fauler und willst einen Buchstaben einsparen

Viele Grüße,
Martin

Gerd König · Beitrag von **Gerd König** » Mi, 25. Okt 2006 13:02

Hallo Manfred,

wir arbeiten mit keinem Verschlüsselungsverfahren.

Allerdings haben wir das Problem so gelöst, daß alle Applikationen, über einen Loader laufen. Dieser wiederum startet das jeweilige Programm unter einem anderen Nutzer. Nur dieser und die Admins haben Zugriff auf die Netzwerk-Ordner mit den DBFs.

Dafür haben wir durch einen externen Partner eine C-DLL entwickeln lassen. Unterstützt werden dabei W2k und XP.

Wir ließen uns dabei davon leiten, daß weniger Manipulationen das Problem sind, sondern wichtige Daten aus Versehen von DAUs oder in der Hektik gelöscht werden könnten.

Natürlich machen wir eine tägliche, besser nächtliche, Datensicherung.

Mir ist es übrigens auch schon passiert, daß ich aus Versehen eine Datei gelöscht habe

Übrigens haben wir (unter XBase) einen File-Commander entwickelt, der auch beim Ändern oder Löschen einer Datei eine Sicherungskopie erstellt

Viele Grüße
Gerd

Beitrag von **Martin Altmann** » Mi, 25. Okt 2006 13:03

So - und nun zurück zum Thema.
Habe gerade die Diskussion in der Newsgroup gelesen.
Etwas darf man (zumindest in Deutschland) nicht vergessen:
Die Daten, die ein Nutzer mit einer Applikation erstellt bzw. verwaltet, gehören dem Nutzer - nicht dem Programmierer!
Dem Nutzer muß es ermöglicht werden, an die Daten auch ohne dem entsprechenden Programm heranzukommen!
Wenn also der Nutzer sich in x Monaten/Jahren nach Kauf der Software dazu entscheidet, nicht mehr mit dem alten Programm A, sondern einem Konkurrenzprodukt B zu arbeiten, so muß der Nutzer die Möglichkeit haben, die Daten aus dem alten Programm A auslesen zu können!
Diese Möglichkeit muß entweder im Programm verfügbar sein (Exportfunktion) oder kostenfrei dem Nutzer zur Verfügung gestellt werden!
Alles andere verstößt (zumindest in Deutschland) gegen geltendes Gesetz/geltende Rechte!

Viele Grüße,
Martin

Beitrag von **brandelh** » Mi, 25. Okt 2006 13:33

Hallo Martin,

das widerspricht aber nicht der Aussage, dass es nötig sein kann Daten und Dateien zu schützen / verschlüsseln.

Der berechtigte User hat ja Zugriff auf die Daten über das Programm, ohne Programm würden ihm die Daten oft nichts nützen. Viele Betriebe und Behörden (und auch Privatanwender) haben z.b. aber immer im Hinterkopf, was geschieht wenn jemand an den Dateien ohne die Plausis der Programme herum macht. Support-Abteilungen wissen da sicher ein Lied davon zu singen. Ich hatte auch mal jemand, der im PC Kurs von EDLIN gehört und damit die DBF geöffnet hat. Nix zu sehen, also wieder beendet. Dumm nur, dass beim normalen Ende EDLIN die DBF wieder gespeichert hat, dummerweise nicht ganz unverändert und auf 64KB gekürzt - mehr konnte der Uralt-Editor nicht (ist schon ne Weile her). Nur gut, dass die Sicherungskopie nur 6 Tage alt war und die Änderungen nachvollzogen werden konnten. Oder denke nur an Laptops die verloren gehen oder PCs die gestolen werden. Sind dann die Daten verschlüsselt ist alles gut.
Oder denke an TOMs Software. Die Daten, die die User eingeben, dürfen diese selbst gerne haben (eventuell Sozialdatenschutz), aber was ist mit den Hilfstabellen und datadriven Regelwerken die das Programm als solches erst zum Leben erwecken, das sind seine Geschäftsgeheimnisse.

Solide Exportfunktionen der Daten auch zu Datensicherungen die unabhängig vom BS und Programm sind sind schon schön und eventuell je nach Fall auch nötig. Ich warte ja darauf, dass z.B. MS seine DOC Dokumente endlich mit sauberen Konvertern für die Konkurenzprodukte ausliefert - na ja wenigstens zum OpenDoc Standard

Beitrag von **Martin Altmann** » Mi, 25. Okt 2006 13:43

Hallo Hubert,

brandelh hat geschrieben:das widerspricht aber nicht der Aussage, dass es nötig sein kann Daten und Dateien zu schützen / verschlüsseln.

das habe/wollte ich ja auch nicht behaupte[t|n]

Aber wie gesagt: Der User muß in die Lage versetzt werden, ohne Mehrkosten an seine Daten auch ohne dem Programm heranzukommen!
Eventuelle Steuerdaten, die nicht durch den Nutzer eingegeben wurden, fallen da natürlich nicht drunter und sind ja auch nicht sein Eigentum!
Ich habe das ja auch nur geschrieben, damit es nicht in Vergessenheit gerät. Unter Umständen ist dieses auch nicht jedem klar!
Also: Wer die Daten verschlüsselt, muß sich darüber im klaren sein, dass er kostenfrei die Möglichkeit zur Entschlüsselung und ggf. Export mit- bzw. nachliefern muß!

brandelh hat geschrieben:Ich warte ja darauf, dass z.B. MS seine DOC Dokumente endlich mit sauberen Konvertern für die Konkurenzprodukte ausliefert - na ja wenigstens zum OpenDoc Standard

Ist doch (laut heise vor einigen Tagen) bereits geschehen.

Viele Grüße,
Martin

Beitrag von **brandelh** » Mi, 25. Okt 2006 13:48

Martin Altmann hat geschrieben:Ist doch (laut heise vor einigen Tagen) bereits geschehen.

Wirklich ? Es geschehen noch Zeichen und Wunder

Beitrag von **Manfred** » Mi, 25. Okt 2006 13:52

jaja,

und manchmal muß man die Zeichen dann nur noch zu deuten wissen.

Beitrag von **Tom** » Mi, 25. Okt 2006 14:17

Hi, Ihr.

Was Martin sagt, ist absolut richtig, allerdings gibt es gewisse Grenzen. Gerade bei kaufmännischen Anwendungen liegen der Art der Datenhaltung technische Entscheidungen zugrunde, und die Standardanwendungen, die man für verschiedene Branchen vorfindet, halten ganz unterschiedliche Daten vor, die sich häufig nicht direkt oder indirekt in eine neue Lösung importieren lassen. Der Nutzer hat aber das Recht, auf seine Daten ohne die Anwendung zugreifen zu können - nicht mehr, nicht weniger. Deshalb gibt es bei uns auch Exportroutinen, die innerhalb des Programmes für bestimmte Nutzer (Superuser) zugänglich sind und die Standardinformationen exportieren. Wir halten Daten halbverschlüsselt, crypten also nur jene Datenbankfelder, die es ermöglichen, Zusammenhänge herzustellen. Die von Alaska mit der 1.9 ausgelieferten Verschlüsselungsroutinen sind übrigens nur für DBFCD/FoxPro anwendbar. Für die gängigsten Konkurrenzprodukte haben wir übrigens ein Importtool (XUpdater) geschrieben, das Daten aus diesen Anwendungen in unsere holt.

Beitrag von **brandelh** » Mi, 25. Okt 2006 14:27

Hi,

zum Thema passt auch diese Info:

http://www.heise.de/newsticker/meldung/79880

Wie so oft kommts halt genau drauf an, was im Einzelfall zu beachten ist.

Dazu fällt mir auch ein,

es gibt Aufbewahrungsvorschriften für verschiedene Daten und es
gibt Löschvorschriften, für Daten die aus Datenschutzgründen garnicht oder nur begrenzt vorgehalten werden dürfen (letzteres wird bei Programmen oft übersehen).

Beitrag von **Tom** » Mi, 25. Okt 2006 14:38

Hallo, Hubert.

es gibt Aufbewahrungsvorschriften für verschiedene Daten und es
gibt Löschvorschriften

Glücklicherweise betreffen solche Vorschriften die Nutzer, nicht die Softwarehersteller. Auch die gesamte Datenschutzproblematik insbesondere im Hinblick darauf, welche Daten überhaupt erfaßt werden dürfen, ist eine Kuh, die für die Hersteller vom Eis ist, weil sie in den Verantwortungsbereich der Anwender fällt - ein Messerhersteller wird auch nicht dafür verantwortlich gemacht, wenn jemand mit dem Teil seine Gattin zersäbelt. Und auch zum Beispiel das Problem, daß viele Informationen auch ohne Software verfügbar sein müssen (Dokumentenvorhaltung).

Übrigens, das hatte ich ganz vergessen. Unsere Software ist verdongelt (Aladdin/Hardlock), und es gibt eine Version, die sämtliche Daten durch den Dongle jagt - um sie auf diese Art zu ver- und entschlüsseln.

Beitrag von **Martin Altmann** » Mi, 25. Okt 2006 14:44

Hallo Tom,

Tom hat geschrieben:- ein Messerhersteller wird auch nicht dafür verantwortlich gemacht, wenn jemand mit dem Teil seine Gattin zersäbelt.

dies gilt jedoch nicht so einfach in den USA!

Viele Grüße,
Martin

Beitrag von **brandelh** » Mi, 25. Okt 2006 15:10

Martin Altmann hat geschrieben:Hallo Tom,
Tom hat geschrieben:- ein Messerhersteller wird auch nicht dafür verantwortlich gemacht, wenn jemand mit dem Teil seine Gattin zersäbelt.
dies gilt jedoch nicht so einfach in den USA!

Viele Grüße,
Martin

Hi Martin,

der Einwand zieht nicht, oder hast du je gehört, dass der Verkauf
von z.B. Schnellfeuerwaffen an Privatleute nach einem Anschlag auch
zu Beschränkungen geführt hätte. Bei allem was Waffen betrifft sind die
Hersteller in den USA sicher

Na ja beim Küchenmesser vielleicht ... sicher aber ist Porsche dran,
wenn der erste mit nem Carrera in der Schule aufräumt

Beitrag von **brandelh** » Mi, 25. Okt 2006 15:16

Tom hat geschrieben:
es gibt Aufbewahrungsvorschriften für verschiedene Daten und es gibt Löschvorschriften
Glücklicherweise betreffen solche Vorschriften die Nutzer, nicht die Softwarehersteller.

ich kenn mich jetzt nicht mit den privaten Softwareherstellern aus, aber die alten inhouse programme hatten das auch übersehen und die letzte Prüfung lies durchblicken, dass wir bei der nächsten nicht mehr durchkämen ...

Die Software muss dem Anwender zumindest die Möglichkeit geben, z.B. per Ablaufdatum und Löschroutinen die Einhaltung der Gesetze zu ermöglichen. Was würde wohl passieren, wenn eine Buchhaltungssoftware Funktionen enthielte die der Steuerhinterziehung dienen könnten ...

Beitrag von **Tom** » Mi, 25. Okt 2006 15:34

Hallo, Hubert.

Die Software muss dem Anwender zumindest die Möglichkeit geben, z.B. per Ablaufdatum und Löschroutinen die Einhaltung der Gesetze zu ermöglichen.

Das muß sie. Zudem prüft bei unseren Kunden der Medizinische Dienst der Krankenkassen (MDK), ob die Software bestimmten Anforderungen genügt, die per Zulassungsvertrag vereinbart sind. Allerdings muß es für solche Systematiken keinen Automatismus geben; der Nutzer muß lediglich dazu in der Lage sein, bestimmte Löschungen vorzunehmen.

Was würde wohl passieren, wenn eine Buchhaltungssoftware Funktionen enthielte die der Steuerhinterziehung dienen könnten ...

Jeder, der mal mit der Gastronomie konfrontiert war, wird solche Anforderungen kennen: "Wir wollen mittags eine Art Abschlagsrechnung machen. Gibt es die Möglichkeit, die fortlaufende Bon-Nummerierung zurückzusetzen? Ich meine nur, wenn wir mal einen Fehler machen. Sie wissen schon."

Beitrag von **Manfred** » Mi, 25. Okt 2006 15:41

Höhö,

da kenne ich noch ein paar ganz geile Registrierkassen aus alten Zeiten. Die hatten einen Schwarzwaldspeicher.

Beitrag von **AUGE_OHR** » Mi, 25. Okt 2006 16:37

hi,

man muss Daten verschlüsseln ! Warum ?
Naja wenn Daten nicht verschlüsselt werden hat man auch keinen
Anspruch auf "Schutz". Wenn man also gegen einen "alten" Mitarbeiter
einen Prozess führt weil er "Daten mitgenommen" hat ...

Ich hab irgendwann mal am "Anfang" mit der DBESYS.PRG so rum-
gespielt das ich auf einmal DBF/FPT hatte die mit Cl*pper, DBU, BRO
etc. sowie Office97 NICHT mehr zu öffnen waren. Nur noch mit
meiner Xbase++ Anwendung und ARC32 (ADS Local) kam ich an die
DBF/FPT Dateien ran. Leider hab ich die DBESYS.PRG danach wieder
"korrigiert" ... muss mal sehen ob ich noch ein Work-Backup habe.

gruss by OHR
Jimmy

Markus Walter · Beitrag von **Markus Walter** » Mi, 25. Okt 2006 17:25

Hallo Manfred,

zurück zu Deiner Ursprungsfrage:
Bei der Variante von Hannes sehe ich das Problem, dass eine Datei sobald sie von einem Prozess geöffnet ist, "unverschlüsselt" ist, d. h. den richtigen Header hat. Somit kann sie in dieser Zeit geöffnet und bearbeitet werden. Und dieser Zustand ist (zumindest bei meiner Applikation) der häufigere...

Deswegen wollte ich den Datei-Header immer geändert lassen, dass geht aber nicht, da Xbase häufig den ganzen Header neuschreibt (Aussage von Andreas Herdt).

Ich bin aber an dem Thema auch richtig interessiert. Ich werde Alaska mal anschreiben wegen dem AES-Treiber. Mir haben die damals auch gesagt, dass sowas kommen soll...

Hat jemand Erfahrung damit?

Ich habe aber zusätzlich das Problem, dass ich mit Delphi-Applikationen zugreifen können muss (über eine Komponente namens Apollo)... Das wird dann wohl nicht gehen

Beitrag von **Manfred** » Mi, 25. Okt 2006 17:27

Hi Markus,

ich sage nur mal kurz: "aha, interessant zu lesen"