Die vorgeschlagenen Einschränkungen sind schädlich. Diese Einschränkungen sind übertrieben. Sie sind schlecht für die Benutzerfreundlichkeit. Daher denke ich, dass sie die Sicherheit der Benutzer mehr beeinträchtigen als helfen.

Benutzerfreundlichkeit ist der Punkt, an dem sie sich befindet. Meiner Meinung nach ist dies derzeit der wichtigste Einflussfaktor Kennwortsicherheit ist Benutzerfreundlichkeit: Inwieweit Benutzer den Mechanismus auf sichere Weise verwenden. In erster Näherung sollte alles, was Sie tun sollten, darauf abzielen, die Benutzerfreundlichkeit zu erhöhen und die Wahrscheinlichkeit zu erhöhen, dass sich Benutzer sicher verhalten. Jedes Mal, wenn Sie eine Entwurfsentscheidung treffen, sollten Sie sich fragen: Welche Option führt eher dazu, dass sich Benutzer sicher verhalten?

Ich würde erwarten, dass die komplexen Einschränkungen, die Sie formuliert haben, insgesamt schädlich für die Benutzer sind Sicherheit des Benutzers. Ich denke, sie werden die Sicherheit mehr verringern als erhöhen. Hier sind meine Argumente:

• Frustration. Ein Risiko besteht darin, dass Benutzer frustriert oder verärgert werden, aufgeben und zu einem anderen OpenID-Anbieter wechseln weniger sicher verwaltet als SO - oder bleiben Sie einfach bei der aktuellen SO, anstatt den OpenID-Anbieter von SO zu übernehmen. Dies ist ein Nettoverlust für die Sicherheit des Benutzers.

• Das Speichern ist schwierig. Wenn Sie eindeutige Einschränkungen haben, die für den OpenID-Anbieter von SO spezifisch sind, Dies bedeutet, dass der Benutzer ein eindeutiges Passwort für Ihre Site auswählen muss. Das mag positiv klingen, könnte aber auch negativ sein. Wenn der Benutzer bereits ein Geheimnis mit hoher Entropie hat, kann er dieses wahrscheinlich nicht verwenden, da es wahrscheinlich nicht den Einschränkungen von SO entspricht. Ich vermute, dass diese Tatsache die Wahrscheinlichkeit erhöht, dass der Benutzer gezwungen ist, sein SO-Passwort irgendwo aufzuschreiben, anstatt es sich zu merken.

• Automatisierte Passwortgeneratoren. Menschen sind im Allgemeinen schlecht darin, nicht erratene Passwörter auszuwählen. Um dies zu beheben, verwenden einige Leute Tools, um ihr Passwort für sie zu generieren. Einige haben sogar befürwortet, dass diese Tools stärker in den Browser aller integriert und weit verbreitet sein sollten. Derzeit besteht das größte Hindernis für die Verwendung der automatisierten Kennwortgenerierung bei Websites, die ihre eigenen speziellen Einschränkungen für das Kennwort auswählen. Aufgrund der von Ihnen vorgeschlagenen Einschränkungen wird es für Benutzer daher schwierig, automatisierte Kennwortgeneratoren zu verwenden. Das ist schlecht; Sie möchten Benutzer dazu ermutigen, automatisierte Kennwortgeneratoren zu verwenden, da automatisch generierte Kennwörter sicherer sind. Und Sie möchten keine Barrieren für integrierte Passwortgeneratoren schaffen.

Was sollten Sie also tun? Ich habe zwei allgemeine Ratschläge:

