Überall, wo ich hinschaue, heißt es, dass Server Passwörter in gehashter Form speichern, aber dann gibt es die neuesten Nachrichten über Hacker, die Passwörter von großen Unternehmen stehlen. Was fehlt mir?
Überall, wo ich hinschaue, heißt es, dass Server Passwörter in gehashter Form speichern, aber dann gibt es die neuesten Nachrichten über Hacker, die Passwörter von großen Unternehmen stehlen. Was fehlt mir?
Es gibt zwei häufige Fehler, die darüber hinaus dazu führen, dass Datenbanken oder Dateien gestohlen werden.
Leider speichern viele Systeme trotz aller Sicherheitsempfehlungen immer noch Klartextkennwörter.
Hashed Passwörter sind technisch nicht umkehrbar, aber wie von anderen betont wurde, ist es möglich, Millionen von Passwort-Vermutungen zu hashen und dann einfach nach Übereinstimmungen zu suchen. In der Tat ist es normalerweise so, dass Tabellen mit vorberechneten Passwörtern und Hashes (Rainbow Tables) verfügbar sind und zur Suche nach Übereinstimmungen verwendet werden. Eine gute Regenbogentabelle kann eine hohe prozentuale Übereinstimmung in Bruchteilen einer Sekunde pro Passwort-Hash unterstützen.
Verwenden eines Salzes ( eine zusätzliche nicht geheime Erweiterung des Passworts ) im Hash verhindert die Verwendung vorberechneter Regenbogentabellen.
Die meisten Kompromissierer hängen von Regenbogentabellen ab. Das Berechnen eines eigenen Hash-Sets ist sicherlich möglich, aber es ist extrem zeitaufwändig (wie in Monaten oder länger), daher ist im Allgemeinen der Vanille-Hash anfällig.
Die Verwendung eines Salzes stoppt Regenbogentabellen und eine hohe Anzahl von Runden von gehashten Hashes von Hashes kann einen brutalen Übergang von Monaten zu Jahren oder länger bewirken. Die meisten Institutionen implementieren diese Sicherheitsstufe einfach nicht.
Wenn Sie hören, dass Passwörter gestohlen wurden, melden Unternehmen dies manchmal, auch wenn nur gestohlene Passwörter gehasht wurden. Auf diese Weise können Sie Maßnahmen ergreifen, falls sie beschädigt sind. Leider gibt es immer noch Unternehmen, die ihre Passwörter falsch speichern. Wenn Sie beispielsweise nach der Rockyou-Passwortverletzung suchen, werden Sie feststellen, dass sie ihre Passwörter im Klartext gespeichert haben, was bedeutet, dass sie kompromittiert wurden, sobald sie gestohlen wurden. In anderen Fällen, z. B. bei der Verletzung des Adobe-Kennworts, wurde die Speicherung der verschlüsselten Kennwörter in der Datenbank falsch gehandhabt. In anderen Fällen verwenden Unternehmen Hashing für ihre Passwörter, verwenden jedoch unsichere Hashing-Algorithmen oder salzen ihre Passwörter nicht richtig. Kurz gesagt, wenn ein Unternehmen die empfohlenen Methoden zum Speichern von Passwörtern befolgt, sollten die Passwörter theoretisch in ihrer Hash-Form sicher sein, aber ein gutes Unternehmen wird seine Kunden dennoch über den Verstoß informieren. Es gibt jedoch viele Beispiele, in denen Unternehmen Passwörter nicht korrekt speichern, was dazu führt, dass sie recht schnell geknackt werden.
Sie haben eine große Anzahl potenzieller Kennwörter * sup> und prüfen dann, ob jede Ausgabe mit Hashes aus der Datenbank für gestohlene Kennwörter übereinstimmt. Brute-Force-Cracking ist möglich, da Personen nicht normalerweise höchst unvorhersehbare Kennwörter auswählen.
Wenn eine Kennwortdatenbank gestohlen wird, enthält das gestohlene Material alle Informationen notwendig, um Offline-Cracking zu machen. (Es ist einfach ein Vermutungs- und Überprüfungsprozess. Andere Methoden sind möglicherweise mit weniger sicheren Hashing- oder Kennwortspeichermethoden verfügbar.)
* Wenn Salze verwendet werden, muss der Cracker diese ebenfalls berücksichtigen . Wenn jedes Konto ein eindeutiges Salz verwendet, können Cracker nicht einfach alle ansprechen, indem sie jedes Kandidatenpasswort einmal hashen. Wenn mehrere Konten als Ziel ausgewählt werden, muss das Kennwort, das Sie ausprobieren möchten, für jedes Salt einmal gehasht werden. Wenn Passwort-Hashes ungesalzen sind oder alle dasselbe Salz verwenden, ist es viel einfacher, nicht zielgerichtete Angriffe auszuführen. Sie müssten ein Kandidatenkennwort nur einmal hashen, um die vollständige Liste der Benutzer mit diesem Kennwort zu ermitteln. Salze machen auch nutzlose Versuche, die Vorberechnung von Hashes zu verwenden, um Cracking-Aufwand zu sparen. Salze reduzieren NICHT die Anzahl der Hashes, die ausgewertet werden müssen, wenn nur ein Konto als Ziel ausgewählt wird. Abgesehen von diesen Nuancen bleibt die Grundlage für das Knacken von Passwörtern ein Vermutungs- und Überprüfungsprozess. Sup> sub>
Hashing von Passwörtern mit vorbildresistenten Funktionen mit einer ausreichend unvorhersehbaren Eingabe reicht aus, um ein Passwort nicht wiederherzustellen. (Ein unmenschlich sicheres Passwort.)
Die meisten Menschen tun dies jedoch nicht in der realen Welt. Eine gestohlene Datenbank mit Hashes ist möglicherweise genauso besorgniserregend wie eine Liste nicht verwaschener Passwörter für eine große Teilmenge von Benutzern eine typische Website.
Wenn der Passwort-Cracker ein Kandidaten-Passwort findet, dessen Hash mit dem in der Datenbank gespeicherten übereinstimmt, hat er das ursprüngliche (schwache) Passwort wiederhergestellt.
Wenn eine Hash-Funktion nicht vor dem Bild resistent ist (auch wenn die Ausgabe des Hashs zu kurz ist), kann ein Guess-and-Check-Verfahren zu falsch positiven Ergebnissen führen. (Alternative Kennwörter sind nicht mit dem Original identisch.)
Die Konten von Benutzern des Unternehmens mit der Datenverletzung sind immer noch anfällig , da diese Kennwörter das Konto eines Benutzers entsperren, auch , wenn sie nicht mit dem ursprünglichen Passwort identisch sind. (Der Server kann nicht feststellen, ob es sich um das ursprüngliche Kennwort handelt. In diesem Fall stimmt der Hash immer noch mit dem in der gestohlenen Datenbank überein.)
Verwenden Sie natürlich nicht absichtlich eine unsichere Hash-Funktion. Es ist weiterhin möglich, das ursprüngliche Passwort abzuleiten oder die Anzahl der Möglichkeiten einzugrenzen. Dies würde Benutzer, die Kennwörter auf anderen Websites wiederverwenden, immer noch besonders anfällig machen.
Es gibt andere Möglichkeiten, wie Kennwörter gestohlen werden können, die nicht aus einer Kopie einer Datenbank mit durchgesickerten Kennwort-Hashes stammen. Klartext-Anmeldeinformationen können protokolliert werden. (Zum Beispiel durch Beobachten des unverschlüsselten / entschlüsselten Netzwerkverkehrs, durch Hacken und Umschreiben von Servercode oder durch Verwenden von clientseitigen Fehlern.) Dann kann dieses Protokoll exfiltriert werden.
Und natürlich haben einige Unternehmen möglicherweise überhaupt keine sicheren Kennwortüberprüfungsschemata verwendet oder den Klartext durch einen Fehler 1, 2
Trotz der alternativen Erklärungen für einige Fälle von Massenkennwortverletzungen ist die Wiederherstellung von Klartextkennwörtern aus Kennwort-Hashes üblich und effektiv. Es ist jedoch nicht so effektiv, dass 100% der Hashes in jedem großen Datenbankleck wiederhergestellt werden.
Wenn Kennwörter mit einer kryptografischen Hash-Funktion verarbeitet werden, müssen Benutzer mit extrem starken Kennwörtern nicht so besorgt sein wie typische Benutzer. (Aber die meisten Leute überschätzen die Passwortstärke und ihre eigene Klugheit.) Nachdem sie erhebliche Ressourcen aufgewendet haben, um 99% der Hashes zu knacken, ist es wahrscheinlich nicht wert oder praktisch, die letzten 1% zu knacken. Starke Passwörter sind jedoch nicht gut, wenn sie nicht gehasht werden.
Entwickler sollten einen Algorithmus zum Strecken von Passwörtern verwenden. Diese Algorithmen versuchen nur, das Passwort-Hashing teurer zu machen. (Sowohl für legitime Benutzer als auch für Kennwortcracker.) Argon2 ist derzeit der beste Algorithmus zum Erweitern von Kennwörtern , insbesondere auf Intel / ARM-CPUs. Insbesondere Argon2 kann einen sehr langen Weg gehen, um den Anteil der Hashes zu reduzieren, die Risse bekommen. (Schwache Passwörter sind weiterhin knackbar.)
Viele Möglichkeiten:
Auch wenn Kennwörter vor dem Speichern gehasht werden sollten , ist dies nicht immer der Fall. Leider sind auch heute noch viele Passwörter als Klartext gespeichert. Stehlen Sie die Datenbank und holen Sie sich alle Passwörter.
Passwörter könnten woanders gespeichert werden. Passwörter können beispielsweise in Protokollen enthalten sein. Stehlen Sie Protokolle und rufen Sie alle Kennwörter ab, die in diesen Protokollen verwendet wurden.
Kennwörter können gehasht, aber nicht gesalzen sein. Sie erstellen also eine Liste mit Kennwörtern -> Hash-Kombinationen, die auf allen Arten von Kennwörtern basieren. Sie kehren diese Tabelle um, sodass sie zu Hash -> Passwort ( Nachschlagetabelle ) wird. Datenbank abrufen, Hashes in Kennwörter konvertieren, viele Kennwörter abrufen.
Kennwörter werden gehasht und gesalzen. Aber viele Benutzer verwenden sehr schwache Passwörter (123456, Passwort, Letmein, QWERTY ...). Versuchen Sie es mit Listen von Passwörtern für diese Hashes. Datenbank abrufen, Wörterbuchangriff auf Hashes ausführen, viele Kennwörter abrufen.
Variation der vorherigen anstelle einer vorher festgelegten Liste von Passwörter, versuchen Sie Passwörter basierend auf anderen Informationen, die Sie über den Benutzer haben (Benutzername, Vorname, Nachname, Geburtsdatum, E-Mail ...).
Noch eine Variante, da viele Benutzer dasselbe Kennwort erneut verwenden: Versuchen Sie, Kennwörter für dieselbe E-Mail / denselben Benutzernamen zu verwenden, die / der nach anderen Verstößen wiederhergestellt wurde .
Eine weitere Variante, wenn eine strenge Kennwortrichtlinie vorhanden ist, bei der Kennwörter regelmäßig geändert werden müssen: Wenn Sie ein vorheriges Kennwort für den Benutzer haben, versuchen Sie einfach, die endgültigen Nummern zu ändern : Wenn der Benutzer zu einem bestimmten Zeitpunkt das Passwort "joe12" hatte, versuchen Sie es mit joe13, joe14, joe15 ... Wenn Sie das Datum haben, an dem das ursprüngliche Passwort gültig war, und das Intervall für die Passwortänderung kennen, kann es sehr schnell gehen.
Passwörter werden gehasht und gesalzen, verwenden jedoch schwache (schnelle) Hashes . Wie # 4-7, aber Sie können viel schneller viel mehr Versuche ausführen, sodass Sie ein größeres Wörterbuch oder sogar ganz systematisch alle Kombinationen ausprobieren können ( Brute-Force-Angriff ).
Die Kommunikation zwischen Clients und Servern ist anfällig für Man-in-the-Middle (MITM) -Angriffe. Unterwegs werden Passwörter erfasst.
Sie führen Social Engineering durch. "Hallo, dies ist die IT-Abteilung. Es gibt ein Problem mit Ihrem Konto. Wir müssen etwas zurücksetzen. Können Sie mir Ihr Passwort geben?" Sie werden erstaunt sein, wie oft dies funktioniert, wenn es richtig gerahmt ist.
Mass Social Engineering, auch bekannt als Phishing : Senden Sie eine Massen-E-Mail-Kampagne an Melden Sie sich bei einer Site an, die alle diese Kennwörter erfasst.
Hacken Sie sich in die Site und ändern Sie sie so, dass alle empfangenen Passwörter an einen Remote-Server gesendet werden (oder protokolliert sie in einer Datei, die Sie später abrufen werden).
Das Gleiche, aber ändern Sie den clientseitigen Code, um dies zu tun. Könnte so einfach sein wie ein gespeicherter XSS -Hack.
Eine Variation der oben genannten: Keylogger .
Es gibt wahrscheinlich noch einige weitere Methoden, aber das gibt Ihnen eine Vorstellung davon, wie einfach es sein kann, Tonnen von Passwörtern wiederherzustellen.
Da wir nicht darüber diskutieren, wie die Passwörter gestohlen wurden, und noch mehr über die Folgen, werde ich die vielen Faktoren vermeiden, die Unternehmen implementieren sollten, um diese Datenverletzungen zu verhindern.
Wenn Sie eine Website erstellen und die Datenbank verwalten, liegt es an uns, diese Informationen effizient zu speichern. Wenn dies nicht der Fall ist, können Angreifer bei einem Datenverstoß Kennwörter auch in Klartext anzeigen, wie dies häufig der Fall ist (abhängig von der Art und Weise, in der diese gespeichert werden).
In Kurz gesagt, Sie würden nie wollen, dass dies passiert! - Das Knacken von Passwörtern ist eine sehr häufige und reale Sache, nur weil Passwörter gehasht werden, sind sie in keiner Weise sicher.
Angenommen, ein Unternehmen verfügt über 1000 Kundenkennwörter, die alle gehasht sind.
Angenommen, 600 dieser Kunden hatten ein Kennwort mit einer Länge von 8 Zeichen, wobei die Wahrscheinlichkeit besteht, dass diese Kennwörter geknackt werden innerhalb der ersten 5 Minuten (großzügig sein) ist sehr hoch.
"5 Minuten?! Aber sie wurden gehasht!" ....
Ja, aber die Passwörter dieser 600 Kunden waren immer noch schlecht, zusammen mit einem ebenso schlechten Hashing-Algorithmus.
Ohne zu sehr ins Detail zu gehen, um die Erklärung zu vereinfachen; Das Knacken von Passwörtern funktioniert, indem der Hash einfach mit einer Wörterbuchdatei von Wörtern abgeglichen wird und jedes Wort durchlaufen wird, um festzustellen, ob der Hash mit denen übereinstimmt, die von diesen 600 Kunden erhalten wurden. Ihr Passwort könnte beispielsweise sein:
Passwort : Sicherheit
MD5 Hashed : 2FAE32629D4EF4FC6341F1751B405E45
Ich führe dann nur einige günstige Hacking-Tools gegen diese Hashes aus, um "zu knacken" "sie.
Sollten Sie jemals Passwörter selbst speichern wollen, sollte MD5 vermieden werden, oben nur zu Beispielzwecken. Wenn Sie stattdessen nach den stärkeren Arten von Hashing-Algorithmen suchen, wird es für Angreifer viel schwieriger, die gestohlenen Passwörter erfolgreich zu verwenden.
Die kurze Antwort; Hashing oder das Format, in dem Sie Ihre Passwörter speichern, hat keinen Einfluss auf die Fähigkeit von Hackern, diese zu stehlen. Sie werden aufgrund einer Vielzahl unterschiedlicher Sicherheitslücken gestohlen. Es gibt eine Vielzahl von Angriffen, mit denen Passwörter abgerufen werden können (gehasht oder nicht).
Ein besonders wichtiger Punkt ist, dass wenn die Kennwortdatenbank sicher ist und nur dem legitimen Dienst zugänglich ist, jemand, der versucht, auf ein Konto zuzugreifen, diese nur einzeln über den legitimen Dienst ausprobieren kann. Wiederholte fehlgeschlagene Versuche können bemerkt, eine automatische Warnung bereitgestellt und geeignete Maßnahmen ergriffen werden, um weitere Anmeldeversuche aus derselben Quelle zu begrenzen.
Sobald die Kennwortdatenbank gestohlen wurde und Details des Hashing-Algorithmus bekannt sind, werden die Personen, die im Besitz der Datenbank mit gestohlenen Passwörtern sind, können Millionen oder Milliarden von Passwörtern gegen ihre Kopie der Datenbank testen, ohne dass jemand weiter darauf aufmerksam gemacht wird. Wenn sie eine gefunden haben, die mit ihrer Offline-Kopie funktioniert, tun sie dies erst dann Versuchen Sie, auf den legitimen Dienst zuzugreifen, der sich als einer der Benutzer dieses Dienstes ausgibt (vielleicht Sie!).
Ein erheblicher Teil der Benutzer verfügt über Kennwörter, die wahrscheinlich in der ersten Milliarde liegen, die ein Angreifer versuchen würde Es ist nur eine relativ kurze Zeit, bis der Angreifer auf einen erheblichen Teil der Konten zugreifen kann.
Benutzer, die wirklich sichere Kennwörter haben, sollten in der Lage sein, einen Kompromiss zu ignorieren, bei dem nur gehashte Kennwörter verwendet werden waren undicht d, aber viele Benutzer verfügen tatsächlich nicht über ausreichend sichere Kennwörter, um dieser Art von Offline-Angriffen zu widerstehen, sondern nur über solche, die für die automatische Überprüfung der Kennwortstärke der Website stark genug erscheinen. In der Regel geht es eher darum, sicherzustellen, dass die Konten ausreichend stark sind, um Online-Angriffen zu widerstehen gegen den legitimen Dienst.
Berücksichtigen Sie auch den folgenden Angriffsvektor für Webanwendungen:
Wenn der Angreifer den Frontend-Code ändern kann, können die Klartext-Passwörter mit einem kleinen Skript für eine Weile "beschnüffelt" werden.
Wenn das Skript vom Backend aus eingefügt werden kann, kann es so eingestellt werden, dass es nur Besuchern aus bestimmten Ländern angezeigt wird, um einen besseren Schutz vor automatisierten Automatisierungen zur Erkennung von Änderungen des Frontend-Codes zu gewährleisten, die in demselben Land ausgeführt werden, in dem sich die Anwendung befindet laufen von.
Das Speichern von Passwörtern in Hash-Form ist zwar wünschenswert, kann jedoch auch einige Schwierigkeiten bereiten. Wenn eine Entität im Namen eines Benutzers eine Anforderung an eine andere Entität senden muss und die zweite Entität die Übermittlung von Klartextkennwörtern zur Validierung erfordert, muss die erste Entität das Kennwort des Benutzers in einer Form halten, in die konvertiert werden kann Klartext.
Um dies zu ermöglichen, können Unternehmen Kennwörter in verschiedenen Arten von Hardware-Sicherheitsmodulen speichern, die alle Versuche prüfen, Kennwörter von ihnen abzurufen. Dieser Ansatz verringert viele der Gefahren, die mit der Speicherung von Klartextkennwörtern verbunden sind. Es kann nicht alle Gefahren mindern, aber wenn eine Entität befugt sein soll, im Namen eines Benutzers auf eine externe Entität zuzugreifen, und die externe Entität nichts anderes als das Kennwort des Benutzers als Beweis für diese Autorität akzeptiert, Einige der mit Klartextkennwörtern verbundenen Gefahren sind unausweichlich, unabhängig davon, was die erste Entität versucht.