Yeah, I agree that aspect of it seemed quite problematic to me as well from the beginning. And he obviously cannot include the email in the hash. So it’s better to just disallow the top x most common passwords, which we already have. (Though it’s not updated on the fly as the list changes over time.)
2 „Gefällt mir“
What would really solve the issue here, in my humble opinion, would just to apply best practices like preventing an IP to try to login more than X times without success, don’t let people try passwords at non human time ( humans don’t try a password every 1 sec ) would fix the security issue without forbidding all the passwords.
The way I see is, someone can make a list that gives all the combinations of A-Z 1-9 up to X length. This means nothing if you can’t brute force the target, unless it’s a targed attack and then there’s not much you can do.
Is anything like that currently implemented?
Yes, there is extensive rate limiting across the whole of Discourse. By default login attempts are limited to 6 per minute and 30 per hour (per IP).
9 „Gefällt mir“
Hmm, can you extrapolate here though? It would seem to me that the distribution of lengths might be quite different if you focus on the 1 mil most common ones since those will obviously tend to be shorter.
1 „Gefällt mir“
I think it’s a good idea to alert the user but maybe not prevent them from using the password if they insist. Explain it better, maybe something along the lines of
“The encrypted version of this password has been found in a public database of stolen user information and may put your account at increased risk of being hacked by brute force attacks. If you use this password across multiple web services we strongly recommend changing them to unique passwords to stay secure, especially for mail accounts.”
And let them hit submit a second time to use it anyway.
hopefully webauthn will make passwords a thing of the past someday 
2 „Gefällt mir“
Das ergibt für mich keinen Sinn (daher das Aufwärmen des Threads): Sobald bekannt ist, dass ein Passwort geknackt wurde (oder im Klartext gefunden wurde), ist es deutlich weniger sicher. Selbst unter sehr großzügigen Annahmen stellt dies eine massive Verringerung der Entropie dar:
- ein zufälliges 10-stelliges Passwort, selbst mit einem sehr begrenzten Zeichensatz (Beispiel: nur Kleinbuchstaben: Pr = 1/26^10 = 1/1,4e14)
- ein Passwort, von dem bekannt ist, dass es in der HIBP-Liste enthalten ist (Pr = 1/5e8)
Sobald jemand anderes es verwendet hat und es zudem kompromittiert und/oder entschlüsselt wurde – das ist der entscheidende Unterschied.
Was ist das praktische Problem daran, ein Passwort zu verhindern, das nur in einer Liste aufgetaucht ist? Als Nutzer möchte ich definitiv davon wissen, um dieses Passwort nicht erneut zu verwenden. Als Seitenadministrator möchte ich nicht, dass meine Nutzer kompromittierte Passwörter verwenden. Dies scheint den Abstrich bei der Benutzerfreundlichkeit mehr als wert zu sein.
Nein, das ist kein entscheidender Unterschied, da statistisch gesehen alle Passwörter im Laufe der Zeit kompromittiert werden.
Denken Sie daran: Wir blockieren bereits seit Jahren die eine Million häufigsten Passwörter, sodass Sie in den wirklich wichtigen Aspekten bereits geschützt sind.
3 „Gefällt mir“
Statistisch gesehen werden auch alle kryptografischen und Hashing-Algorithmen im Laufe der Zeit gebrochen. Sobald der erste Hinweis darauf erscheint, dass ein Algorithmus kurz vor dem Bruch steht, setzen wir ihn außer Kraft.
Warum sollten Passwörter anders sein? Alle Sicherheit ist eine Wette darauf, dass die verwendete Entropie für die jeweilige Aufgabe ausreicht, und dabei wird stets angenommen, wie lang oder intensiv ein Angriff sein kann, dem man standhalten kann.
Angesichts dessen, dass man beim ersten Auftauchen eines Passworts in einer Liste mindestens 6 Größenordnungen an Entropie verliert (in der Realität wahrscheinlich noch mehrere mehr), scheint dies eine einfache Entscheidung zu sein.
Ja, dies ist eine deutlich bessere Situation als bei vielen anderen heute verfügbaren Softwarepaketen. HIBP stellt dennoch eine weitere Verbesserung für Websites dar, die darüber hinaus mehr Sicherheit gewährleisten möchten.
Das klingt nach einer Möglichkeit, über ein Plugin einen Button „Passphrase generieren
Warum wird das Passwort auf dem Server generiert?
Angenommen, der Benutzer muss es speichern, wäre es dann nicht sinnvoller, die Verantwortung für die Passwortgenerierung beim Benutzer zu belassen? Der von ihm gewählte Passwortmanager führt dies wahrscheinlich bereits durch.
2 „Gefällt mir“
Weil es besser sein könnte, ihnen ständig zu sagen, dass „apple“, „apple1“, „apple 123“, „apple 12345“ unter der 1m-Verbotsliste nicht akzeptabel sind. Ich persönlich würde diese Funktion bei Discourse nicht unbedingt erwarten, aber wenn es das Thema der kompromittierten Passwörter einigermaßen elegant abschließt und die Entscheidung, falls etwas schiefgeht, in den Händen des Nutzers lässt, könnte es sich lohnen, es zu prüfen.
Und Sie schlagen vor, dass clientseitige Passwort-Manager Passwörter wie diese generieren?
Ihren Nutzern zu empfehlen, einen Passwort-Manager zu verwenden, ist weitaus effektiver, als ihnen ein Passwort von einer einzigen Seite vorzuschreiben. Letzteres führt nur dazu, dass sie dieses Passwort überall anders verwenden und seine Kompromittierung beschleunigen.
Stupides zu reparieren ist schwieriger als das zu reparieren, was kompromittiert wurde. Sich an etwas wie https://www.useapassphrase.com/ zu halten, wirft denen, die sich nicht für die akademischen Aspekte interessieren, einen Knochen zu, meiner Meinung nach.
Ich habe Systeme entwickelt, die von zig Millionen Menschen genutzt werden, und wir haben verschiedene Ansätze im Zusammenhang mit Passwörtern erprobt, darunter diese furchtbaren Anforderungen, dass sie x und y enthalten müssen.
Wenn Sie Benutzer nicht im Umgang mit Passwörtern schulen, erhöhen Sie nur die Wahrscheinlichkeit von Passwortmüdigkeit, Wiederverwendung und dem gefürchteten „Klebezettel unter der Tastatur".
Das Generieren von Passwörtern auf dem Server schafft zudem eine neue Angriffsfläche, die gesichert werden muss. Persönlich könnte ich auf ALLES davon verzichten.
3 „Gefällt mir“
Ich hätte gedacht, dass JS zufällig eine Passphrase clientseitig generiert, diese dann hash und mit einer Liste vergleicht. Der Bildungsteil könnte ein Stub über „Erstelle mir ein Passwort
Ich denke, deine beste Option wäre dann, ein Plugin zu entwickeln oder in Auftrag zu geben, das genau das macht, was du vorschlägst.
1 „Gefällt mir“
Das ist genau der Zweck dieses Plugins.
Ich habe dies seit der Entwicklung dieses Plugins einige Zeit überdacht und stimme Jeff nun zu.
„Kompromittiert
4 „Gefällt mir“
[quote=“featheredtoast, Beitrag: 37, Thema: 90074”]
Jeffs Argumentation lautet, dass dies bedeutet, dass schließlich alle Zeichenketten „unsicher
1 „Gefällt mir“