nicht angemeldet
Liest der Angreifer den Hash mit, so kann er sich damit beliebig oft authentifizieren. Es muss sogar erst der Salt zum Client übertragen werden, damit der Client denselben Hash produzieren und der Server beide Hashes vergleichen kann.
Das unterschreib ich voll mit.
Wenn SSL unsicher ist, dann ist es kein Stück besser, einen Hash per JS zu erzeugen und den im Klartext zu übertragen - denn dem Angreifer ist es schlicht egal, ober das per tcpdump mitgeschnittene Passwort oder dessen (halt auch per tcpdump mitgeschnittenen) Hash für die Authentifizierung überträgt.
Solange es nichts besseres als ssl/https für eine verschlüsselte Übertragung hat sollte man das auch nutzen.
Die browserseitig verwendete crypto-js nutzt in meinen Augen also nicht wirklich viel, für Authentifizierungen ist sie sogar nahezu unbrauchbar.
Brauchbar für Authentifizierungen wäre sie allenfalls, wenn der Server z.B. einen zufälligen Key für jede zu authentifizierende Sitzung sendet, der Benutzer diesen in JS mit einem beiden(!) Seiten bekannten(!) Passwort verschlüsselt...
var encrypted = CryptoJS.TripleDES.encrypt("zufälliger Key für Sitzung", "Passwort");
der Server dann wieder - mit dem bekanntem Passwort - entschlüsselt und den zuvor erzeugten Key ("zufälliger Key für Sitzung") vergleicht.
Aber auch hier müsste das Passwort auf einem sicheren Weg übertragen werden. Das dürfte bei Webanwendungen ein Schwachpunkt sein - es sei denn, es ist nicht zu teuer, z.B. dem Anwender das Passwort per Bote zu senden (oder so von diesem zu empfangen).
Natürlich könnte der Server mit einem Passwort (oder shared key) auch Daten verschlüsseln, die dann clientseitig entschlüsselt werden. Aber auch hier müsste das Passwort beiden Seiten bekannt sein. Für die Übertragung gilt das oben gesagte.
Da wäre eine asynchrone Verschlüsselung mit privaten und öffentlichen Schlüsseln aber deutlich besser... weil die privaten Schlüssel sogar öffentlich bekannt sein können ohne die Sicherheit zu gefährden. Dann kann man die Daten aber auch gleich mit gpg oder pgp ver- oder entschlüsseln.
Matthias Apsel