Frage:
Wie werden Passwörter von Unternehmen gestohlen, wenn sie nur Hashes speichern?
W2a
2019-03-17 00:44:39 UTC
view on stackexchange narkive permalink

Ü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?

Passwörter könnten auch gestohlen werden, indem man sie an den Punkten abhört, an denen sie unverschlüsselt vorbeikommen.Und zumindest in einem Punkt sind sie unverschlüsselt, nämlich auf der Tastatur des Benutzers.
_ "Überall, wo ich hinschaue, heißt es, dass Server Passwörter in Hash-Form speichern" _ Nein, es heißt, Server sollten Passwörter in Hash-Form speichern !!
Wenn Ihr Passwort "123abc" lautet, wird Ihr Konto nach dem Diebstahl der Datenbank durch kein Hashing, Salting oder Pepping geschützt.
Sie müssen die Menschen auch über Sicherheit aufklären.Wenn Ihr Passwort genügend Entropie hat, verwenden Sie Hashes und Salt, aber Ihre Mitarbeiter schreiben Passwörter auf das Post-It und lassen sie herum oder geben sie einfach an den Kollegen weiter, der "diese Datei wirklich auf dem Server benötigt". Sie werden Probleme haben.Suchen Sie nach "Social Engineering"
Ich habe lange genug an einem Lebensmittelschalter gearbeitet, damit ich Ihnen für ein halbes Dutzend Combos, wenn Sie mir die Gesamtsumme eines Kunden mitteilen, sagen kann, was er bestellt hat, ohne eine Quittung oder Kenntnis seiner jeweiligen Bestellung.
Relevante xkcd: https://xkcd.com/1286/
Fast alle Verstöße beginnen entweder mit Social Engineering oder dem Finden eines schwachen Passworts und dem anschließenden Eintauchen in das System.
Weil sich einige Unternehmen wie blutige Idioten verhalten: https://krebsonsecurity.com/2019/03/facebook-stored-hundreds-of-millions-of-user-passwords-in-plain-text-for-years/
Acht antworten:
user10216038
2019-03-17 04:42:10 UTC
view on stackexchange narkive permalink

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.