• Beginnen Sie mit einem Bedrohungsmodell. Machen Sie sich nicht nur Einschränkungen und Sicherheitsschemata aus, die gut klingen . Denken Sie stattdessen zunächst über das Bedrohungsmodell nach. Was sind Ihrer Meinung nach die wahrscheinlichsten Möglichkeiten, dass die Sicherheit versagt? Wenn Sie dann eine neue Idee entwickeln, anstatt sie sofort umzusetzen, weil sie sich gut anhört, analysieren Sie, wie sie sich auf jeden dieser wahrscheinlichen Fehlermodi auswirkt. Reduziert es insgesamt die Wahrscheinlichkeit der wahrscheinlichsten Fehlermodi erheblich? So wie es keinen Sinn macht, das stärkste Glied in einer Kette zu stärken, macht es oft wenig Sinn, sich gegen eine Bedrohung abzusichern, die eigentlich nicht sehr wahrscheinlich ist.

  Ich stelle fest, dass die Frage einen Sicherheitsmechanismus beschreibt, dies aber nicht Beschreiben Sie das Bedrohungsmodell und es enthält keine Analyse. Es gibt nicht genau an, welchen Angriff es besiegen soll. Im Bereich des Sicherheitsdesigns ist dies ein "schlechter Geruch", der häufig darauf hinweist, dass möglicherweise mehr Gedanken angebracht sind.

  Ein Beispiel für diese Art der Analyse finden Sie unter diese Analyse. In dem Artikel wird argumentiert, dass etwa 20 Bit Entropie für Webkennwörter ausreichen, solange die Kennwortüberprüfungssoftware angemessen aufgebaut ist, und dass Kennwörter mit höherer Entropie nur einen geringen Nutzen haben. Siehe das Papier für die detaillierte Analyse. In der Schlussfolgerung des Papiers heißt es: "Wir kommen zu dem Schluss, dass es falsch erscheint, Benutzer zur Auswahl sicherer Passwörter zu zwingen." In diesem Dokument erfahren Sie, warum.

• Kosten-Nutzen-Analyse. Es ist wichtig, die Kosten und den Nutzen des Mechanismus zu bewerten und sicherzustellen, dass die Kosten werden durch den Nutzen gerechtfertigt. In diesem Fall sind die Kosten Benutzer Ärger. Die Sicherheitsvorteile dieser Einschränkungen im Vergleich zu einigen weniger strengen Einschränkungen sind unklar und wahrscheinlich geringfügig.

  Ich empfehle Ihnen, Cormac Herleys wirtschaftliche Analyse der Passwortsicherheit zu lesen. Er weist darauf hin, dass der Rat, den Sicherheitsexperten Benutzern zu Passwörtern geben, irrational ist: Die Kosten für Benutzer, diesen Rat zu befolgen (z. B. ihre Zeit, die beim Auswählen, Speichern, Verwalten und Eingeben komplexer Passwörter verschwendet wird), übersteigen wahrscheinlich die Vorteile (bei reduzierten Sicherheitsverletzungen) mit großem Abstand. Er argumentiert, dass jede Einschränkung, die mehr als ein paar Minuten der Zeit des Benutzers pro Jahr in Anspruch nimmt, mit ziemlicher Sicherheit einen Nettoverlust darstellt, und in der Praxis vermute ich, dass sie wahrscheinlich mindestens eine Größenordnung niedriger sein muss als Das. Jemand fragte nach Daten; er hat es.

  In einem ähnlichen Zusammenhang hat Cormac Herley auch eine Studie zu den Kennwortrichtlinien auf 75 verschiedenen Websites durchgeführt. Er fand eine breite Palette von Einschränkungen. Er stellte außerdem fest, dass der Grad der Restriktivität nicht mit der Sicherheitsempfindlichkeit der Website korreliert, und schlägt vor, dass "die Websites mit den restriktivsten Kennwortrichtlinien keine größeren Sicherheitsbedenken haben, sondern lediglich besser gegen die Folgen einer schlechten Benutzerfreundlichkeit isoliert sind. "" Dies sollte einen zweimal über den Vorschlag nachdenken lassen, dass strengere Kennwortbeschränkungen besser sind.

Wenn Sie nach konkreteren Schritten suchen, können Sie Ihre Benutzer schützen und die Anzahl erhöhen Hier sind einige Ideen, die Sie berücksichtigen könnten:

• Fügen Sie eine Kennwortstärkeleiste ein. Auf dem Formular, auf dem der Benutzer sein muss Wählen Sie ein Passwort aus und fügen Sie etwas Javascript hinzu, um eine dynamisch aktualisierte Leiste bereitzustellen, die anzeigt, wie stark das Passwort des Benutzers ist. Sie können Rot, Gelb, Grün für unsicher, grenzwertig und gut verwenden.

