Verschlüsselte Konfiguration

[Ghostwalker]

Hihi,

ich wollte mal Fragen ob ihr die Konfiguration eurer Programme (also ini,cfg,registry oder wo auch immer) verschlüsselt oder plain speichert ?

[Benedikt Magnus]

Kommt immer darauf an:
Soll der Nutzer generell die Möglichkeit haben, die Einstellungen zu ändern (was meistens der Fall ist), dann im Klartext oder sogar mit Lesbarkeitshilfe (a la ini).
Wenn der Nutzer hingegen möglichst wenig Zugriff haben soll bzw. nur sehr schwierig (absolute Sicherheit gibt es da nicht), dann wird die Konfiguration verschleiert, z.B. durch Verschlüsselung oder binärem Abspeichern oder durch das Fehlen jeglicher Hilfe (unbeschrifteter Haufen Zeilen o.Ä.). Der einzige Anwendungsfall, der mir hier einfiele, wären unter Umständen Speicherstände von Computerspiele...

[Darlo]

Ich bin dazu übergegangen sämtliche Programmeinstellungen in einer verschlüsselten sqlite DB zu speichern. Informationen für Schnittstellen landen in einer unverschlüsselten ini-Datei. Was ein User ändern darf, kann er dann über das UI der Anwendung machen.

[Zacherl]

Plain. Wenn ein User meint irgendwas ändern zu wollen, was nicht über die GUI geht - selbst Schuld, wenn er dabei was kaputt macht. Und wer wirklich will, kann die Config über Umwege eh immer ändern.

[blawen]

Grundsätzlich speichere ich die Einstellungen in Form von Schlüsseln in der verwendeten Datenbank.

Einstellungen die ich dort nicht ablegen kann, z.B. die DB-Zugangsdate, speicher ich in einer Ini-Datei.
Was der User nicht ändern, bzw. nicht direkt lesbar einsehen soll, speichere ich darin verschleiert.
Diese Zeilen überprüfe ich zusätzlich mit einer in der Ini-Datei abgelegten MD5-Summe.
Um die Übersicht noch ein wenig mehr zu erschweren, füge ich noch ein paar "unnütze" Zeilen hinzu.
Daten welche er ändern darf (oder ggf. muss) sind unverschlüsselt und ungesichert in der Ini-Datei.

Code:

[DB_Server]
Hostname     = CTCD@^]><3
Port         = 3306
Username     = XH@@
Passwort     = <?>98;:
DB_Name      = elmo_test
Protokoll    = mysql-5
MD5-Hash     = 70C829DB98ECA56974C6839070681C40
Schlüssel1   = dsaear5656asdq34dwa6cx68w54sdfs6t35i75oizt5Ppö.asdü$ycsdfr*'?aAdöed
Schlüssel2   = 9ik)JI0wrk630$AKK;K98ufxv9HJHRgwKJKJUzkHJNJGHasfawe33303asfyijnq34$
Service_IP   = 172.20.202.62
Service_Port = 40000

...und nein, der User ist nicht "root" ;-)

[dGeek]

Zitat:

Zitat von Zacherl (Beitrag 1353511)

Plain. Wenn ein User meint irgendwas ändern zu wollen, was nicht über die GUI geht - selbst Schuld, wenn er dabei was kaputt macht. Und wer wirklich will, kann die Config über Umwege eh immer ändern.

So sehe ich das auch.
Ich sehe in dem Verschlüsseln/Verschleiern einer Konfigurationsdatei absolut keinerlei Sinn und Zweck.

Ich finde verschlüsselte oder schleierte Konfigurationsdateien sind sogar ein absolutes NoGo was Benutzerfreundlichkeit angeht.

[blawen]

Zitat:

Zitat von dGeek (Beitrag 1353517)

Zitat:

Zitat von Zacherl (Beitrag 1353511)

