Frage:
Warum werden Brute-Force-Angriffe zum Knacken von Passwörtern nicht automatisch erkannt und vereitelt?
kjo
2014-06-26 18:31:16 UTC
view on stackexchange narkive permalink

Warum erkennt Software Angriffe zum Knacken von Passwörtern nicht automatisch und vereitelt sie?

Lange Version:

Angenommen, jemand versucht, Brute-Force-Passwörter zu knacken Angriff auf ein Programm XYZ, für das eine Kennwortauthentifizierung erforderlich ist.

Nach meinem Verständnis würde ein solcher Angriff darin bestehen, die Menge "aller möglichen Kennwörter" zu durchlaufen und jeweils nacheinander an XYZ zu senden, bis eines davon funktioniert . Damit diese Strategie eine Erfolgswahrscheinlichkeit hat, muss der Angreifer in der Lage sein, XYZ sehr viele Kandidatenpasswörter pro Sekunde zu liefern. Daher wäre es trivial, XYZ so zu programmieren, dass dieses Muster erkannt wird (dh es unterscheidet sich von dem Fall, in dem ein legitimer Benutzer das richtige Kennwort einige Male falsch eingibt) und die Authentifizierungsanforderung automatisch für die nächsten beispielsweise 10 Minuten zu eskalieren.

Die Idee ist, dass der Eigentümer von XYZ zwei "Passwörter" festlegen darf: ein "Level 1-Passwort" (AKA "das pass Wort i > ") das ist relativ leicht zu merken und leicht zu tippen, aber auch relativ leicht mit brutaler Gewalt zu knacken, und ein" Level 2 Passwort "(AKA" die Pass Phrase i> "), das extrem sein könnte lang, unmöglich mit brutaler Gewalt zu knacken, aber auch sehr unpraktisch für den (legitimen) täglichen Gebrauch.

Jemand, der das bequeme, aber schwache Passwort kannte i>, würde es kaum jemals brauchen Verwenden Sie die nicht knackbare, aber unbequeme Pass-Phrase i>.

Ich bin sicher, dass dieses Schema einen großen Fehler aufweist, da sonst Passwörter den legitimen Benutzern nicht die Kopfschmerzen bereiten würden, die es ist. Was ist die Erklärung?

Es gibt kein Passwort, das "mit brutaler Gewalt nicht zu knacken ist". Es wird möglicherweise sehr, sehr lange dauern, aber eines Tages wird das Passwort geknackt. Übrigens ist Ihr Satz "aller möglichen Passwörter" (theoretisch) unendlich.
http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ Passphrasen sind immer noch anfällig für Wörterbuchangriffe, sodass Sie nicht zu faul mit ihnen werden können .
Die Frage ist etwas zu allgemein gehalten, sodass Sie verschiedene Antworten haben. Beziehen Sie sich auf Internet-Server, LAN-Server oder lokale Software?
Mögliches Duplikat dieser [Frage] (http://security.stackexchange.com/questions/47103/cant-brute-force-password-cracking-somehow-be-throttled).
@wumm Es ist nichts Falsches daran, über eine unendliche Menge zu iterieren :) Da kein Passwort selbst eine unendliche Anzahl von Zeichen hat, werden Sie es irgendwann wiederholen
@wumm: Ist Ihnen klar, wie unlesbar Beiträge werden, wenn sie versuchen, Streitigkeiten wie Ihre zu antizipieren und zu vertuschen?
Nein, ich wusste nicht, dass das Schreiben von "fast unmöglich" und "jede Kombination ausprobieren" unleserlicher sein würde. Es tut mir leid für Sie, dass Sie eine gut gemeinte Notiz nicht verstehen können.
Denken Sie neben allem anderen daran, dass ein Bösewicht, der über ein Bot-Netzwerk verfügt, den Versuch über mehrere Bots ausführen kann, sodass keine einzelne IP-Adresse zu viele fehlgeschlagene Versuche auslöst.
Fünf antworten:
AJ Henderson
2014-06-26 18:44:50 UTC
view on stackexchange narkive permalink

Ziemlich oft. Jedes vernünftige System sperrt Sie aus, wenn Sie zu viele Online-Angriffe (oder legitime falsche Versuche) ausführen, um auf das Konto zuzugreifen.

