Novi: Sicherer Javascript Passwortschutz ?!

Beitrag lesen

Hallo,

soweit ich weis kann man, wenn man Hash und Salt kennt ein "String" errechnen, welcher zum gleichen "Hash" wie das Passwort kommt. Dies sollte ausreichen um sich einloggen zu können(sowohl beim System selbst, als auch an anderen Stellen mit dem selben Passwort).

ja berechnen trifft es nicht ganz. Man kann über ein vorgefertigtes Wörterbuch einem Brute-Force-Attack oder aus einer Mischung von beiden eine möglichen Schlüssel erhalten. Er kann nicht direkt berechnet werden. Ob man den Salt kennt oder nicht, mach natürlich nur aufgrund der Länge einen Unterschied. Kurze Passwörter sind sehr anfällig für Brute-Force-Attacks.

In der Regel wird es glaube auf Grund des Rechenaufwandes nicht gemacht.

Ja, damit hast du recht.

Ja der höhere Aufwand für den Angreifer, bedeutet in diesem Fall gleichzeitig ein höheren Aufwand für den normalen Benutzer. Der Einsatz von Captchas erschwert nur rein automatisierte Angriffe, macht sie aber längst nicht unmöglich. Captchas können häufig doch von Programmen gelesen werden. Ansonsten gibt es auch noch andere Möglichkeiten Captchas zu umgehen, indem man sie zum Beispiel von anderen Personen auf einer anderen Website lösen lässt. Der Angreifer fängt also ein Captcha ab und lässt dieses einfach von einem Benutzer auf der eigenen Website lösen. Des Weiteren könnte der Angreifer die Webseite mit den Login-Feldern so manipulieren, dass der Browser des Benutzers die Lösung des Captchas halt doch mitsendet. (Es läuft ja alles über HTTP ab.)

Für einen Manipulationsversuch des Logins müsste der "Feind" so viel Kontrolle über die HTTP Verbindung haben, das jede Aktion, abgesehen von eventuell SSL, für die Katz sein. Weil dann kann er auch gleich das Klartextpasswort mitsenden (notfalls in einem weiteren Hidden Input Element)

Da hast du natürlich recht, dass hätte ich schon bei der bisherigen Diskussion einbringen sollen. Demnach wäre das Hashen von Passwörtern sogar komplett sinnlos, da es nur erfolgt, wenn der Angreifer die Seite nicht manipulieren kann. Wenn er in der Lage ist Pakete mitzulesen, müsste er sie eigentlich auch ohne einen erheblichen Mehraufwand verändern können. Ich kenne mich ehrlich gesagt in der praktischen Durchführung eines Angriffes nicht mehr gut genug aus, um den Mehraufwand beurteilen zu können. Theoretisch ist es aber definitiv möglich.

Aber du hast mich Überzeugt, ich hab die Idee verworfen. Der Entwicklungsaufwand sollte schon den Nutzen nicht übersteigen.

Für mich gibt es eigentlich nur zwei sinnvolle Lösungen: Entweder das Passwort im Klartext versenden oder TLS einzusetzen. Dabei gehe ich davon aus, das es nicht jedem möglich ist, einfach mal den Traffic eines Benutzers abzuhorchen oder zu manipulieren. Man müsste wahrscheinlich in das lokale Netz des Benutzers oder direkt in seinen Rechner eindringen oder irgendwie einen Namensserver manipulieren, sodass sich der Angreifer dazwischen schalten kann. Diesen Aufwand macht man sich wahrscheinlich keiner, wenn es sich nicht lohnt. Den normalen Anwender und auch viele Personen mit Erfahrung im Programmieren, sollte man jedoch von einem Angriff abhalten können. Jetzt könnte man natürlich argumentieren, dass professionelle Angreifer erfolgreich sein würde, jedoch könnte man diese auch nicht durch irgendwelche Javascript-Lösungen beeindrucken. Auch die vermeidliche Sicherheit durch Hashen könnten diese aushebeln, indem sie Seiten manipulieren. Wenn man also solche Angriffe für möglich hält und nach Abwägung von Kosten und Nutzen bereit ist sich dafür ein Zertifikat zu kaufen, dann sollte man dies tun. Alle andere Lösungen sind jedoch quatsch. Entweder alles oder nichts. Das ist meine persönliche Meinung.

Viele Grüße Novi

--
"(...) deshalb mag ich Binärtechnik. Da gibt es nur drei Zustände: High, Low und Kaputt." (Wau Holland)