• Fügen Sie einen vorgenerierten Kennwortvorschlag hinzu. Auf dem Formular, auf dem die Benutzer muss ein Passwort auswählen, Sie können zufällig ein Passwort für sie generieren und vorschlagen, dass sie es verwenden. Vielleicht werden einige es verwenden!

• Helfen Sie Benutzern, beliebte Passwörter zu vermeiden. Ein aktuelles Forschungspapier schlägt eine interessante Idee vor: Sie schlagen vor, dass Benutzer in der Lage sein sollten, ein beliebiges Passwort zu wählen, solange nicht zu viele andere Benutzer es zuvor ausgewählt haben. Anschließend wird beschrieben, wie diese Richtlinie durchgesetzt wird, ohne dass Kennwörter im Klartext auf dem Server gespeichert werden.

• Verwenden Sie sichere, dauerhafte Cookies für die Benutzerauthentifizierung. Wenn Sie die Häufigkeit verringern, mit der Benutzer Kennwörter eingeben müssen, sind Benutzer möglicherweise eher bereit, selbst komplexe Kennwörter auszuwählen Übereinstimmung, und vielleicht werden Benutzer weniger wahrscheinlich von Phishing-Angriffen getäuscht. Ich schlage vor, dass Ihre Site ein sicheres, dauerhaftes Cookie im Browser des Benutzers setzt, wenn sich der Benutzer zum ersten Mal anmeldet. Wenn Sie dieses Cookie bei zukünftigen Besuchen erkennen, behandeln Sie den Benutzer sofort als authentifiziert und leiten Sie es ohne Benutzerinteraktion an sein endgültiges Ziel weiter erforderlich, damit Benutzer angemeldet sind, ohne ihr Kennwort eingeben zu müssen.

• Konzentrieren Sie sich mehr auf den Schritt zur Kennwortüberprüfung. Warum sollen Benutzer dies tun? Wählen Sie in erster Linie Passwörter mit hoher Entropie? Über welche Angriffe sind wir besorgt? Eine Art von Angriff ist ein gezielter Angriff, bei dem der Angreifer einen bestimmten Benutzernamen im Sinn hat und in das Konto dieses Benutzers eindringen möchte. Eine andere Art von Angriff ist ein breiter Angriff, bei dem der Angreifer eine Menge Benutzernamen hat und einen finden möchte, einen beliebigen, dessen Passwort er erraten kann. Was ist die größte Bedrohung für den SO OpenID-Anbieter? Ich vermute, dass Sie sich am meisten um gezielte Angriffe sorgen sollten, da ich vermute, dass ein Angreifer eher motiviert ist, in einen Moderator oder hochrangigen Benutzer einzudringen, als ein durchschnittlicher Benutzer.

  • Stoppen gezielter Angriffe. Es gibt effektive Möglichkeiten, gezielte Angriffe auf die Passphrase eines einzelnen Benutzers zu verhindern. Eine sehr einfache Möglichkeit besteht darin, zu zählen, wie viele falsche Passwörter am letzten Tag oder so eingegeben wurden. Wenn diese Anzahl einen bestimmten Schwellenwert überschreitet, wechseln Sie in den Modus "Oh Scheiße, ich werde möglicherweise angegriffen". In diesem Modus können Sie vom Benutzer die Eingabe eines CAPTCHA zusammen mit jedem Kennwort verlangen oder nach jedem Versuch eine Verzögerung hinzufügen oder Anmeldeversuche mit Ratenbegrenzung durchführen oder den Benutzer zwingen, eine Proof-of-Work-Herausforderung zu lösen (z. B. dem Benutzer Javascript-Code bereitstellen und ihn zwingen, 20 Sekunden zu berechnen, bevor Sie die nächste Kennwortschätzung akzeptieren) oder eine Teilmenge davon. Es gibt viele mögliche Schemata.

  • Stoppen breiter Angriffe. Wenn Sie sich gegen breit angelegte Angriffe verteidigen möchten, z. B. wenn der Angreifer versucht, ein Kennwort zu erraten Für jedes von Zehntausenden von Konten benötigen Sie unterschiedliche Verteidigungen. Es gibt aber auch Pläne, um dieses Problem zu lösen. Eine mögliche Gegenmaßnahme besteht darin, die Gesamtrate falscher Passwörter zu verfolgen und in den Modus "Ich werde möglicherweise angegriffen" zu wechseln, wenn diese Rate anfängt, hoch zu werden.

  eine reichhaltige Literatur zur Verteidigung gegen solche Angriffe. Insgesamt denke ich, dass es für Angreifer besser ist, es schwieriger zu machen, Angriffe zum Erraten von Passwörtern durchzuführen (z. B. sie langsamer laufen zu lassen), als den Benutzerkennwörtern zusätzliche Einschränkungen aufzuerlegen. Ich denke, da gibt es mehr für den Geldbeutel.