Das Problem tritt bei Offline-Angriffen auf. Der Server (oder was auch immer Sie authentifizieren) muss etwas haben, mit dem Sie das Passwort vergleichen können. Dies ist normalerweise entweder ein verschlüsselter Wert, der mit dem Kennwort entschlüsselt werden kann, oder ein Hash. Wenn dieser Wert gefährdet ist, z. B. wenn ein Angreifer Zugriff auf die Benutzerdatenbank erhält, kann er versuchen, den Hash oder die Entschlüsselung auf seinem eigenen Computer auszuführen und alle Zählungen zu umgehen, wie oft versucht wurde. Sie können auch versuchen, Größenordnungen schneller zu erraten, da sie lokal arbeiten und nicht auf ein Netzwerk warten müssen.

Bei einem Offline-Angriff können Tausende, wenn nicht Millionen von Angriffen pro Sekunde versucht werden und es wird plötzlich trivial, einfache Passwörter innerhalb von Minuten, wenn nicht Sekunden, anzugreifen. Es gibt keine Möglichkeit, den Angriff zu verhindern, da wir keine Kontrolle über das System haben, mit dem das Kennwort überprüft wird. Aus diesem Grund ist es wichtig, dass Sie Ihr Kennwort ändern, nachdem ein DB-Kompromiss entdeckt wurde.

Naja .... nicht "meistens". Vernünftige Systeme, klar - aber das ist nicht "am meisten" ... ;-)
@AviD - fairer Punkt, ist "vernünftigerweise oft" mit der Realität angenehmer?
Dies erfordert, dass der Cracker wissen muss, wann ein Kandidatenkennwort das richtige ist, * ohne * es XYZ zu übermitteln. Der einzige Weg, den ich finden kann, ist, dass beim Finden des richtigen "Schlüssels" (was auch immer es ist) eine verschlüsselte Datei in etwas "menschlich lesbares" / "erkennbares" (z. B. Wörterbuchwörter, persönliche Namen usw.) dekodiert werden kann. In diesem Fall würde der Angriff vereitelt, wenn die "decodierte" Datei nur Zeichenfolgen enthält, die nicht "erkennbarer" sind als die in der codierten Version. Natürlich sind "zufällig aussehende" Passwörter nicht praktikabel. Ich möchte nur sicherstellen, dass ich Ihre Antwort vollständig verstehe.
@kjo - Der dekodierte Wert muss etwas sein, das die Anwendung auch als gültig erkennen kann, wenn es alles ist, was sie tun muss. Wenn es nicht erkennbar ist, kann der Anmeldevorgang auch nicht richtig von falsch unterscheiden. Der Angreifer kann denselben Ansatz verwenden.
@kjo: Nun, wenn Sie perfekt zufälliges Rauschen sicher speichern möchten, das Sie niemals für irgendetwas verwenden, ist dies möglicherweise ein praktikabler Ansatz. Wenn der Angreifer das falsche Passwort angibt, bekommt er das falsche Geräusch und hat keine Ahnung. Es ist unzerbrechlich - aber es zu brechen ist wertlos. Sie können es nicht einmal verwenden, um verschlüsselte Daten (die zufällig aussehen) oder Rauschen zu sichern, das Sie tatsächlich verwendet haben oder das Sie für etwas verwenden möchten (z. B. als einmaliges Pad), da der Angreifer dann eine Möglichkeit hat, falsch von zu unterscheiden richtig.
@kjo Sehen Sie sich [diesen alten Kryptogrammartikel] (https://www.schneier.com/crypto-gram-9812.html#plaintext) an, wie Brute-Force-Angriffe Erfolg erkennen.
@kjo Der Angreifer muss lediglich replizieren, was der Anwendungsserver tut, um festzustellen, ob ein Kandidatenkennwort gültig ist. Dieser Prozess muss offensichtlich möglich sein und darf nicht davon abhängen, dass die Ausgabe "erkennbar" ist. In der Regel sind die Schritte 1) Erstellen eines Kandidatenkennworts 2) Anhängen der entsprechenden Salt (s) 3) Hashing der resultierenden Zeichenfolge 4) Überprüfen der Hash-Ausgabe anhand des DB 5) Wiederholen, bis sie übereinstimmt.
@AaronDufour: danke, dass die Frage in meinem Kommentar beantwortet. Ich nehme an, dass eine Möglichkeit, diese Form des Angriffs zu vereiteln, darin besteht, dass die Anwendung einen Vorgang ausführt, den der Angreifer nicht auf einem anderen Computer replizieren kann (z. B. kann sich die Anwendung auf einen in die Hardware eingebauten maschinenspezifischen Schlüssel stützen).
@kjo, das nur emuliert werden kann, wenn der Schlüssel geschützt ist. Dies ist die Idee hinter einem hsm, aber solche Dinge sind nicht billig oder einfach zu handhaben.
Damon
2014-06-26 20:25:58 UTC
view on stackexchange narkive permalink

