Frage:
Bedeutet das Hashing von Passwörtern auf der Serverseite nicht, dass eine kompromittierte Website Passwörter anfällig machen könnte?
James
2015-08-13 00:37:50 UTC
view on stackexchange narkive permalink

Der Datenverkehr wird also auf eine Website verschlüsselt, damit das Kennwort während der Übertragung sicher ist. Wenn die Website gehackt wird, enthält die Datenbank nur Hashes.

Der Hacker konnte jedoch kein serverseitiges Skript erstellen um die Benutzernamen und Passwörter, mit denen Sie sich auf der Website anmelden, in einer Datei zu speichern, da diese entschlüsselt und noch nicht gehasht sind? Dies würde nicht jeden Benutzer erreichen, es würde ihm jedoch ermöglichen, Benutzerkennwörter anzuzeigen, die versuchen, sich auf der Site anzumelden, während diese gefährdet ist.

Wäre es nicht besser, Kennwörter auf der Clientseite zu hashen?

Niemand wird sich mit [SRP] befassen (https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol)? Dies ist wichtig, da es das Kennwort vor dem Server schützt, ohne * Kennwortäquivalente * zu verwenden, und nur das Problem hat, dass ohne eine native Implementierung durch Browser (die [anscheinend niemand will]) (http://stackoverflow.com/a/2842980) / 1850091)), kann böswillig ersetzt werden, wie es beim Hashing der Fall ist. (* Übrigens, unterstützen Sie neben Such-Bots immer noch Nicht-Javascript-Benutzer? Diese Bots melden sich nicht an! *)
Siehe [Digest Access Authentication] (https://en.wikipedia.org/wiki/Digest_access_authentication)
Fünf antworten:
#1
+59
Thomas Pornin
2015-08-13 01:00:13 UTC
view on stackexchange narkive permalink

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 :

  • Was auch immer der Client an den Server sendet, sei es das Das Passwort selbst oder das Hash-Passwort gewährt Zugriff. Es ist passwortäquivalent . Wenn der Server diese Hashes "wie sie sind" in seiner Datenbank speichert, befindet er sich in der gleichen Situation wie ein Server, der Klartextkennwörter speichert, und das ist schlecht. Daher MUSS der Server auch Hashing durchführen.

  • Clientseitiges Hashing tritt nur auf, wenn auf der Clientseite Code vorhanden ist, der das Hashing ausführt. In einem Webkontext bedeutet dies JavaScript. Leider ist JavaScript bei kryptografischen Implementierungen schlecht. Insbesondere ist es ziemlich langsam, sodass das clientseitige Hashing nicht die vielen Iterationen verwenden kann, die normalerweise für ein gutes Kennwort-Hashing erforderlich sind (siehe dies für Details). Dies würde auch für Clients ohne JavaScript nicht funktionieren.

  • In einem Webkontext wird das clientseitige Hashing, falls es auftritt, durch den gesendeten JavaScript-Code durchgeführt vom Server . Wenn der Server unter feindliche Kontrolle geraten ist, sendet er möglicherweise schädliches JavaScript, das vorgibt, das Hashing durchzuführen, dies jedoch nicht. Der Benutzer wird nicht klüger sein. Somit ist das Grundproblem nicht gelöst.

  • 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.

    Wissen Sie, ich habe gerade festgestellt, dass clientseitiges Hashing tatsächlich Sinn macht, denn wenn der Angreifer die Klartextkennwörter abrufen möchte, muss er die Tatsache offenlegen, dass er den Server kompromittiert hat (die Quelldateien ändern), wenn er ordnungsgemäß überwacht wird. Es zwingt den Angreifer zu einem aktiven Angriff. Natürlich hilft es in * den meisten * Fällen überhaupt nicht, aber zumindest hat es theoretische Vorteile (ich dachte, es hätte keine).
    Clientseitiges Hashing hilft auch bei dem Problem, dass ein Benutzer an mehreren Standorten dasselbe Kennwort verwendet. Unter dem Gesichtspunkt der Kennwortäquivalenz mag dies für diese Site zutreffen, aber dieser Hash kann nicht für mehrere Sites verwendet werden (zum Beispiel, wenn der Domainname am Hashing beteiligt ist).
    @DavidMulder Nicht wirklich - Wenn ein Angreifer den Server kontrolliert, kann er eine Anfrage von Ihrem Skript auf eine Weise an sein bösartiges Skript umleiten, die viel seltener und effektiver überwacht wird. Sie müssen die eigentlichen Quelldateien nicht selbst ändern, sondern müssen sie nur ersetzen.
    @JohnCarpenter - Thomas sprach darüber, warum dies unzureichend ist, clientseitiges Javascript nicht schnell genug ist, um mit angemessener Sicherheit zu hashen, und Hash-Cracking ist heutzutage zu weit fortgeschritten, um sich auf unzureichende Sicherheit zu verlassen. Wenn Sie ignorieren, dass ein gefährdeter Server den Client nicht anweisen muss, das Kennwort tatsächlich zu hashen. Ein kompromittierter Server ist das ganze Spiel, Sie können nichts tun, um sich selbst zu retten.
    @Jason Nicht sagen, dass die aktuelle Überwachung bereits ausreichend ist, aber zumindest überwacht werden kann. Fordern Sie einfach eine angemessene Anzahl von Seiten von Ihrer Website an und geben Sie bei jeder Änderung eine Warnung an den Entwicklungsleiter aus. Wenn dies mit einer neuen Version übereinstimmt, die in die Produktion gebracht wird: Gut. Wenn nicht: Gehen Sie und überprüfen Sie.
    @Jason Ehrlich gesagt, ich habe keine Ahnung, woher dieser Glaube kommt, dass Sie auf der Client-Seite keinen ausreichend starken Hash verwenden können. Selbst wenn Sie sich für etwas wie bcrypt als Ihre Hashing-Lösung entscheiden (was ich den meisten Leuten ehrlich gesagt nicht empfehlen würde), können Sie es problemlos mit 4096 Iterationen ausführen, wenn Sie möchten (oder sogar mehr, wenn Sie * wirklich * möchten ).
    @Jason Ich sage nicht, dass es kugelsicher ist, aber andererseits ist nichts wirklich. Mein einziger Punkt war, dass das Hashing auf der Clientseite eine weitere Ebene darstellt, die es einem böswilligen Hacker erschwert, Kennwörter zu erhalten, die auf anderen Websites verwendet werden können. Und wie David sagte, würde dies eher einen aktiven Angriff als eine passive Beobachtung erfordern.
    @DavidMulder Sie schlagen also eine Nachrichtenübersicht in einem Durchgang vor, wie zum Beispiel Sha256? Dies ist heutzutage äußerst unsicher - jedes Passwort-Hashing, das nicht für große Computerressourcen ausgelegt ist, kann schnell und einfach geknackt werden, meistens in Minuten oder Stunden. Nachdem Sie eine reine Javascript-Implementierung von PBKDF2 für den Knoten geschrieben und mit der integrierten PBKDF2 aus der Kryptobibliothek verglichen haben, können Sie auf dem Client keine Anzahl von Iterationen verwenden, die erhebliche Ressourcen auf dem Server (oder auf dem des Angreifers) verbrauchen Maschine).
    @JohnCarpenter Vorsicht vor "Sicherheit", die Ihnen Schritte hinzuzufügen scheint, die für einen Angreifer wirklich trivial sind. Sie lenken Ihre Aufmerksamkeit und Aktivität von Dingen ab, die wirklich einen Unterschied machen.
    @Jason SHA256 ist heutzutage absolut unsicher? Das ist nur Müll. Ja, wenn Sie ein Passwort mit sehr geringer Entropie haben (ein wörtliches Wörterbuchwort), der Hash richtig gesalzen wurde, Sie das Salz kennen und eine GPU haben, um das Hashing auszuführen, dann werden Sie es in einer angemessenen Zeit (ungefähr einer Sekunde) tun in der Lage sein, das Passwort zu finden. Bei einer durchgesickerten Datenbank mit SHA256-Passwörtern, bei der einige von ihnen eine hohe Entropie aufweisen, wenn Sie alle (Forts.)
    Ich werde in ein paar Millionen Jahren auf dich warten. Ich meine, Hashing hat definitiv einen Platz, aber solange das Passwort nicht auch für die Verschlüsselung verwendet wird, würde ich persönlich leicht SHA256 oder SHA512 auswählen. Oh und, stimme deinem Punkt in deinem letzten Kommentar vollkommen zu. Ein weiterer Grund, einfach einen normalen Hashing-Algorithmus zu wählen, anstatt mit einer (clientseitigen?) Dynamisch steigenden Kosten-Verschlüsselungslösung herumzuspielen.
    @DavidMulder Die * effektive * Entropie von Passwörtern nimmt mit alarmierender Geschwindigkeit ab. Was Sie als "hohe Entropie" betrachten, kann aufgrund der Art und Weise, wie Menschen Passwörter erstellen, immer noch leicht geknackt werden (siehe [diesen Artikel] (http://arstechnica.com/security) / 2013/05 / wie-Cracker-Hackfleisch-aus-deinen-Passwörtern machen /)). Wenn Sie über ein maschinengeneriertes Zufallskennwort sprechen, stimme ich Ihnen zu, aber das ist immer noch eher die Ausnahme als die Norm.
    #2
    +13
    Greg
    2015-08-13 00:49:46 UTC
    view on stackexchange narkive permalink

    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.

    Ja, aber andererseits dient das Hashing von Passwörtern nicht dazu, den Zugriff der Benutzer auf diese Site zu schützen. (Wenn Sie die Datenbank pwn, können Sie trotzdem alle Benutzerdaten kopieren; Sie * benötigen * nicht ihre Anmeldeinformationen.) Der Zweck des Hashing von Passwörtern besteht darin, all jene armen idiotischen Benutzer zu schützen, die überall dasselbe Passwort verwenden. Damit die Hacker nicht auf den gesamten Rest ihrer Online-Identität zugreifen können.
    @MasonWheeler Dies setzt voraus, dass das einzige Ziel des Angreifers darin besteht, auf Daten zuzugreifen, die in der Datenbank gespeichert sind. Was ist, wenn sein Ziel darin besteht, auf ein CMS zuzugreifen und Webseiten zu entstellen oder Benutzerkonten zu löschen, indem Sie sich als Administrator anmelden?
    @Eric Wenn ich die Datenbank pwn, könnte ich nicht (1) eine Kopie des Hash-Passworts des Benutzers erstellen, (2) ein neues Passwort auswählen, (3) den Hash des neuen Passworts auf dem Computer, (3) das Hash-Passwort des Benutzers ersetzen mit meinem Hash-Passwort, (4) als Benutzer authentifizieren, (5) tun, was ich will, (6) mein Hash-Passwort durch das Hash-Passwort des Benutzers ersetzen, damit der Benutzer nicht weiß, dass ich sein Passwort geändert habe.
    @emory Wenn Sie Schreibzugriff auf die Datenbank haben, ja.
    Beachten Sie, dass ein häufiges Szenario für illegalen Zugriff der Zugriff von Angreifern auf Sicherungsmedien ist. (Ich habe gehört, dass Backups in den Papierkorb / das Recycling geworfen werden.) Wenn auf der Website keine aggressive Richtlinie zum Ändern von Kennwörtern mit häufigem Kennwort vorhanden ist, ist eine alte Sicherung des Kennwortspeichers (Hash) möglicherweise immer noch sehr aktuell. Dieses und andere Szenarien können zu einem einmaligen schreibgeschützten Zugriff auf die Kennwortdaten führen (z. B. kann ein Zero-Day-Code-Injection-Angriff gegen das Anmeldeprogramm dies und nur das ergeben, ohne einen breiteren Zugriff auf die Site bereitzustellen).
    #3
    +1
    Bruno
    2015-08-13 11:18:11 UTC
    view on stackexchange narkive permalink

    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).

    #4
    +1
    Machavity
    2015-08-13 20:16:35 UTC
    view on stackexchange narkive permalink

    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.
    6. 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
    einbrechen kann
    #5
    -2
    Lucas
    2015-08-14 02:55:47 UTC
    view on stackexchange narkive permalink

    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?

    "Element inspizieren" ist nicht das, was Sie wollten
    Der Zugriff auf den Code, der das Hashing ausführt, reicht nicht aus. Sie müssen dennoch wissen, was in den Algorithmus eingegeben wurde, um den Hash zu generieren. Wie würden Sie ein System implementieren, um eine Seite, die von einem Hacker geändert wurde, anhand einer legitimen Änderung zu erkennen oder mit dynamischen Seiten umzugehen?
    Das macht keinen Sinn. Wenn ein Hacker Zugriff auf den Server hat, kann er "inspect element" auf keinem anderen Client als seinem eigenen verwenden.


    Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
    Loading...