Zitat:
Eine Frage zum "Salt": Was bringt mir das? Warum wird es dadurch so sicher?
Das übergebene Passwort wird mit dem Salt "verknüpft" und per Einweg-Hash-Funktion daraus ein Datenwert=Sessionschlüssel erzeugt der die maximal mögliche Länge des Verschl.Algo. benutzt -> Context.KeySize. Alleine das erhöht schon die Sicherheit, da heutige menschliche Passwörter niemals so lang sind wie sie sein müssten damit der Cipher "sicher ausgelastet" ist. Wir erzeugen quasi aus den wenigen Passwortbits soviele sichere Bits wie der Cipher benötigt um seine berechnete Sicherheit zu erlangen. Dies ist natürlich nur ein bedingt sicherer Prozess, besser ist es immer gleich ein ordentliches Passwort zu benutzen.
Das Resultat dieser Berechnung kann auf Grund der Eigenschaften der Hashfunktion nicht mehr zurückgerechnet werden in Passwort + Salt. Da der Salt zufällig ist würde bei dieser Berechnung jedesmal ein anderer Sessionkey rauskommen, quasi-zufällig, obwohl man das gleiche Passwort benutzt. Nun ist es in der Realität so das man oft das gleiche Passwort wiederverwendet und damit ganz verschiende Sachen verschlüsselt. Benutzt man das Passwort direkt als Key so könnte man in einem unsicheren Verfahren eventuell dieses Passwort direkt berechnen, schwups hat man den Schlüssel geknackt. Das führt dann dazu das durch das schlechte Benutzerverhalten der Angreifer über die "unsichere Verwendung auf WEB Seite X, das Passwort knackt und selbst auf der absolut sicheren und gute konstrukierte WEB Seite Y Zugriff auf die Konten des Benutzers erlangt". Das heist der Benutzer nutzt das gleiche Passwort an unterschiedlichen Stellen und die schwächste Stelle komprimiertiert dadurch das Gesamtsystem. Wenn also Seite X scheiße mit den Daten umgeht so wird dadurch auch Seite Y kompromitiert wenn der Benutzer das/die selben Passwörter benutzt. Das ist heutzutage oft der Fall.
Die Salt-Methode verhindert nun das man durch einfache Brute Force Attacke das Passwort berechnen kann. Wir gehen davon aus das der Angreifer den Verschl. Algo. X knacken kann, er kann also aus einer verschl. Nachricht dieses Verfahrens den benutzten Schlüssel ermitteln. Würden wir keinen Salt+Einwegfunktion benutzen so hätte er direkt das Passwort geknackt. Wenn wir aber obige Methode -> KDF -> Key Derivation Function -> Schlüssel-Ableitungs-Funktion benutzen dann hat der Angreifer NUR diesen EINEN Sessionkey geknackt. Eine zweite Datei mit gleichem Passwort und Verfahren würde auf Grund des Zufallssalts ja wiederum einen anderen Sessionkey erzeugen. Der Angreifer MUSS erneut die Nachricht komplett knacken um nun diesen EINEN einmalig verwendeten Sessionkey zu knacken. Er muss also alle Nachrichten einzeln knacken. Wenn nun der Aufwand dieses Prozeses > 1 ist dann bedeutet dies das er durch unsere KDF also X Dateien * Aufwand Knacken benötigt statt nur 1 Datei Knacken und X-1 Dateien sofort entschlüsseln zu können. Wir erhöhen also mathem. beweisbar den Aufwand des Knackens beim Angreifer.
Da der Salt 16 Bytes = 128 Bit = 2^128 Kombinationen hat, also sehr groß ist, verhindern wir das wir quasi doppelte Sessionskeys erzeugen, einfach weil die Wahrscheinlichkeit mit 1/2^128 enorm gering ist. Wir haben also aus unserem EINEM Passwort das wir X mal verwenden wollen auf sichere Art&Weise X gute Sessionkeys erzeugt. Nur derjenige der das Passwort und die X Salts kennt kann diese X Sessionkeys reproduzieren.
Wir schützen also das reale Passwort des Benuitzers und erhöhen noch den Aufwand für einen Angreifer. Denoch: eine KDF schützt nichts besser wenn der Angreifer direkt das Passwort per Brute Force Attacke knackt (er kennt also den Salt). Dh. eine KDF ist kein "Ausgleich" dafür das man nun schlechte Passwörter benutzen kann, sie erhöht nur die Angriffskomplexität wenn man ein Passwort mehrmals verwendet, und das ist weitaus besser als das Passwort direkt mehrmals zu benutzen.
Gruß Hagen