Gerade wenn es ein verschlüsseltes Passwort ist sollte man es möglichst gut schützen, besonders wenn der nötige Mehraufwand im Vergleich zur Sicherheit die man gewinnt so dramatisch gering ist. Benutzt du dieses in der
XML so geschützte Passwort als Schlüssel zur Verschlüselung anderer Daten sollte auch dort mit einem Salt gearbeitet werden. Wenn man ohne diesen Salt arbeitet und mit zu verschlüsselenden Nachrichten arbeitet die selber feste Header enthalten oder sogar identisch sind dann wird der verschl. Output immer gleich sein, da ja Nachricht und Schlüssel immer gleich sind. Sowas ermöglicht dann einen Haufen Angriffe die man mit Salt einfach unmöglich machen könnte.
Also, immer mit Salts und KDFs den Key in einen pseudozufälligen Sessionkey umwandeln, egal ob das Passwort nun in einer
XML gespeichert wurde oder nicht, besser natürlich nicht speichern.
Eine Ausrede wie "ich möchte es nicht 100% sicher" zeugt gelinde gesagt nur von Unwissenheit. Entweder möchte man was elektronisch schützen oder man lässt es. Möchte man was schützen dann kann man dies aber nur im Rahmen mathematisch beweisbar sicherer Kryptographie. Geht man nicht diesen Weg, zb. weil man XOR benutzt, dann reden wir eben nicht mehr von Kryptographie und man könnte diese Pseudotricks auch gleich ganz bleiben lassen. Sowas übersteht im Ernstfall, also wenn ein Profi Interesse daran hat, nur 2 Stunden. Das Ziel dieser Kryptographie ist es immer mit verhältnismäßig geringstem Aufwand das Leben eines Angreifers unendlich schwer zu machen. Und vergleicht man den Aufwand eines Angreifers bei richtig angewendeter Kryptographie zu zb. einen Delphi Source der das
DEC benutzt so trifft dies auch zu.
Nun gilt aber auch noch das es garkeine 100% sichere und praktische Kryptographie gegen kann. Nichts ist also 100% sicher, aber heutige Verfahren sind aus sicht des Machbaren zu 99.9....9% sicher. Entscheidend ist aber das Verhältnis dieser Sicherheit zu zb. abgespeckten Verfahren oder gar XOR Verfahren. Diese sind dann meinstens nicht mal 0.00000....1% sicher. Mit ein par Sourcezeilen mehr entscheidet man also über eine "Alles oder Nichts" Frage.
Übrigens das Problem bei deinem Verfahren ist nicht das in der
XML gespeicherte Passwort sondern das hardcoded Passwort innerhalb deiner Software das zur Verschlüsselung des
XML Passwortes dient. Und diese objektive Sichtweise verändert auch gleichmal konzeptionell die Kryptoanalyse. Denn wenn man dieses
XML Passwort richtig schützt und der Angreifer hat nicht die Software sondern nur die
XML Daten so wird es sicher sein. Das ist weit mehr Sicherheit als wenn man dieses
XML Passwort eben nur mit XOR oder abgespeckten Verfahren schützt. Denn dann ist die Wahrscheinlichkeit das man ohne Software und nur den
XML Daten dieses Passwort knacken kann weitaus größer.
Hat der Angreifer aber Zugriff auf diese Software so kann er ein
XML Passwort auch sofort knacken durch Reverse Engineering der Software. Wurden aber nun sehr viele Daten mit unterschiedlichen
XML Passwörtern verschlüsselt, und zwar korrekt mit Salt usw., dann inkrementiert sich denoch der Aufwand für den Angreifer. Denn er braucht Zugriff auf alle
XML-Daten zu diesen verschlüsselten Dateien die er ja knacken möchte. Also auch die Benutzung der veschl.
XML-Passwörter als Schlüsel sollte kryptographsich richtig erfolgen um das Gesamtsystem bestehend aus vielen Benutzern mit vielen verschlüsselten Daten sicherer zu machen.
Wie man sieht muß man bei der Kryptoanalyse das Gesamtsystem betrachten und deshalb ist es so schwierig die Frage "wie sicher ist DECs AES Rijndael wenn ich diesen so oder so benutze" zu beantworten wenn man das Gesamtsytem in dem es als Teil benutzt wird nicht kennt. Man kann aber sehr wohl eine Vorgehensweise bei der Benutzung dieser Verfahren empfehlen die mit großer Wahrscheilnlichkeit immer sicher sein wird wenn man sie im Gesamtssystem auch richtig einbaut. Und das ist eben die Benutzung von Salts + KDFs zur Erzeugung von Sessionkey.
Deine Aussage "man hätte das
XML Passwort auch nur verstecken können" hat also weitreichende Konsequenzen innerhalb des Gesamtsytemes, es ermöglicht dann eben das Knacken von Benutzerdaten mit für den Angreifer leichter verfügbaren Datenquellen und dekemntiert somit die Gesamtsicherheit aller Benutzer und deren Daten. Kryptoanalysiert man also den Fakt das deine Software ein hardcoded Passwort benutzt so heist dies nicht autom. das nun das Gesamtsystem sofort absolut unsicher wäre und man deshalb von Vornherein alles hinschlampen kann.
Gruß Hagen