Die Schwäche, auf die Sie anspielen, ist real. Ein wichtiger Punkt ist, dass der Angreifer nach einer Gefährdung des Servers kaum einen Anreiz hat, Kennwörter abzurufen, die Zugriff auf diesen Server gewähren - er ist bereits vor Ort. Menschliche Benutzer haben jedoch die Angewohnheit, Kennwörter wiederzuverwenden, und das ist ein großes Problem, da ein wiederverwendetes Kennwort dazu führt, dass sich Kompromisse auf einem Server genau so "verbreiten", wie Sie es erklären: Der Angreifer greift nach dem Kennwort P für Benutzer U und vermutet (leider meistens meistens), dass derselbe Benutzer U auf einigen anderen Servern dasselbe Kennwort verwendet hat.

Das Hashing auf der Clientseite ist eine gute Idee, aber es gibt Details :

Clientseitiges Hashing wird normalerweise unter dem Namen "Server Relief" ins Auge gefasst, um nicht die Sicherheit gegen böse Server zu erhöhen, sondern um dem Server die Verarbeitung vieler gleichzeitiger Benutzer zu ermöglichen, ohne die gesamte CPU für viel Hashing aufzuwenden. Da JavaScript das ist, was es ist, wird dies heutzutage nicht mehr häufig durchgeführt.

Das besteht also aus zwei Teilen.

Erstens wird der Server kompromittiert und zweitens werden anstelle von Kennwörtern Hashes an den Server gesendet.

Für den ersten Teil mit dem Server wird kompromittiert, ja, der Angreifer kann so ziemlich alles tun, was er will. Wenn sie den Server besitzen, können sie tatsächlich die Benutzernamen und Passwörter von den Benutzern erhalten, die an den Server übergeben werden. Aus diesem Grund müssen Server gegen Angriffe gehärtet und regelmäßig aktualisiert werden, damit sie so wenig Angriffsfläche wie möglich bieten.

Wenn der Client im zweiten Teil den Hash vorberechnet, ist dies der Fall Hash ist buchstäblich zum Passwort geworden. Wenn ein Angreifer die Datenbank mit Hashes gestohlen hat (aber den Webserver nicht kompromittiert hat), muss er nicht die Kennwörter finden, die sich in diese Hashes verwandeln. Er kann den Hash einfach an den Webserver senden und er würde sich authentifizieren, da der Server bereits einen Hash als Eingabe zum Vergleich mit seiner Datenbank erwarten würde.

Sie könnten wahrscheinlich nicht verhindern, dass der an Clients zur Ausführung gesendete Code einfach serverseitig geändert wird, wenn Ihr Server vollständig im Besitz ist.

Wenn dies jedoch Teil einer vorinstallierten oder einer vorinstallierten Version ist Vorverteiltes Softwarepaket mit unterschiedlichen Client- und Serverkomponenten (dies kann Webanwendungen mit heruntergeladenen Komponenten umfassen, die auf dem Client-Betriebssystem gespeichert bleiben), clientseitiges Hashing kann in dem Sinne nützlich sein, dass der Angreifer diese Hashes wahrscheinlich weiterhin verwenden kann Bei der Authentifizierung bei IHRER Datenbank (oder beim Zurücksetzen von Kennwörtern, wie in einem der Kommentare erwähnt) haben sie keinen einfachen Zugriff mehr auf das Klartextkennwort, das für gesalzenes Hashing und Datenbankspeicher an Ihren Server (über SSL) gesendet wird.

Wenn Sie also einen Client haben, der dasselbe Kennwort an mehreren Stellen verwendet, solange der Hash nicht trivial umkehrbar ist , hat Ihr bestimmter Serverkompromiss keine Anmeldeinformationen mehr offengelegt, die der Angreifer an anderer Stelle verwenden kann . Dies würde durch zufälliges clientseitiges Salting verbessert (so dass Sie nicht denselben Hash erhalten, den derselbe Algorithmus immer für diesen Klartext generieren würde).

Ich finde, dass viele Leute (insbesondere im PHP-Bereich) falsch verstehen, was Hashing bewirkt. Hier ist die Methode

1. Der Benutzer erstellt ein Konto und sendet Ihnen eine Kombination aus Benutzername und Passwort (hoffentlich sicher über HTTPS).
2. Das Passwort wird auf dem Server gehasht (mit einem zufälligen Salt) ) und mit dem Benutzernamen gespeichert
3. Der Benutzer kommt später zurück und gibt sein Klartextkennwort ein.
4. Der Server findet den gespeicherten Hash für den Benutzernamen. Mit $ 2y -Hashes (BCRYPT) werden die Kosten und das Salz in derselben Zeichenfolge gespeichert. Unter Verwendung der gleichen Kosten und des gleichen Salt generiert der Server einen Hash unter Verwendung des vom Benutzer angegebenen Kennworts (denken Sie daran, dass Hashes nur in eine Richtung ausgeführt werden).
5. Wenn der generierte Hash mit dem gespeicherten Hash übereinstimmt, ist alles gleich können wir den Benutzer authentifizieren.
ol>

Angenommen, jemand hackt Ihren Server, sind Ihre Benutzer besser geschützt, da das Salt für jeden Hash zufällig ist. Als solches müssten Sie jedes Passwort einzeln brutal erzwingen (die Kerntheorie hinter jeder Art von Sicherheit besteht darin, die Kosten für etwas so weit zu erhöhen, dass jemand es nicht mehr versucht). SHA1 und MD5, die zuvor beliebten Hashing-Systeme, wurden fast immer ohne Salz erzeugt, wodurch sie nicht nur für Schwachstellen im Hash selbst, sondern auch für Regenbogentabellenangriffe anfällig sind (ohne Salz sind SHA1 und MD5 für eine bestimmte Zeichenfolge gleich).

Es gibt wirklich keine Möglichkeit, diese Client-Seite zu erstellen, da

• der Client in den Händen des Feindes liegt. Sie müssten dem Client also alles senden, was er zum Generieren des Hashs benötigt (insbesondere das Salz), und ihn dann den Hash zurückgeben lassen.
• Wie in einer anderen Antwort erwähnt, wird der Hash zu diesem Zeitpunkt zum Hash Passwort, weil sie dir das schicken. Mit anderen Worten, obwohl ich möglicherweise nicht weiß, wie das Kennwort lautet, führen Sie dennoch einen einfachen Zeichenfolgenvergleich durch, anstatt einen sicheren Hash zu generieren, damit ich

Nein, Inspect Element oder ähnliches ist in den meisten Browsern vorhanden, sodass jeder den clientseitigen Code umgehen kann. Wenn ein Hacker Zugriff auf die Datenbank hat, kann er den Hashing-Code mithilfe von Inspect Element entfernen und die Hashes als Kennwörter eingeben oder die Seite so bearbeiten, dass sie ohnehin nicht gehasht wird. Wie wäre es stattdessen mit einem Skript, das den Server stoppt, wenn es erkennt, dass eine Seite von einem Hacker geändert wurde?