In der Frage wird ausdrücklich auf die Anforderung einer "engen Integration mit Websites von Drittanbietern" hingewiesen. Alle Argumente darüber, wie unwichtig SE-Konten sind, stehen außer Frage.

Beachten Sie auch, dass niemand jemanden zwingt, diesen bestimmten OpenID-Dienst zu verwenden. Es gibt viele zur Auswahl. Eine Differenzierung auf der Grundlage einer guten Sicherheit scheint eine gute Idee für einen Authentifizierungsdienst zu sein.

Falsche Passwörter sind ein großes Problem auf der Welt. Benutzer können das gleiche Passwort möglicherweise an anderer Stelle wiederverwenden. Die Aufklärung der Benutzer über das Erstellen eines guten Passworts ist ein sehr wertvoller Dienst für das Internet. Die Kosten für den Benutzer, ein gutes Passwort zu verwenden, sind gering, insbesondere angesichts der Bequemlichkeit guter und sicherer Agenten (in Browsern oder anderswo), sich diese zu merken.

Websites mit wertvollen Informationen wie Passwörtern sollten kompromittiert werden und planen Sie, wie Sie den Schaden minimieren können. Selbst mit einem guten Hashing-Algorithmus wie bcrypt können Passwörter mit geringer Entropie brutal erzwungen werden. Gute Passwörter bleiben also eine gute Idee.

Welche Richtlinie ist die beste? Wir haben alle Meinungen, aber es gibt tatsächlich Daten da draußen. Ein interessantes neues Papier ist Wiederverwendbare Sicherheit: Neues Papier zu Kennzahlen zur Passwortsicherheit. (Update :) Es wird darauf hingewiesen, wie wichtig es ist, die vorgeschlagenen Passwörter mit einer schwarzen Liste gängiger Passwörter zu vergleichen (einschließlich Zeilen mit Tastaturtasten). Es schwebt auch die Idee einer interessanten neuen Funktion zum Zurückweisen von Passwörtern vor, die auch Änderungen des vorgeschlagenen Passworts vorschlägt, die das vom Benutzer gewählte Grundmuster verwenden, das Passwort jedoch ungewöhnlicher und damit schwerer zu knacken machen:

[zuerst] bewerten Sie die Wahrscheinlichkeit eines vom Menschen generierten Passworts, indem Sie es mit einer Grammatik analysieren, die auf zuvor offenbarten Passwortlisten trainiert wurde. Auf diese Weise können wir im Vergleich zu einer einfachen Blacklist eine robustere Ablehnungsfunktion erstellen und gleichzeitig versuchen, bei der Auswahl ihrer Kennwörter angesichts der Sicherheitsbeschränkungen des Systems die größtmögliche Benutzerfreiheit zu gewährleisten.

Auf der Grundlage des oben Gesagten scheint die vorgeschlagene Richtlinie sicherlich die Art von Unterscheidungsmerkmal für die Sicherheit zu sein, nach der ich als Drittanbieter-Site suchen würde, die an der Einführung des Stack Exchange OpenID-Anbieters interessiert ist, wenn ich das Risiko von Kennwörtern verringern möchte geknackt.

(Update :) Wenn Sie jedoch Benutzer für Ihren OpenID-Dienst gewinnen möchten, ist ein Schema, das sie weniger frustriert (wie D.W. beschreibt), möglicherweise eine bessere Geschäftsentscheidung. Letztendlich sind Ihre Ziele wahrscheinlich vielfältig und die Kompromisse komplex.

