Verschlüsselte Konfiguration

[dGeek]

Zitat von 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.

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 von dGeek:

Zitat von 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.

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 von blawen:

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 von Zacherl:

Zitat von blawen:

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 von blawen:

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).