Frage:
Warum gibt es Anforderungen an die Passwortstärke?
Bozho
2012-06-25 15:54:17 UTC
view on stackexchange narkive permalink

Die Kennwortstärke ist jetzt alles und zwingt Sie dazu, Kennwörter mit Ziffern, Sonderzeichen, Großbuchstaben und so weiter zu erstellen. Abgesehen davon, dass es sich um einen Alptraum für die Benutzerfreundlichkeit handelt (selbst ich als Entwickler hasse es, wenn für eine Website ein komplexes Kennwort erforderlich ist), was sind die tatsächlichen Vorteile sicherer Kennwörter (für die Website-Authentifizierung)? Hier sind die Voraussetzungen für ein System, das die Authentifizierung ordnungsgemäß verarbeitet:

  • Speichern von Passwörtern mit bcrypt (oder zumindest mit Salt + Hash) - es ist schwer bis unmöglich, das ursprüngliche Passwort zu finden, wenn ein Angreifer es erhält Die Datenbank
  • sperrt nachfolgende Kennwortversuche mit zunehmender Abklingzeit - keine Brute-Force über die Site
tatsächlich. Aber es sind 20 Jahre - es ist schwer, sich sofort zu ändern
Mögliches Duplikat von [Welche Best Practices sollten in einem PHP-Anmeldeskript verwendet werden?] (http://programmers.stackexchange.com/questions/73024/what-best-practices-should-be-employed-in-a-php- Login-Skript)
@Zavior ist mit den Leerzeichen stärker
Keine * direkte * Antwort, daher werde ich sie als Kommentar hinterlassen, aber "ein System, das die Authentifizierung ordnungsgemäß handhabt" speichert möglicherweise keine Passwörter * überhaupt *. Wenn Sie nicht das Risiko eingehen möchten, Passwörter (auch aus Versehen) preiszugeben, speichern Sie sie nicht. Verwenden Sie eine vertrauenswürdige oder Verbundauthentifizierung, wie dies bei StackExchange der Fall ist.
Was ich hasse ist, dass einige Websites denken, dass sie speziell genug sind, um meine speziellen Passwörter zu erhalten. Verdammt, ich mache kein anderes Passwort, um Ihre dummen Anforderungen zu erfüllen, die ich für eine Seite vergessen werde, die ich fast nie wieder besuchen werde.
"_wachsende Abklingzeit_" bis?
sagen wir bis zu einer halben Stunde
@muntoo Wenn Sie dasselbe Kennwort für mehrere Websites verwenden, kann der Eigentümer einer dieser Websites mit demselben Kennwort auf andere Websites zugreifen, die Sie verwenden
Die Kennwortkomplexität zwingt Benutzer dazu, dasselbe Kennwort zu verwenden, damit sie sich daran erinnern können.
"Jemand hat wiederholt versucht, sich in Ihr Konto einzuloggen. Bitte versuchen Sie es in einer halben Stunde erneut und hoffen Sie, dass sie nicht immer noch brutal gezwungen werden, wodurch es für eine weitere halbe Stunde gesperrt wird. Ich wünsche Ihnen einen schönen Tag!"
Eine verwandte Frage, die Ihre nicht beantwortet, Ihnen aber möglicherweise zusätzliche Einblicke gibt: [Sind Regeln zur Kennwortkomplexität kontraproduktiv?] (Http://security.stackexchange.com/q/32222/12).
Acht antworten:
#1
+28
Darhazer
2012-06-25 16:19:12 UTC
view on stackexchange narkive permalink

Weil, wie LinkedIn und andere aktuelle Passwortlecks zeigen, die häufigsten Passwörter für Websites immer noch "Passwort", "Gott", "123456" usw. sind. Sie können also mit einer wirklich kurzen Liste der häufigsten Passwörter Brute-Force-Aktionen durchführen . Sie können diese Kennwörter jedoch einfach sperren oder ein langes Kennwort anfordern - da mögliche Kombinationen exponentiell mit der Länge zunehmen und das Erfordernis eines langen Kennworts besser ist als das Erfordernis eines "starken" Kennworts, um Brute-Force zu verhindern. Aber zu viele Menschen folgen dem, was sie für eine bewährte Methode halten, ohne es in Frage zu stellen. Eine großartige Frage!

Vielen Dank. Das Hauptproblem bei kürzlich aufgetretenen Kennwortverletzungen ist das Speichern ohne Salz oder sogar im Klartext
Bozho: Selbst mit wirklich guter Krypto, Salz und allem ist es nicht gerade schwierig, "Passwort" oder "123" brutal zu erzwingen.
"_langes langes Passwort erforderlich - da mögliche Kombinationen exponentiell mit der Länge wachsen_" Sie meinen, dass es exponentiell länger dauert, "aaa", "aaaa", "aaaaaaa", "aaaaaaaaaaa" zu hacken ...?
@curiousguy: Tatsächlich dauert es (fast exponentiell) länger, diese brutal zu erzwingen. Selbst bei einem Zwischenfall zwischen einem Wörterbuch und einem Brute-Force-Angriff, wenn Sie wissen, dass die Länge minimal ist, gibt es viele Möglichkeiten, jedes kurze Kennwort in Ihrem Wörterbuch auf ein längeres zu erweitern. Sie können Zeichen wiederholen, am Ende / vorne hinzufügen usw. Der einzige Fall, in dem es keine Rolle spielt, ist, wenn Sie wissen, dass das Passwort nur "a" und nichts anderes enthält, aber das passiert nicht so oft.
@EgonGeerardyn "_Indeed dauert es (fast exponentiell) länger, diese brutal zu erzwingen._" Außer wenn dies nicht der Fall ist. Sie können "a", "b", ... "aa", "bb" ... "aaaaaaa" "bbbbbb" versuchen. Dies dauert linear. "_Der einzige Fall, in dem es keine Rolle spielt, ist, wenn Sie wissen, dass das Passwort nur ein und nichts anderes enthält_" Sie müssen nichts wissen, können Sie erraten und schnell überprüfen. Sie wissen nichts über das Passwort, aber Sie versuchen immer noch Wörterbuchwörter vor "cbzpftxuf".
@curiousguy: Das ist genau das Gleiche wie zu sagen, dass "tWz2jc7J4eJxdukeW! C $ 8 & a8GVE7 $ ex9cUv ^ yc! N" in konstanter / linearer Zeit brutal erzwungen werden kann (beginnen Sie damit und versuchen Sie dann den Rest). Das Wörterbuch funktioniert gut, da es starke Beweise dafür gibt, dass viele Menschen Wörterbuchwörter verwenden. Sie können die Exponentialzeit nur reduzieren, indem Sie Annahmen treffen, die in einigen Fällen funktionieren, aber da es viele Fälle gibt, z. Sequenzen "aaaaaa", "abcdef", "acegik", "123456", "112358", ... Es gibt zu viele Sequenzen, um sie zu versuchen, so dass Ihre beste Vermutung brutale Gewalt bleibt.
@EgonGeerardyn Sie wetten also, dass es ca. so viele Leute mit "aaaaaaaa" als Passwort (sagen Sie Passwort für etwas nicht so Wichtiges, f.ex Forum) wie mit "tWz2jc7J"?
@curiousguy: Meine erste Wette wäre in der Tat das. Aber wie es in einigen Listen der am häufigsten verwendeten Passwörter steht, muss ich sagen, dass ich falsch liege. Sie könnten also argumentieren, dass Sie Ihrem Wörterbuch eine solche Zeichenfolge hinzufügen. Auf der anderen Seite ist so etwas wie "bb" nicht in der [Liste] (http://dazzlepod.com/disclosure/) enthalten, die ich konsultiert habe, so dass die Nützlichkeit bereits eingeschränkt ist. Auf der anderen Seite könnte man argumentieren, dass Komplexitätsbeschränkungen die Häufigkeit des Auftretens von "aaaaa" begrenzen würden (dh eine gleichmäßigere Verteilung, bei der "aaa" wirklich genauso wahrscheinlich ist wie eine zufällige Zeichenfolge), bei der Brute Force die beste Wahl ist .
#2
+16
static_rtti
2012-06-25 16:25:43 UTC
view on stackexchange narkive permalink

Weil niemand entlassen wurde, weil er Anforderungen an die Kennwortstärke erstellt hat. Für den Administrator ist dies im Grunde ein risikoarmer Ansatz, obwohl diese Einschränkungen für den Benutzer sehr ärgerlich sind und so gut wie keine echte Sicherheit bieten.

@static_rtti - Nur das Zulassen eines Passworts mit einer bestimmten Länge und Komplexität bietet tatsächlich echte Sicherheit. Auf diese Weise kann der Administrator verhindern, dass Benutzer allgemeine Kennwörter verwenden.
@Ramhound "_Nur ein Passwort mit einer bestimmten Länge und Komplexität zulassen_" Was ist "Passwortkomplexität"?
Die Komplexität des Passworts bedeutet, dass das Passwort eine hohe [Entropie] aufweist (http://en.wikipedia.org/wiki/Entropy_%28information_theory%29). Grundsätzlich bedeutet dies, dass Ihr Passwort unwahrscheinlich sein sollte (ungewöhnlich oder nicht leicht zu erraten). Sie können die Kennwortentropie auf zwei Arten verbessern: entweder durch recht kurze Kennwörter mit vielen verschiedenen Zeichen oder durch sehr lange mit Wörtern.
#3
+9
user9818
2012-06-26 01:08:23 UTC
view on stackexchange narkive permalink

Hier sind einige relevante Illustrationen von xkcd! Was als stark angesehen wird, ist tatsächlich schwach, weil die Menschen menschlich sind und sich nicht anstrengen, und das andere ist Faulheit, selbst wenn sie ein "starkes" Passwort verwenden, wird es überall wiederverwendet. Sie können nicht gewinnen!

Passwortstärke

Password Strength

und

Wiederverwendung von Passwörtern

Password Reuse

#4
+8
Bill
2012-06-25 17:48:43 UTC
view on stackexchange narkive permalink

Wenn Sie kurze Passwörter ohne Stärkeanforderung zulassen, lassen Sie sich für jemanden offen, der die Benutzernamen im Regenbogenstil angreift. Zum Beispiel:

  admin, passwordfred, passwordbob, password ... machen Sie so lange, bis das Abklingzeitfenster abläuft ... admin, godfred, godbob, god ... wiederholen Sie nach Bedarf ...  

Viele Systeme werden dieses Muster nicht einmal als Problem kennzeichnen, und ich habe noch nie eines gesehen, das es wirklich auffängt, wenn Sie es über ein Botnetz ausführen und es entsprechend drosseln .

"_rainbow style attack_" was ist das?
Vielleicht mache ich einen schlechten Vergleich, aber ich meinte, wenn Sie eine Liste allgemeiner Benutzernamen hätten (wie die Liste der allgemeinen Passwörter einer Regenbogentabelle), würden Sie sie einfach durchlaufen und zufällige lahme Passwörter ausprobieren, sodass Sie sehr viele Kombinationen von Benutzernamen / versuchen könnten Passwort sehr schnell, ohne den Schwellenwert für den Passwortversuch auszulösen. Nicht meine Idee, und vielleicht gibt es einen besseren Namen dafür, aber es ist effektiv, wenn es richtig gemacht wird.
"_wie die Liste der gebräuchlichen Passwörter einer Regenbogentabelle_" Eine Regenbogentabelle ist keine "Liste der gebräuchlichen Passwörter" (und enthält sie nicht), sondern ein ** geschickt komprimierter Satz von Passwort-Hashes **. Der Begriff "Regenbogen" bezeichnet ** eine bestimmte Hash-Speichermethode ** und ist kein Synonym für "Wörterbuch" oder "Brute Force".
Richtig, wenn Ihre Organisation immer Vornamen verwendet oder immer Initialen gefolgt von sequentiell mit Nullen aufgefüllten Ints verwendet, identifiziert sie das Muster, um die schlechten Vermutungen zu reduzieren. Vielleicht ist es besser, es als intelligentes Wörterbuch zu bezeichnen, aber ich hatte immer gedacht, dass die Wörterbuchangriffe von Natur aus nicht klug sind. Ich habe gesehen, dass dies getan wurde, aber ich habe noch nie gesehen, dass es benannt wurde, also weiß ich wirklich nicht, wie ich es nennen soll.
#5
+3
user10846
2012-06-25 17:07:12 UTC
view on stackexchange narkive permalink

Es gibt verschiedene Arten von Angriffen, denen Kennwörter ausgesetzt sind, ebenso wie eine Reihe von Schutzmaßnahmen implementiert werden können.

Verschlüsselung und / oder Kennwortsperrung sind nur zwei von vielen Mögliche Abwehrmechanismen.
Kennwortstärke ist ein recht anständiger Artikel.

Um Ihre Frage, warum die Kombinationen erforderlich sind, spezifisch zu beantworten, ist dies das einzige verfügbare Mittel, um die Auswahl zu erzwingen eines starken Passworts. Ein starkes Passwort bedeutet wirklich eine hohe Entropie (Änderung) zwischen den Zeichen des Passworts. Je größer die Entropie ist, desto größer ist der Bereich der für die Verschlüsselung verfügbaren Bits (z. B. mit bcrypt). Ein (schwaches) Passwort mit niedriger Entropie nutzt nicht den gesamten für die Verschlüsselung verfügbaren Speicherplatz. Was Sie für eine 128-Bit- oder 256-Bit-Verschlüsselung hielten, ist viel weniger, da nicht der gesamte Bereich für Schlüssel verwendet wurde.

Einige Zahlen könnten helfen, die Dinge klarer zu erklären. Wir werden für das Beispiel ein 8-stelliges Passwort verwenden. Alle Kleinbuchstaben haben nur 26 verschiedene Kombinationen. Das sind also 26 ^ 8 oder 2.1x10 ^ 11 verschiedene Kombinationen.
Das Hinzufügen von Großbuchstaben verdoppelt unseren Platz (jetzt 52 nicht 26), kauft uns aber viel mehr Kombinationen. 52 ^ 8 oder 5,3x10 ^ 13, was einem Gewinn von ungefähr 250x entspricht.
Fügen Sie Zahlen oder Sonderzeichen hinzu, und Sie können leicht die Auswirkungen des Erzwingens von mehr Entropie im Tastenraum erkennen.

In Wirklichkeit haben wir immer noch nicht den vollen Schlüsselraum, da etwas, an das man sich im Allgemeinen erinnern kann, nicht viel Entropie hat. Die Anforderungen tragen jedoch dazu bei, mehr Entropie in das Kennwort zu bringen.

"_hohe Entropie (Veränderung) _" Umarmung?
#6
+2
Darknight
2012-06-25 16:50:59 UTC
view on stackexchange narkive permalink
  • Speichern von Passwörtern mit bcrypt (oder verwenden Sie zumindest salt + hash) - es ist schwer bis unmöglich, das ursprüngliche Passwort zu finden, wenn ein Angreifer die Datenbank erhält

Wenn sie Ihren Server kompromittiert haben, müssen Sie sich weitaus schlimmere Sorgen machen.

Eine Analogie:

Dieb bricht in Ihr Haus ein. Aber alle Ihre Schlüssel werden sicher aufbewahrt. Na und? Er ist in Ihrem Haus!

  • Sperren Sie nachfolgende Kennwortversuche mit zunehmender Abklingzeit - keine Brute-Force über die Website
/ blockquote>

Dies verlangsamt das Problem nur, wenn das Passwort schwach ist, zB "Passwort". Und das ist der erste Versuch, dann kehren Sie zum ersten Punkt zurück.

Ein sicheres Passwort zu haben, ist eine gute Idee (tm)

Nur dass der Dieb jetzt alle Schlüssel Ihrer Kunden hat und nicht nur Ihre.
-1: In beiden Fällen falsch. Eine vollständige Kompromittierung des Produktionsservers ist nicht die einzige Möglichkeit, eine Kopie der Datenbank zu erhalten, und "starke" Kennwörter können auch nur einen Brute-Force-Angriff verlangsamen.
@MichaelBorgwardt Ich denke, Sie haben den Punkt völlig verfehlt -> Was um alles in der Welt ist der Punkt, der sich um gehashte Schlüssel kümmert, WENN IHR Server kompromittiert wird?
@Darknight: Was ist, wenn der Angreifer nur eine Sicherungskopie der Datenbank von einem Speicherserver erhalten hat oder über ein schreibgeschütztes Konto darauf zugreifen kann? Und selbst wenn Ihr Server kompromittiert ist, werden Ihre Kunden es zu schätzen wissen, dass ihre Passwörter nicht kompromittiert wurden, die sie wahrscheinlich auch für verschiedene Konten verwendet haben. Sicherheit als Alles-oder-Nichts-Problem ist eine vereinfachte und veraltete Sichtweise.
Eine Analogie: Ein Dieb bricht in Ihr Haus ein. Aber der Schlüssel für Ihr Auto in der Garage, der Safe mit unschätzbaren Juwelen und die Häuser der Nachbarn sind sicher aufbewahrt, und das stille Alarmsystem hat bereits eine Sicherheitsfirma angerufen, die die Polizei nach Rücksprache mit Ihnen informiert hat. Die Offiziere werden in 5 Minuten eintreffen. Sehr viel effektiver, als sich nur auf das Schloss an der Haustür zu verlassen, nicht wahr?
@MichaelBorgwardt "_Was, wenn der Angreifer nur eine Sicherungskopie der Datenbank von einem Speicherserver erhalten hat, _" sollte dies niemals passieren. Ihre Backups sollten verschlüsselt sein. "_oder Zugriff darauf über ein schreibgeschütztes Konto? _" Was ist ein schreibgeschütztes Konto?
@curiousguy: Der realen Welt ist es egal, was passieren soll und was nicht. Es gibt keine perfekte Sicherheit, und so ziemlich jeder auf dem Gebiet hat akzeptiert, dass Sie Ebenen von Sicherheitsmaßnahmen benötigen: http://en.wikipedia.org/wiki/Defense_in_depth_%28computing%29. Mit schreibgeschütztem Konto meinte ich ein Konto (DB- oder Betriebssystembenutzer) mit eingeschränkten Zugriffsrechten. Es ist durchaus üblich, dass ein Angreifer zuerst Zugriff auf ein solches Konto erhält.
@MichaelBorgwardt Diese Sache sollte niemals passieren und wird niemals in einem einigermaßen sicheren Setup passieren. "_Und was denken Sie, tun starke Passwörter? _" Sie sind stark. Sie können sie nicht erraten. Das bedeutet "stark".
Starke Passwörter brauchen viel länger, um sie zu erraten. Abklingzeiten verlängern das Erraten schwacher Passwörter erheblich.
@MichaelBorgwardt "_Jedes Passwort kann erraten werden, _" "kann" wie in "kann mit einem theoretischen Computer sein, kann aber nicht in der realen Welt sein, bevor die Sonne die Erde übernimmt"?
Jungs - Ich habe gegebenenfalls gelöscht und bearbeitet. Wenn Sie ein Gespräch führen möchten, bringen Sie es zum Chat, aber halten Sie es höflich.
#7
+1
Peteris
2014-02-26 04:49:23 UTC
view on stackexchange narkive permalink

Ein Grund, der an anderer Stelle nicht erwähnt wird, ist möglicherweise, dass Sie ein größeres Interesse an der Sicherheit Ihres Benutzerkontos haben als die Benutzer selbst.

Wenn Sie beispielsweise ein völlig unkritisches System wie ein Online-Diskussionsforum verwenden, ist es den Benutzern möglicherweise überhaupt nicht wichtig, ob ihre Konten kompromittiert werden - wenn jedoch 5% Ihrer Benutzer Wenn Sie die Passwörter '123456' und 'Passwort' haben, haben Sie immer wieder Probleme mit Spammern, die kompromittierte Konten verwenden. Wenn Sie ein Schulnetzwerk betreiben, ist es einem erheblichen Teil der Benutzer möglicherweise nicht besonders wichtig, ob ihre Konten missbraucht werden. Die Missbraucher verursachen jedoch Probleme für Sie, wenn Sie versuchen, jedes Mal zuverlässig auf ein Dutzend Konten zuzugreifen

Für dieses Angriffsszenario (versuchen Sie es mit einem einfachen Kennwort für alle Kontonamen, die Sie finden können) benötigen Sie keinen Zugriff auf die Datenbank, und Sperren helfen nicht, solange genügend "frische" IP vorhanden ist Adressen sind verfügbar.

#8
  0
Stephen C
2012-06-25 17:42:33 UTC
view on stackexchange narkive permalink

Das Problem mit Ihren Lösungen ist:

  • Die Verwendung von Hash + Seed schützt nicht vor dem Erraten von Brute-Force-Passwörtern.

  • Lockout schützt bis zu einem gewissen Grad, hat jedoch das Problem, dass es als Denial-of-Service-Angriff gegen echte Benutzer verwendet werden kann, insbesondere wenn Sie eine zunehmende Lockout-Zeit verwenden. Ein intelligenter Angreifer kann auf mehrere Konten umsteigen, mehrere IP-Adressen verwenden und / oder eine Zeit zwischen den einzelnen Vermutungen warten.

Im Gegensatz dazu besteht er auf starken (schwerer zu erratenen) ) Passwörter bedeuten, dass der Angreifer (im Durchschnitt) mehr Vermutungen anstellen muss, um ein Konto zu knacken.

"_Lockout schützt bis zu einem gewissen Grad, hat jedoch das Problem, dass es als Denial-of-Service-Angriff gegen echte Benutzer verwendet werden kann_" Im Web können Sie einen kombinierten (moderaten) Delay + CAPTCHA-Ansatz verwenden. Es ist auch nicht perfekt, aber es sperrt keine Benutzer. "Im Gegensatz dazu bestehen sie auf starken (schwerer zu erratenden) Passwörtern." Eigentlich bestehen sie nicht auf starken Passwörtern, sondern auf dummen Regeln wie "Groß- und Kleinschreibung" und "mindestens einer Ziffer", die ein Passwort ergeben. * schwerer zu merken ** bei konstanter Entropie, IOW für konstanten Speicheraufwand ** diese Regeln machen Passwörter schwächer **


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