Komplexe Kennwörter werden häufig von der IT-Abteilung eines Unternehmens erzwungen, um sicherzustellen, dass die Benutzerkonten der Mitarbeiter nicht extern gefährdet werden. Sie werden auch in Situationen erzwungen, in denen einem Benutzer vertraut wird, dass er Zugriff hat, der in den falschen Händen schädlich sein kann.

In diesem Fall gilt keine der beiden Situationen. Stack Exchange speichert keine privaten Daten und reguläre Benutzerkonten können keinen Schaden anrichten. Der einzige Fall, in dem diese Kennwortanforderungen sinnvoll sein könnten, besteht darin, dass die Stack Exchange-Systeme kompromittiert wurden, alle Kennwort-Hashes offengelegt wurden, leicht geknackt werden konnten und Benutzer die Kennwörter an anderer Stelle verwendeten. Kein anderes Szenario ist sinnvoll - Stack Exchange kann Brute-Force-Angriffe drosseln. Wenn das Anmeldesystem beeinträchtigt ist, ist die Kennwortstärke nutzlos. und selbst wenn das Kennwort des Benutzers kompromittiert wird, ist der Schaden, den es bei Stack Exchange anrichten kann, ziemlich begrenzt. In allen Fällen wird Stack Exchange also nicht von der Stärke der Kennwörter ihrer Benutzer beeinflusst.

Auf der anderen Seite werden die starken Kennwortanforderungen wahrscheinlich dazu führen, dass viele Benutzer die Nutzung des Dienstes vermeiden und dabei bleiben ihre Google- oder Facebook-Konten, die beide weitaus weniger Einschränkungen hinsichtlich des Passworts haben.

Dies ist eine Frage des Grades - wie sicher können Sie Menschen dazu zwingen, zu sein, bevor sie entweder Ihren Dienst meiden oder Ihre Versuche, sie zu "sichern", sabotieren. Zum Beispiel kann jemand ein Passwort haben, das er verwenden möchte, aber es kann nicht 8 eindeutige Zeichen haben, also verwenden sie stattdessen "Pas $ word". Oder sie erfinden ein Passwort, wissen aber, dass sie sich nicht daran erinnern, und schreiben es an einer Stelle auf, an der jeder in ihrer Nähe es sehen kann.

Um eine Perspektive zu bieten, werden hier die Passwortbeschränkungen untersucht Die anderen OpenID-Anbieter, die auf den Stack Exchange-Anmeldeseiten prominent vorgestellt werden, haben:

• Google: Mindestens 8 Zeichen, darf auch kein "schwaches" Passwort sein, obwohl der genaue Mechanismus, mit dem ein "schwaches Passwort" ermittelt wird, unklar ist. ("abcdefgh" und "abcdefg1" sind schwach, während "Abcdefgh" ausreichend stark ist). Sie bieten eine Seite mit Tipps für ein stärkeres Passwort.

• Yahoo: mindestens 6 Zeichen. Es gibt eine ähnliche Grafik wie bei Google, die zeigt, wie stark Ihr Passwort ist, aber nichts verhindert die Erstellung eines Kontos mit einem schwachen Passwort.

• MyOpenID: Mindestens 1 Zeichen, keine weiteren Einschränkungen. Ähnlich wie bei Yahoo gibt es eine Grafik, die zeigt, wie stark das Passwort ist ( Quellcode), aber nichts verhindert die Erstellung eines Kontos mit einem schwachen (oder sogar 1 Zeichen) Passwort.

• AOL: Mindestens 6 Zeichen, darf auch nicht "zu unsicher" sein. Es gibt ein Kennwortstärkemessgerät ( Quellcode), und es scheint, dass jedes Kennwort, dessen Punktzahl unter 34 liegt, als "zu unsicher" eingestuft wird.

• Facebook: mindestens 6 Zeichen.

Im Vergleich dazu sind die Einschränkungen für das Stack Exchange OpenID-Kennwort weitaus strenger. Unnötig, meiner Meinung nach, da der größte reine OpenID-Anbieter, MyOpenID, überhaupt keine Passwortbeschränkungen hat.