Bei "Online-Angriffen" tun sie dies in unterschiedlichem Umfang und mit unterschiedlichem Erfolg. Normalerweise ist es nur ein Ärger für den legitimen Benutzer und keine große Abschreckung für Kriminelle.
Für Offline-Angriffe ist dies unmöglich. Wenn jemand über Ihre Passwortdatenbank verfügt, können Sie ihn nicht daran hindern, etwas damit zu tun (obwohl Sie ihn etwas verzögern können).

Mobiltelefone funktionieren genau so, wie Sie es tun beschreiben. Nachdem Sie Ihre PIN falsch über einen bestimmten Schwellenwert eingegeben haben (z. B. 3 Versuche), benötigen Sie die PUK, um das Gerät zu entsperren. Wenn mir das jemals passiert, bin ich sehr sauer, da ich das Stück Papier weggeworfen habe, auf dem diese 10-stellige Nummer vermerkt ist.

Mein AVM-Router sperrt Sie für 5 Sekunden und verdoppelt sich die Zeitdauer bei jedem fehlgeschlagenen Login. Nach 10 fehlgeschlagenen Versuchen müssen Sie also 42 Minuten warten, bevor Sie es erneut versuchen können.

Ein solches Schema ist jedoch nur mäßig intelligent. Es ist zwar unwahrscheinlich, dass Sie 10 Mal hintereinander einen Tippfehler haben, aber es ist durchaus möglich, dass Sie sich nicht erinnern können, welches der 10 Passwörter (Passwörter, die Sie selten an verschiedenen Orten verwenden, oder unter Passwörtern, die Sie haben) im Laufe der Zeit geändert) ist die richtige. Außerdem ermöglicht es einen Denial-of-Service-Angriff mit vergleichsweise wenig Arbeit.
Natürlich muss auch der Angreifer zwischen den Anmeldeversuchen warten, aber er wartet nur 21 Minuten, während Sie 42 Minuten (oder 6 Minuten) warten müssen Stunden, während Sie warten 12). Wenn jemand nur böswillig ist und das Warten nicht schadet, können Sie jederzeit einen Wecker auf 6 Stunden stellen und sich abends erneut falsch anmelden. Für den legitimen Benutzer ist es ein vollständiger Tag des Wartens, wenn dies funktioniert (und was noch wichtiger ist, das Warten tut weh, wenn Sie tatsächlich etwas tun müssen).
Andere Systeme, die ich auf einigen Websites gesehen habe, sind noch weniger intelligent. In einem Fall musste ich vor einigen Jahren mein Passwort ändern, um mein Konto zu entsperren, weil sich jemand falsch angemeldet hatte. Das ist natürlich totaler Unsinn, da das Passwort nachweislich nicht kompromittiert wurde (da diese Anmeldeversuche erfolglos waren). Diese "Sicherheitsmaßnahme" war für den Kunden nur ein sehr großer Ärger ohne Nutzen.

Zur Verteidigung der Implementierer ist es überhaupt nicht einfach (wenn möglich), etwas zu finden, das viel funktioniert besser.

sixtyfootersdude
2014-06-26 21:15:15 UTC
view on stackexchange narkive permalink

Es gibt ein anderes Szenario, das schwer zu erkennen wäre.

Schauen wir uns zunächst Szenarien an, gegen die man sich leicht verteidigen kann.

Einfach: Verteidigung gegen Brute-Force-Angriffe auf a Einzelbenutzer.

Brute-Force-Angriffe sind auch leicht zu verteidigen, wenn ein Einzelbenutzer das Ziel des Angriffs ist. Wir können einfach das Konto dieses Benutzers sperren. Dies kann den Benutzer stören, ermöglicht es uns jedoch zu verhindern, dass das System kompromittiert wird.

  • Anmelden bei UserJoe
  • Anmelden bei UserJoe
  • Anmelden bei UserJoe
  • Anmelden bei UserJoe
  • Anmelden bei UserJoe
  • Sperren des UserJoe-Kontos

