suit: Sicherer Javascript Passwortschutz ?!

Beitrag lesen

Ohne Salt bringt es dir aber nichts, weil man dann das Klartextpasswort überhaupt nicht mehr schützen müsste. Schließlich ineressiert sich der Angreifer nicht mehr für ein Klartextpasswort, wenn jedes Login-System nur einen Hash haben will. Er muss nicht einmal den Hash vom Passwort berechnen, sondern kann den abgefangenen Hash gleich bei anderen Servern testen.

Nochmal: weder ein Hash noch ein gesalteter Hash dienen in irgend einer Form der Sicherheit des Logins.

Wenn der Angreifer so weit ist, dass er den HTTP-Traffic überwachen kann, ist es völlig wurst, ob er das Klartextpasswort, den Hash oder einen gesalteten Hash mitliest - er kann sich damit einloggen.

Wenn ich ein Wörtebuch habe, für ein 8-stelliges Passwort, dann wäre dieses genauso groß wie ein Wörtebuch für ein 8-steliges Passwort + Salt.

Ja - der einzige Vorteil der Salt-Variante ist, dass die Tabelle mit Salt erst berechnet werden muss, die andere aber potentiell verfügbar ist.

Das setzt die Sicherheit doch nicht herab.

Nein, bei einem einzelnen Passwort verbessert sie die Sicherheit aber nur sehr unwesentlich, darum ist es in diesem Kontext quasi unnütz.

Die ersten feststehenden Zeichen beeinflussen zwar den Hash-Wert und verändern diesen. Jedoch wird dadurch die Anzahl der möglichen Hash-Werte nicht verringert. (Zumindest wenn man mögliche Kollisionen vernachlässigt, die bei einem relativen kurzen Salt und Passwort eher nicht auftreten sollten.)

Auch bei einem langen Salt steigt die Kollisionswahrscheinlichkeit nicht an - solange man davon ausgehen kann, dass die Hashfunktion gleichverteilt arbeitet.

Doch damit der Hash nicht bei einem anderen Server verwendet werden kann, wo der Benutzer das gleiche Passwort einsetzt.

Jetzt hab ich dich verstanden - das ist richtig, setzt aber voraus, dass dort dasselbe Loginverfahren genutzt wird. Die Wahrscheinlichkeit, dass das dort auch so ist, ist aber kleiner alsdass dort dasselbe Klartext-Passwort akzeptiert wird.

Darum ist es wesentlich vernünftiger das Passwort vernünftig zu verschlüsseln und dann zu übertragen - und zwar mit einem asynchronen Verfahren - oder eben man nutzt SSL.

Es steht aber da, dass die Passwörter sicher übertragen werden. Daraus könnte man schließen, dass auch das eigene Loginsystem dadurch sicherer wird. Das ist zwar ein Trugschluss, auf den aber nicht aufmerksam gemacht wird.

Wer aus der sicheren übertragung eines Passworts auf die Sicherheit des Login-Systems schließt, hat den Unterschied zwischen Schlüssel und Schloß nicht verstanden.

Was nutzt ein absolut fläschungsicherer Schlüssel, wenn der Schlüssel gestohlen wird?

Für diesen Anwendungsfall gibts One-Time-Pad-Verfahren - da hilft auch ein geklauter Schlüssel nichts, verringert aber den Komfort des Systems.

"Passwörter werden häufig noch im Klartext im Internet/Intranet übertragen (vgl. SELFHTML  Eingabefelder für Passwörter).
Neben diesem Risiko, werden die Zugangsdaten auf Seiten des Servers üblicherweise in einer Datenbank abgespeichert. Ein in diesem Beitrag besprochenes Verfahren bietet die Möglichkeit das Passwort direkt MD5 verschlüsselt über das Netz zu schicken."

Das klingt doch so, als könnte man damit das Problem durch die "Verschlüsselung" beheben.

Für mich nicht :) aber du kannst den Autor ja anschreiben und Verbesserungsvorschläge machen.