Plain. Wenn ein User meint irgendwas ändern zu wollen, was nicht über die GUI geht - selbst Schuld, wenn er dabei was kaputt macht. Und wer wirklich will, kann die Config über Umwege eh immer ändern.

So sehe ich das auch.
Ich sehe in dem Verschlüsseln/Verschleiern einer Konfigurationsdatei absolut keinerlei Sinn und Zweck.

Ich finde verschlüsselte oder schleierte Konfigurationsdateien sind sogar ein absolutes NoGo was Benutzerfreundlichkeit angeht.

In meinem Fall liegt die Exe- und die Ini-Datei in einem Netzwerkordner. Im Normalfall gibt es keinen Grund, warum ein "normaler" User das Passwort oder den Servernamen abändern muss. Selbstverständlich kann der Admin die Ini-Datei mit einem kleinen Tool bearbeiten und so z.b. die DB zügeln.

[Zacherl]

Zitat:

Zitat von blawen (Beitrag 1353519)

In meinem Fall liegt die Exe- und die Ini-Datei in einem Netzwerkordner. Im Normalfall gibt es keinen Grund, warum ein "normaler" User das Passwort oder den Servernamen abändern muss. Selbstverständlich kann der Admin die Ini-Datei mit einem kleinen Tool bearbeiten und so z.b. die DB zügeln.

Dem Admin nimmst du mit deiner Obfuscation aber die Möglichkeit die Datei mit einem Editor seiner Wahl zu bearbeiten und zwingst ihm stattdessen dein Config Tool auf. Statt so einen Aufwand zu betreiben, könntest du die Ini-Datei auch einfach Read-Only flaggen und somit dem User indizieren, dass er die Datei lieber nicht bearbeiten sollte. Oder falls andere Einträge auch vom User bearbeitet werden müssen, notfalls eine zweite, nicht schreibgeschützte Datei.

[blawen]

Zitat:

Zitat von Zacherl (Beitrag 1353521)

Zitat:

Zitat von blawen (Beitrag 1353519)

In meinem Fall liegt die Exe- und die Ini-Datei in einem Netzwerkordner. Im Normalfall gibt es keinen Grund, warum ein "normaler" User das Passwort oder den Servernamen abändern muss. Selbstverständlich kann der Admin die Ini-Datei mit einem kleinen Tool bearbeiten und so z.b. die DB zügeln.

Dem Admin nimmst du mit deiner Obfuscation aber die Möglichkeit die Datei mit einem Editor seiner Wahl zu bearbeiten und zwingst ihm stattdessen dein Config Tool auf. Statt so einen Aufwand zu betreiben, könntest du die Ini-Datei auch einfach Read-Only flaggen und somit dem User indizieren, dass er die Datei lieber nicht bearbeiten sollte. Oder falls andere Einträge auch vom User bearbeitet werden müssen, notfalls eine zweite, nicht schreibgeschützte Datei.

Das stimmt zwar schon, aber Verbindungsdaten (Host, User, Passwort) sind im Normalfall vertrauliche Daten und sollten m.E. nie im Klartext vorhanden sein.

[Zacherl]

Zitat:

Zitat von blawen (Beitrag 1353522)

Das stimmt zwar schon, aber Verbindungsdaten (Host, User, Passwort) sind im Normalfall vertrauliche Daten und sollten m.E. nie im Klartext vorhanden sein.

Vertrauliche Daten sollten GAR NICHT in irgendeiner Form im Programm hardcoded sein. Security through obscurity ist genauso sicher, wie komplett unverschlüsselt.

Also entweder du vertraust bei deinem Beispiel dem User, der Zugriff auf den Netzwerkpfad hat komplett - oder du lässt es ganz. Im ersten Fall ist es egal, ob die sensiblen Daten ersichtlich sind und beim zweiten Fall müsstest du ebendiese Daten bei jedem Programmstart vom Nutzer abfragen (ggfls. lokal beim User irgendwo cachen).