Passwort-Stärke ermitteln (Code und Prüflogik)

[Satty67]

@Hagen:

also...

Deine Funktion basiert auf bekannten (und soweit möglich) belegbaren Methoden ein sicheres Passwort zu ermitteln. Das wird soweit auch korrekt und fehlerfrei umgesetzt. Meine Einwände und daraus resultierende Funktion basiert zum Teil auf Gefühl und ist daher nicht belegbar besser, im Zweifel eher schlechter.

Ich denke soweit kann man das stehen lassen (ich hätte zumindest kein Problem damit) ?

***

Man kann mein Problem also etwas umformulieren:

Ich benötige eine Funktion, die dem Anwender das Gefühl gibt, das Sie korrekt arbeitet. Ich gehe also bei gewissen Punkten einen Kompromiss ein, weil ich ein seltsames (aber möglicherweise korrektes) Verhalten nur schwer vermitteln kann (man sieht ja am Thread, wie schwer das ist).

Der Kompromiss den ich eigehe, darf dabei natürlich nicht so groß sein, das die Empfehlung ein Risiko oder völlig falsch wird. Ich denke, auch wenn Zweifel angebracht sind, ist mein Kompromiss unter der Voraussetzung vertretbar?

@Reinhard:

Es bleibt ja letztlich jedem selbst überlassen, welche Funktion man verwendet. Es liegt wohl an der Komplexität der Sache, das hier unterschiedliche Meinungen herrschen. Ich denke die kann man auch so stehen lassen. Ich kann mich gut Deinen Argumenten anschließen, die liegen ja näher an meiner Meinung. Kann aber Hagens Argumentation genauso stehen lassen, auch wenn (nur) mein Gefühl etwas anderes sagt.

[xZise]

Reinhard, ich glaube du hast Hagen nicht verstanden: Er sagt halt, dass man mithilfe von Zufall (und Länge sowie was kommt drin vor) gut abschätzen kann, wie sicher ein Passwort ist.

Nun führst du ein Beispiel an, welches durch eine Wörterbuchattacke geknackt werden kann, aber er sagt eindeutig, dass dies der Algorithmus nicht löst. Dann kannst du davon nicht erwarten, dass er 123456 schlechter bewertet als 128462, da er nicht weiß, dass es ein Eintrag in der Wörterbuchattacke ist.

Diesen speziellen Fall könnte man noch lösen indem man die Differenz zwischen zwei Ziffern vergleicht, aber dann ist die frage ist 172839 sicherer?

Und das Zufall nicht die Stärke des Passworts bestimmt ist doch ein bisschen unlogisch. Ich meine jeder sagt möglichst zufällig und keine Wörter und viele verschiedene Zeichen(gruppen). Da kann man alles außer "keine Wörter" gut bestimmen, und willst dann ein Kriterium raus schmeißen? Dein Algorithmus würde also sagen das Pappel genauso gut ist wie Papepl? (Ich hoffe in diesem Beispiel habe ich die Definition von Entropie richtig interpretiert). Unabhängig davon, dass Pappel ein Wort ist.

MfG
Fabian

[Satty67]

Man darf auch meinen Eingangsvorwurf nicht vergessen... ich hatte ja behauptet, das Hagens Funktion nicht in jeder Beziehung korrekt arbeitet. Hier hat er richtig gestellt, das seine Funktion entsprechend den Anforderungen korrekt arbeitet.

Letzlich geht es inzwischen eher um die Frage, wie ein sicheres Passwort aussehen muss.

Zufällig mit größ möglicher Entropie? Möglichst lang? Möglichst breiter Zeichensatz? Kein bekanntes Word irgendeiner Sprache? Von allem etwas?