suit: Fragwürdige Literatur (web & mobile Developer, Ausgabe 11/2013)

Beitrag lesen

Idealerweise wird das Passwort schon am Client per JavaScript gehasht

Idealerweise werden alle Daten SSL-verschlüsselt übertragen.

SSL ist prinzipiell nicht mehr sicher.

Das Hashen auf dem Client ist eher ein Sicherheitsverlust, weil man von einer clientseitigen Implementierung abhängig ist, die auf tausenden unterschiedlichen Geräten läuft und viel einfacher angreifbar ist.

Die meisten verbreiteten und gebräuchlichen Streuwert-Algorithmen sind Quelloffen, das ist bei kryptologischen Funktionen ein essentielles Sicherheitsmerkmal - ob das jetzt MD5 oder Blowfish ist, spielt keine Rolle.

In JavaScript habe ich nicht browserübergreifend Zugriff auf einen brauchbaren Seed für einen kryptographisch sicheren Zufallszahlengenerator. Math.random() ist kein guter Seed.

Das ist in der Tat ein Angriffspunkt, ebenso ist ein möglicher Angriffspunkt ein infizierter Rechner, der den clientseitigen Hash-Algorithmus ersetzt und somit absichtlich ein bekanntes Passwort in die DB schreiben lässt.

Wenn ich Krypto zuverlässig auf dem Server machen kann, dann sollte ich das tun.

Ja, da stimme ich dir zu - bei _neu schreiben_ eines Passworts übernimmt das der Server, bei jedem Login kann der Hash aber durchaus vom Client erzeugt werden - da dies durchaus die Sicherheit erhöht, da das Passwort auf dem Übertragungsweg nicht verloren gehen kann.