Es hängt alles vom Kontext ab

Mein Baseline-Rat lautet:

Machen Sie es wie Google stark>

Wenn sie die OpenId-Sicherheit von Google gefährden können, werden sie sich wahrscheinlich nicht um Sie kümmern. Alles, was sicherer als dieses ist, muss durch ein sehr starkes Mehrwertversprechen abgesichert werden. :

• Wir möchten sicherer sein als Google, weil ____________________
• Für unsere Nutzer ist es wertvoller, einen weniger bequemen Service als Google zu haben, da wir ______________________ als Mehrwert

anbieten Zweitens kann ich diese realen Daten anbieten:

10% der Benutzer verwenden denselben Benutzernamen und dasselbe Passwort , gemessen an einigen von mir erstellten Websites, mit 50.000 bis 500.000 Benutzer.

ZB Benutzername Foobar123 und Passwort Foobar123 .

Im Allgemeinen ist es nur dann sinnvoll, das Passwort sicherer zu machen, wenn Sie den Authentifizierungsmechanismus korrekt implementieren:

• Der Benutzername ist nicht geheim, aber Sie geben nicht bekannt, ob er in Ihrem System vorhanden ist.
• Das Passwort ist stark genug.
• Die beiden Informationen sind völlig unabhängig:
  • anders
  • Nie zusammen gespeichert oder gesendet ( Sie werden es lieben - auch an anderen Standorten, an denen sie möglicherweise verwendet werden).

Die 8 eindeutigen Zeichen sind etwas übertrieben. Nur überprüft und es gibt weniger als 1500 Wörter in englischen Wörterbüchern mit 8 oder mehr Buchstaben, die alle eindeutig sind, also was Sie sind Außerdem werden keine Wörter aus dem Wörterbuch akzeptiert. Nicht, dass dies eine schlechte Idee wäre, aber Sie könnten einfach sagen, dass "Wörterbuchwörter nicht erlaubt sind".

Dies wird natürlich die Benutzer frustrieren und viele von ihnen dazu bringen, erkennbare Tastaturmuster , wie jeder Buchstabe in einer Reihe. Diese Muster sind in den Wörterbüchern jedes guten Crackers enthalten.

Bearbeiten: Ich konnte mir nicht helfen, musste dies hier posten: http://popstrip.com/password-validation/ :-)

Ich liebe es, wie wir diese Debatte noch im Jahr 2011 führen. Ich frage mich, ob wir in weiteren 10 Jahren noch über die am besten geeignete Passwortrichtlinie diskutieren werden.

Ich stimme @ Kyle-Cronin zu, dass dies richtig ist Um dies zu erreichen, müssen Sie das Risiko untersuchen:

• Was ist der Wert? Für Standardbenutzer ist nur das Stack Exchange (SE) -Konto von geringem Wert. mäßiger Wert. Es ist kein Wegwerfabonnement, Reputation und Online-Profil sind wichtig, aber weniger als E-Mail, soziale Netzwerke, Online-Banking, Zahlungssysteme. Moderatoren könnten etwas mehr Wert haben, aber immer noch nicht hoch. @Iszi wirft eine interessante Frage auf, ob als Federated Identity-Anbieter die Verantwortung oder Sorgfaltspflicht besteht, mehr Sicherheit zu bieten, als die ursprüngliche Site garantiert, nur weil sie von wertvolleren Sites verwendet werden könnte. Sie können sich darauf verlassen, dass der Benutzer ein stärkeres Kennwort festlegt, wenn er SE Open-ID auf wertvolleren Websites verwendet. Dies ist jedoch möglicherweise nicht der Fall. Alternativ können Sie das Maximum für den Fall festlegen, dass die ID beispielsweise für das Internet-Banking verwendet wird. Wahrscheinlich würden diese Websites den Kontext berücksichtigen, in dem SE verwendet wird, und es ist unwahrscheinlich, dass sie SE Open-ID anbieten, daher können sie rabattiert werden. Die wahrscheinlichsten Sites, die die SE Open-ID verwenden, sind soziale Netzwerke und Start-up-Sites, die eine Vielzahl von Verbundanmeldungen unterstützen und die verschiedenen SE-Communities als Kunden ansprechen möchten.