Ich stimme Ihrer Aussage nicht zu, dass "die meisten Kompromissierer von Regenbogentischen abhängen".Obwohl sie in einigen Situationen nützlich sind, deuten Hinweise darauf hin, dass das Knacken von Passwörtern immer noch beliebter ist, da es unabhängig von Salting, verschiedenen Hash-Typen und iterativem Hashing weiterhin nützlich ist.
Salze verhindern nicht die Verwendung vorberechneter Regenbogentabellen oder stoppen Regenbogentabellen.Sie machen es nur um Größenordnungen schwieriger.Denken Sie daran, es ist möglich (aber so unwahrscheinlich, dass wir sicher so tun können, als würde es niemals passieren), dass ein Zufallszahlengenerator Ihr Passwort beim ersten Versuch erraten könnte.
* "Hashed Passwords sind technisch nicht umkehrbar" * ... wahr, aber irreführend, da Sie es nicht umkehren müssen, benötigen Sie nur ein Vorbild, das auf dasselbe verweist.
Technisch gesehen sind Hash-Passwörter auch vorbildlich (vorausgesetzt, sie verwenden einen vernünftigen Hash-Algorithmus).Es ist nur so, dass die meisten Passwörter leicht zu erraten sind.
Nur zu Ihrer Information, der Ausdruck ist "über und über", nicht "über und über".Wenn dies ein einfacher Tippfehler ist, ignorieren Sie mich bitte.
@Mehrdad Aber das ist ein weiterer Grund, warum das Salzen so wichtig ist - selbst wenn Sie eine Kollision auf dem Hash finden (MD5 ist heute trivial zu kollidieren und wird immer noch häufig verwendet), funktioniert die Kollision * nicht * gegen andere Systeme.
Regenbogentabellen sind auch nicht wirksam gegen lange Passwörter mit niedriger Entropie (l33t-ified-Filmzitate usw.), wohingegen die besten Cracking-Tools sind.Sie waren verheerend gegen alte LanMan-Passwörter, aber ich glaube nicht, dass sie für irgendetwas anderes weit verbreitet sind.
"... viele Systeme speichern immer noch Klartextkennwörter."Jep.Vor ungefähr 2 Jahren haben wir eine Kopie einer Datenbank erhalten, für die wir einen Ersatz erstellt haben.(Wir wollten Daten migrieren.) Wer sie abgeladen und an uns gesendet hat, hat sich nicht die Mühe gemacht, alle Klartext-Passwörter daraus zu entfernen, was bedeutet, dass ich mich in einem Live-Regierungssystem als jemand ausgeben konnte, den ich wollte.
Auf der Website plaintextoffenders.com wird [eine Liste von Unternehmen] (https://github.com/plaintextoffenders/plaintextoffenders/blob/master/offenders.csv) gespeichert, in der Ihre Passwörter im Klartext oder in einem anderen wiederherstellbaren Format gespeichert sind.Die Liste enthält derzeit über 5.000 Einträge.
@anaximander Ich finde zumindest einige ihrer Einträge verdächtig;Der angebliche "Beweis" für die Speicherung von Klartext scheint in einigen Fällen * willkommene * E-Mails zu sein, in denen das Passwort * generiert * wurde.Einer, den ich gesehen habe, warnt sogar davor, dass sie Ihr Passwort nicht für Sie abrufen können.
@DoktorJ Das ist auch ein Sicherheitsproblem.Technisch gesehen speichern einige von ihnen möglicherweise Passwörter korrekt, aber sie generieren ein Passwort und senden es Ihnen in einer E-Mail, bevor sie es speichern.Dies selbst ist jedoch eine schreckliche Möglichkeit, mit Passwörtern umzugehen.Die Website zielt darauf ab, Unternehmen zu entlarven, die beide Praktiken anwenden, und unterscheidet daher nicht.Das Wesentliche ist, dass sie Passwörter durch schreckliche Sicherheitspraktiken im Klartext offenlegen.
@jpmc26 Ich kann jetzt meinen ISP anrufen und ihn bitten, mein Konto wiederherzustellen.Sie werden mir telefonisch meinen aktuellen Benutzernamen und mein Passwort mitteilen.
Wenn sie ohne Salz haschen, werden einige Passwörter auch ohne Regenbogentabelle erraten.Jeder, der dasselbe Passwort verwendet, wird demselben Hash zugeordnet, und die Frequenzanalyse macht es dann einfach herauszufinden, wer "Passwort123" usw. verwendet.
Dam30n
2019-03-17 01:28:32 UTC
view on stackexchange narkive permalink

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.

Und selbst wenn Sie alles richtig machen, macht es der Diebstahl aller gehashten Passwörter (vermutlich zusammen mit Benutzernamen oder E-Mails) viel einfacher, andere Angriffe auf die Passwörter durchzuführen - insbesondere mit alten Mechanismen wie MD5, Salting oder nicht.Und da die meisten Leute auf mehreren Websites dasselbe Passwort verwenden und die Passwörter immer noch oft genug schwach sind ... Zugegeben, wenn Sie einen guten langsamen Hash mit richtigem Salting verwenden, sind die Auswirkungen sehr gering.
Future Security
2019-03-17 02:52:58 UTC
view on stackexchange narkive permalink

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

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

"Sie haben eine große Anzahl von Passwörtern und prüfen dann, ob die Ausgabe mit einem der gespeicherten Hashes übereinstimmt."Salting besiegt dies.
@Taemyr Es ist mir nicht klar, dass dies vorberechnete Hashes bedeutet, obwohl es etwas klarer sein könnte.Das Salzen macht Wörterbuchangriffe nur rechenintensiver und eine Vorberechnung unmöglich.
@Taemyr Außer wenn sie es geschafft haben, Ihre Systeme so stark zu kompromittieren, dass sie Ihre Datenbank stehlen, haben sie es möglicherweise auch geschafft, Ihr Salz zu stehlen.
Ich wollte die Dinge nicht weiter komplizieren, indem ich ins Salzen ging, aber an diesem Punkt kann ich es auch, da die Frage mehr Verkehr bekam.Im Idealfall würde ich die gleichen Informationen in einem einfacheren, besser organisierten Format angeben ... Das Web vereinfacht den Grund für die Verwendung von Salzen zu stark, um "sicherer" oder "absolut sicher" zu sein.Sie machen die Herde sicherer, aber nicht den Einzelnen.Salze können mithilfe von Nachschlagetabellen vollständig gegen das "Umkehren" von Hashes wirksam sein.Sie tun überhaupt nicht viel, um gezielte Angriffe zu verlangsamen.Aber jeder, der keine langen, zufälligen, einzigartigen Salze verwendet, hat einen massiven Fehler gemacht.Verwenden Sie auch Argon2
jcaron
2019-03-18 19:22:11 UTC
view on stackexchange narkive permalink

Viele Möglichkeiten:

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

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

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

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

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

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

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

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

  9. Die Kommunikation zwischen Clients und Servern ist anfällig für Man-in-the-Middle (MITM) -Angriffe. Unterwegs werden Passwörter erfasst.

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

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

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

  13. Das Gleiche, aber ändern Sie den clientseitigen Code, um dies zu tun. Könnte so einfach sein wie ein gespeicherter XSS -Hack.

  14. Eine Variation der oben genannten: Keylogger .

  15. ol>

    Es gibt wahrscheinlich noch einige weitere Methoden, aber das gibt Ihnen eine Vorstellung davon, wie einfach es sein kann, Tonnen von Passwörtern wiederherzustellen.

Nummer 7 ist für mich einfach genial
Dies ist bei weitem die vollständigste und genaueste Antwort.
Tipping44
2019-03-17 02:21:20 UTC
view on stackexchange narkive permalink

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

Nur um zu beachten, dass Sie mit einem schwachen Passwort wie "Sicherheit" nicht einmal ein Cracking-Tool benötigen, sondern nur Google 2FAE32629D4EF4FC6341F1751B405E45
Und das umso mehr, als dieser Artikel indiziert ist!
Nur als Hinweis: Während MD5 gegenüber neueren Algorithmen wie SHA2 oder SHA3 überhaupt nicht bevorzugt werden sollte, sind diese für das Hashing von Passwörtern fast genauso schlecht, nur weil sie zu schnell sind.Verwenden Sie stattdessen einen iterierten Hash wie PBKDF2, bcrypt oder scrypt mit geeigneten Sicherheitsparametern.
Steve
2019-03-19 21:33:33 UTC
view on stackexchange narkive permalink

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.

Sevron
2019-03-17 15:55:13 UTC
view on stackexchange narkive permalink

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.

supercat
2019-03-19 01:31:28 UTC
view on stackexchange narkive permalink

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.

Ich bin mir nicht sicher, unter welchen Umständen eine solche zweite Entität einer ersten Entität erlaubt, sich als eine signifikante Gruppe von Benutzern auszugeben, und dieser ersten Entität keinen geeigneten Authentifizierungsmechanismus zur Verfügung stellt.In vielen Fällen verstößt ein Benutzer, der einer solchen ersten Entität sein Kennwort für den Zugriff auf die zweite Entität zur Verfügung stellt, gegen die Nutzungsbedingungen der zweiten Entität.Gibt es ein konkretes Beispiel für eine solche erste Entität / zweite Entität?
@Steve: Ich habe über Dinge wie automatisierte Tools nachgedacht, um beispielsweise Nachrichten zu bestimmten Zeiten zu posten, nach Nachrichten auf einem Dienst zu suchen und Benachrichtigungen (und / oder den Nachrichteninhalt) an einen anderen weiterzuleiten usw. Ein Dienst unterstützt eine Form von Proxy-AnmeldeinformationenDies könnte besser mit dem automatisierten Dienst geteilt werden, ohne dass die primären Anmeldeinformationen geteilt werden müssten. Dies würde jedoch die Zusammenarbeit des Anbieters des primären Dienstes erfordern.Eine andere verwandte Situation wäre mit Einrichtungen, die Passwörter zwischen Diensten synchronisieren müssen, die sie unterschiedlich speichern.
Wenn Unternehmen X ein System Y erbt / erwirbt, an das alle X-Benutzer automatisch mit ihren aktuellen Anmeldeinformationen empfangen sollen, der Authentifizierungsmechanismus von Y die Kennwörter jedoch anders hascht und X sie nicht ändern kann, wie sollte X Konten auf Y erstellen, ohne über Ys Kennwörter zu verfügenirgendwo gespeichert?Wenn X sichere Hardwarespeichermodule verwendet, die Benutzerkennwörter nicht entschlüsseln können, ohne mindestens fünf von acht privaten Schlüsseln zu haben, von denen jeder nur an einer Stelle im Universum vorhanden ist, und die Inhaber dieser Schlüssel alle Aktionen überwachen, die ausgeführt werdenfertig mit ihnen, ...
... dann kann es möglich sein, die Sicherheit über Passwörter aufrechtzuerhalten, obwohl die Datenbank unter den richtigen Umständen entschlüsselt werden könnte.Beachten Sie, dass ich einige Situationen gesehen habe, in denen Unternehmen eine unangemessene Offenlegung von Anmeldeinformationen benötigen, z. B. ein Satellitennetzwerk, bei dem Benutzer Anmeldeinformationen von Satellitenanbietern angeben müssen, um auf Streaming-Inhalte zugreifen zu können (vermutlich, damit das Netzwerk die Kontotools des Kunden verwenden kann, um zu bestätigen, dass dieDer Kunde ist tatsächlich abonniert, aber es gibt keinen Grund, warum der Satellitenanbieter dies erforderlich machen sollte!).


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 4.0-Lizenz, unter der er vertrieben wird.
Loading...