Einfach : Verteidigung gegen Brute-Force-Angriffe von einer einzelnen IP-Adresse

Brute-Force-Angriffe, die leicht zu erkennen und zu verteidigen sind, wenn alle Anforderungen von derselben IP-Adresse stammen.

Wir können Sperren Sie einfach, dass diese IP-Adresse weitere Anforderungen stellt.

  • SomeIPAddress1 versucht sich anzumelden
  • SomeIPAddress1 versucht sich anzumelden
  • SomeIPAddress1 versucht sich anzumelden
  • SomeIPAddress1 versucht sich anzumelden
  • Verhindert, dass SomeIPAddress1 versucht, sich später anzumelden

Unmöglich (?): Verteidigung gegen einen Botnet-Brute- Erzwingen eines neuen Benutzers bei jedem Versuch.

Angenommen, jemand, der ein Botnetz verwendet, versucht, Ihr System brutal zu erzwingen. Sie haben unterschiedliche IP-Adressen, sodass Sie Anmeldungen nicht nach IP-Adresse filtern können.

Nehmen wir als Nächstes an, dass sie versuchen, sich bei jedem Versuch bei einem anderen Benutzer anzumelden.

Die Anforderungen könnten dies also tun So sieht es aus:

  • SomeIPAddress1 versucht sich bei UserJoe anzumelden
  • SomeIPAddress2 versucht sich bei UserAnne anzumelden
  • SomeIPAddress3 versucht sich bei UserMarc anzumelden
  • SomeIPAddress4 versucht, sich bei UserHanah anzumelden
  • ...

Ich kann mir keine Möglichkeit vorstellen, legitime Anmeldungen von gefälschten Anmeldungen zu unterscheiden.

Ist es in der Botnet-Situation nicht möglich, die Anmeldeseite / den Handler so weit zu ändern, dass sich vorhandene Bots nicht authentifizieren können, ohne neuen Code vom "Master" zu erhalten, oder, noch besser, ein Captcha zu benötigen?
@hexafraction Ich denke, dass alle Änderungen, die Sie am Login vornehmen können, auch an den Bots vorgenommen werden können. Dies kann Ihnen einige Zeit kosten, ist aber kein wirklich zuverlässiger Sicherheitsmechanismus. Guter Punkt auf dem Captcha.
Sogar Captcha ist nicht die Barriere, die es zu sein scheint. Stellen Sie eine wünschenswerte Ressource im Internet bereit und stellen Sie sie hinter ein Captcha. Anstatt ein neues Captcha zu generieren, holen Sie sich bei jedem Laden einer Seite einfach eine Captcha-Herausforderung von der Site, die Sie knacken möchten. Wenn Ihr eigener menschlicher Besucher Ihnen die Antwort gibt, verwenden Sie sie auf der ursprünglichen Website. Die Ressourcen können Spiel-ROMs, MP3-Audiodateien, Pornografie oder andere herunterladbare Inhalte sein, die die Leute wünschen. Mit einem Botnetz kompromittierter Maschinen könnte man sogar einmal pro Stunde zufällig ein Captcha auf dem Desktop ausführen. Captcha ist nicht die endgültige Antwort.
Ich mag die Captcha-Lösung nicht. Fügen Sie der Kontobestätigung möglicherweise eine Verzögerung hinzu. Erhöhen Sie die Verzögerung mit der Anzahl der fehlgeschlagenen Anmeldungen. Überprüfen Sie auch Ihre Benutzerkonten auf sehr einfache Passwörter. Sperren Sie diese Konten und senden Sie eine E-Mail mit Kennwortänderungen.
Wenn im Fall des Botnetzes so etwas wie fail2ban ausgeführt wird und jeder Bot nur zwei Versuche erhält, bevor er für eine Stunde gesperrt ist, stellen Sie immer noch eine anständige Verteidigung auf ...
@Shadur - Das sind wahrscheinlich zwei Versuche ** pro IP-Adresse ** pro Stunde, was immer noch viele Versuche sein könnte.
Aber immer noch ungefähr eine Größenordnung weniger Versuche als ohne fail2ban. Möglicherweise genug, um den Unterschied zu machen.
Beachten Sie, dass Sie solche Anmeldungen erkennen und für eine Weile blockieren können, wenn Sie viele fehlgeschlagene Anmeldeversuche erhalten, auch von vielen variablen IP-Adressen, die nicht gültig sind. Abhängig von der Art der Websites, die Sie haben, könnte dies sicherer sein, als die Tür offen zu lassen ...
Phil Perry
2014-06-26 21:02:21 UTC
view on stackexchange narkive permalink