• Bedrohungen und Motivationen? Die Hauptbedrohungen für SE-Konten sind wahrscheinlich Spammer. Sie sind motiviert, verwenden jedoch einen Dragnet-Ansatz, um die größtmögliche Abdeckung mit dem geringsten Widerstand zu erreichen. Potenziell verärgerte oder böswillige Benutzer, die Berechtigungen an Moderatoren weitergeben, andere Benutzer in den Papierkorb werfen usw. möchten, haben jedoch wahrscheinlich keine sehr hohe Motivation, grundlegende Kennwortkontrollen zu untergraben. Soziale Netzwerke und andere Start-ups, die SE Open-ID verwenden, werden zumindest zu Beginn wahrscheinlich nicht mit hochmotivierten Angreifern konfrontiert sein. Wenn sie später ein höheres Risiko wahrnehmen, würden sie wahrscheinlich ihre Unterstützung für SE Open-ID überdenken oder zusätzliche Kontrollen hinzufügen, z. Adaptive Authentifizierungs- oder Betrugsüberwachungssysteme.

• Sicherheitslücken? Die Hauptangriffe, gegen die eine Kennwortrichtlinie verteidigt, sind das brutale Erzwingen oder Erraten eines Kennworts. Bei einem exponentiellen Back-Off oder einer kurzen Kontosperrung kann sogar ein 6-stelliges Passwort einen angemessenen Schwierigkeitsgrad für Brute-Force oder Vermutungen bieten. Insbesondere gegen die Art der Bedrohungen und Motivationsniveaus, die wir erwarten. Größere und komplexere Passwörter würden sich wirklich nur gegen jemanden verteidigen, der die vollständige oder teilweise Datenbank mit Passwörtern erhält. Unter der Annahme einer vernünftigen Multi-Round-Hash- und Seed-Methode mit bcrypt usw. sowie einer vernünftigen Infrastrukturkontrolle ist die Wahrscheinlichkeit für die SE-Bedrohungen so gering, dass sich der Kompromiss zwischen Benutzerfreundlichkeit

• Risikoübersicht: Insgesamt ist das Risiko für einen Standardbenutzer gering, wenn ein grundlegender Satz von Kennwortrichtlinien festgelegt wird. Moderatoren sind einem etwas höheren Risiko ausgesetzt, und Benutzer, die die SE Open-ID für vertraulichere Websites verwenden, sind dem höchsten Risiko von allen ausgesetzt.

Daher empfehle ich einen segmentierten Satz von Kennwortkontrollen Um das beste Gleichgewicht zwischen Risiko und Benutzerfreundlichkeit zu erzielen:

Standardbenutzer:

