Ist das Passwort also auf dem Rechner, dann liegt der damit "unter der Fussmatte".
Womit wir wieder bei meinem Eröffnungspost wären (einfach nochmal lesen). Denn genau das brachte mich ja darauf, über die Problemstellung nachzudenken.
Frage 1:
Was ist besser: Ein userdefiniertes oder ein hartcodiertes Passwort?
Antwort: Userdefiniert.
Frage 2:
Wenn ein Programm mit hartcodiertem Passwort verlangt wird, wie sollte es am besten konstruiert sein?
Antwort: So kompliziert wie möglich.
Das userdefinierte Masterpasswort hat eben den Nachteil dass man bei jedem Programmstart danach gefragt wird. Manche Leute wollen das nicht. Das kann man als Entwickler gut oder schlecht finden, man muss damit leben. Ich denke, der beste Kompromiss wäre, userdefiniertes und hartcodiertes Passwort parallel zu implementieren und dem Anwender per Konfigurationsoption die Wahl zu lassen.
Als Entwickler hat man ja auch prinzipiell zwei Möglichkeiten: Entweder man implementiert was richtig gutes, was natürlich Zeit und Geld kostet sowie permanent auf dem aktuellen Stand gehalten werden muss. Oder man implementiert "irgendwas", hält sich selbst für den tollsten Hecht der Welt, der Kunde (selbst Laie) sieht nur verschlüsselte Daten und nimmt das Programm so ab, und am Ende hoffen Entwickler und Kunde einfach nur dass die Sache "irgendwie" dicht hält.
Insofern gebe ich r2c2 vollkommen recht, das Thema ist eine Sache für Spezialisten zu denen ich mich nicht zähle. Darum kann ich nur bewährte Prinzipien anwenden und auf sichere Algos wie AES aus dem
DEC vertrauen. Garantieren würde ICH trotzdem nicht dafür. Nach allem was ich so lese kann es sichere Kryptografie gar nicht geben. Höchstens solche, die wenn sie gut gemacht ist, den Angriff darauf in hohem Maße erschwert. In meinen Augen begibt sich derjenige, der für sichere Verschlüsselung GARANTIERT, auf sehr dünnes Eis.