Es wird immer ein Balanceakt sein, wie viel Zeit jemand nach einem falschen Anmeldeversuch warten muss. Es ist nicht unangemessen, die Wartezeit nach jedem Versuch weiter zu verlängern (und schließlich weitere Versuche bis zu einem Zurücksetzen zu sperren), dies muss jedoch an die IP-Adresse gebunden sein, auf die der Versuch eingeht, damit der legitime Benutzer dies nicht tut. t auch ausgesperrt werden (Opfer, weil jemand versucht, in sein Konto einzubrechen). Ein verteilter Angriff (von vielen IP-Adressen) kann das System jedoch so weit belasten, dass es nur noch zu einem einfachen DDoS-Angriff wird.

Wenn jemand entschlossen ist, eine ganze Reihe von Passwörtern auszuprobieren (nicht unbedingt jedes mögliche , nur die häufigsten / wahrscheinlichsten) und eine Herde zombifizierter Maschinen hat, um dies zu tun Entweder werden sie irgendwann Erfolg haben oder das System in die Knie zwingen. Vergessen Sie nicht, dass das Erzwingen einer Wartezeit (Ablehnen von Anmeldeanforderungen) oder das Verweigern einer IP-Adresse ebenfalls Ressourcen verbraucht. Und wenn Sie so viele Passwörter haben, dass Sie sich nicht erinnern können, welches Sie verwenden sollen, haben Sie ein Problem mit Ihrer Methodik, wenn Sie alle durchgehen müssen!

Eine Herausforderung für "Sicherheitsfragen" (im Grunde genommen ein alternatives Passwort) nach so vielen fehlgeschlagenen Versuchen ist das Senden eines Einmalkennworts (Zurücksetzen) an eine registrierte E-Mail-Adresse (ob automatisch oder "Passwort vergessen" -Anforderung) möglich, ebenso wie eine Sperrung dieser IP-Adresse für eine bestimmte Zeit oder bis ein Administrator aufgefordert wird, es zu entsperren. Ich habe alle diese Methoden gesehen.

Wenn der Angreifer Insiderinformationen hat, nämlich die gehashte oder verschlüsselte Kennwortdatei, kann er den größten Teil seiner Arbeit offline erledigen und sich nur einmal anmelden (nachdem er das zu verwendende Kennwort herausgefunden hat). Passwörter sollten immer als Hashes (Einwegverschlüsselungen) und niemals im Klartext oder sogar in reversibler verschlüsselter Form gespeichert werden. Hashes sind schwierig (aber nicht unmöglich), um das Nur-Text-Passwort wiederherzustellen, insbesondere wenn sie gesalzen sind (so dass der Hash für zwei verschiedene Benutzer, die zufällig "geheim" für ihr Passwort gewählt haben, nicht gleich ist). P. >

PiTheNumber
2014-06-26 19:18:57 UTC
view on stackexchange narkive permalink

Weil der Kunde nicht für die Sicherheit bezahlt.

Sie müssen eine Datenbanktabelle erstellen. Sammeln Sie IP-Adressen aus fehlgeschlagenen Anmeldungen. Bereinigen Sie diese Tabelle regelmäßig. Erstellen Sie eine weitere Tabelle mit blockierten IP-Adressen und bereinigen Sie diese ebenfalls. Sie sehen, es erfordert einige Anstrengungen, und Kunden zahlen nicht gerne nur für die Sicherheit extra.

Als Entwickler sollten Sie Frameworks verwenden, die sich um diese Probleme kümmern. Vielleicht möchten Sie auch einen Blick auf fail2ban werfen.

Ich glaube immer noch nicht, dass es eine Verteidigung gegen das Szenario gibt, das ich in meiner Antwort beschreibe: http://security.stackexchange.com/a/61936/874


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