• Mindestlänge 6 Zeichen. Obwohl MyOpenID 1 Zeichen bietet, sind die meisten Benutzer jetzt an ein Kennwort mit etwa 6 Zeichen gewöhnt. Dies sollte nicht viele Benutzer davon abhalten, der Site beizutreten und sie zu nutzen, und unvergesslich genug sein. Wie bereits erwähnt, wird dies von Facebook und Yahoo verwendet.
• Zeigt die einfache Kennwortstärkeanzeige an, die während der Eingabe aktualisiert wurde, aber keine weiteren Anforderungen erfüllt. Es ist auch eine gute Idee, einen Benutzer zu ermutigen, hier auf der Benutzeroberfläche einen Kennwort-Tresor zu verwenden, um das Kennwort zu generieren >

  Moderatoren (zusätzlich):

  • Muss 3 enthalten: Kleinbuchstaben, Großbuchstaben, Zahlen, Sonderzeichen
  • Darf kein Feld für ein öffentliches Konto enthalten.
  • Mindestkennwortlänge 8 Zeichen

  Wenn ein Benutzer Moderator wird, kann er aufgefordert werden, sein Kennwort mit den neuen Anforderungen zu ändern.

  Authentifizierung für andere Sites (zusätzlich):

  Jeder Benutzer, der die SE zur Authentifizierung bei x anderen Sites verwendet (x kann konfigurierbar sein 3), ist wahrscheinlich eine gute Nummer wenn sich das Risiko erhöht, um eine ausreichende Sicherheit zu gewährleisten). Da ich nicht der Meinung bin, dass es eine gute Möglichkeit gibt, das Risiko der Websites zu beurteilen, für die SE Open-ID verwendet wird, ohne eine manuelle Liste zu führen und das Risikoprofil des Benutzers zu kennen, ist eine grundlegende Anzahl verknüpfter Websites ausreichend. Dies sollte auch für höhersensible SE-Websites wie careers.stackoverflow.com gelten, da hier personenbezogene Daten gespeichert werden.

  • Bieten Sie eine Zwei-Faktor-Option an, z. SMS pünktlich Passwort, Soft Token wie Google Authenticator. Nicht sicher, ob dies von SE kostengünstig entwickelt und unterstützt werden kann.

  Wenn ein Benutzer zusätzliche Websites verknüpft, kann er aufgefordert werden, sein Kennwort mit den neuen Anforderungen zu ändern.

  8 Einzigartige Charaktere sind ein Albtraum für die Benutzerfreundlichkeit und das Anbieten von zwei Faktoren wäre eine viel bessere Option für diese Risikostufe. Das Ablaufen des Passworts ist eher schädlich als vorteilhaft, daher bin ich froh, dass dies nicht vorgeschlagen wurde.

Sie sollten Folgendes hinzufügen:

• Keine Kennwörter sollten ihre Benutzernamen sein (das ist nur dumm, passiert aber).

• Keine tatsächlichen Wörter oder zumindest eine Wortkombination, die nicht in Wörterbüchern enthalten ist (ich habe von einer Website über Cyberspace-Probleme erfahren, und eines davon befasste sich mit Problemen. Es heißt, dass Hacker manchmal mit Computern angreifen und hacken, die Wörter finden und dann vorhersagen können Ihr Passwort ist so).

• Passwörter sollten auch komplex, eindeutig, aber leicht zu merken sein, wie ein Satz, bei dem sich der Anfang jedes Buchstabens irgendwie ändert.

• Sie können nicht zulassen, dass Personen ihren Anmeldevorgang beenden, es sei denn, sie geben mindestens einige Zahlen und einen Großbuchstaben mit einigen anderen Dingen wie H3110 !: |.

• Sie können auch einen Checker hinzufügen, um zu sehen, wie sie die Stärke ihres Passworts sehen.

• Versuchen Sie, das 2. und 3. Passwort mit ihrer Telefonnummer und anderen persönlichen Dingen wie dem Daumen hinzuzufügen drucken (dies ist von Google inspiriert) so auf die Hacker müssen buchstäblich "ihr Opfer" sein, um vorbei zu kommen.

• Versuchen Sie, ihre Informationen mit einem anderen Passwort zu verschlüsseln, das nur die Person kennt, falls ein Hacker jemals erfolgreich gehackt wurde Daher können sie dieses Passwort auch nicht so einfach durchgehen.

• Ich weiß, dass es schwierig sein wird, dieses Passwort hinzuzufügen, aber vielleicht fügen Sie einen kleinen Begleiter auf Ihrer Website / Ihrem Ort hinzu / Was auch immer das ihre Persönlichkeit kennt, wenn es eine Veränderung sieht, würde es wahrscheinlich vermuten, dass es ein Hacker wäre, wenn die Person dies nicht zuerst sagte. Ein bisschen wie eine Persönlichkeitssoftware für jeden Benutzer (schließlich ist jeder anders).

• Benachrichtigen Sie sie auch, wenn jemand anderes als der, den sie kennen, auf ihr Konto wechselt. Wenn sie sagen, dass sie nicht wissen, wer diese Person ist, ist es wahrscheinlich ein Hacker (Google tut dies).

• Für Phishing-Mails / Dinge / was auch immer versuchen Sie, sie zuerst zu scannen, bevor Sie sie sehen lassen (testen Sie, ob es sicher ist), fragen Sie sie danach, und wenn sie nein sagen, zerstören Sie es, um zu verhindern, dass sie betrogen werden der Hacker.