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

[BUG]

Hier gibt es einen Online-Passwortchecker von Microsoft in JavaScript.


EDIT:
Auf StackOverFlow gibt es auch Anregungen.

U.A. dort für interessant befunden:

• John the Ripper passwdqc
• CrackLib (Anleitung)

algorithm password strength findet auch eine ganz Menge Bibliotheken. Viele scheinen einen heuristischen Ansatz zu verfolgen.

[cookie22]

Zitat:

Hier gibt es einen Online-Passwortchecker von Microsoft in JavaScript.

der bestimmt aber nur die passwortlänge, sonst nichts.

[Satty67]

Zitat von BUG:

Auf StackOverFlow gibt es auch Anregungen.

Ja, da hab' ich mich für den mittleren Prüfteil insperieren lassen:

Zitat:

* At least one uppercase and one lowercase letter
* At least one number
* At least one special character

wobei ich das in der Schleife im Case-Block prüfe.

Dezeit wird ja geprüft:

• Eventuell ein Datum? -> auf Zahlen reduzieren (da nur Zahlen sowieso ein schlechtes Ergebnis bringen)
• Wiederholdende Zeichen? -> nur das erste bewerten (da das scheinbar kein großen Vorteil bringt)
• Mindestens je ein Groß/KleinBuchstabe, Zahl, Sonderzeichen vorhanden?
• Anzahl unterschiedlicher Zeichen im Passwort (Entropie)
• Länge des Passwortes

Punkt 1/2 passen nur das zu prüfende Passwort (intern) an, also schneiden Punkte bzw. Zeichenwiederholungen aus.

Punkt 3 vergibt pro Zeichengruppe einen Multiplikator-Anteil, der später aufaddiert wird. Sind aber nur Groß/Klein-Buchstaben vorhanden, dann wird abgewertet.

Punkt 4 ergibt je nach Anzahl unterschiedlicher Zeichen zu Länge einen Multiplikator

Punkt 5 Bewertet die Länge expentionel, allerdings etwas abgemildert durch die Log2 Funktion

Am Ende steht ein Entropie-Wert (aus Punkt 3/4) und ein Längen-Wert (aus Punkt 4), die miteinander multipliziert das Ergebnis bilden.

Grundsätzlich sind alle in Tutorials vorgeschlagenen Prüfmethoden drin. Ebenso kann man durch etwas probieren, die Anteile der einzelnen Methoden am Gesamtergebnis verschieben. Wer also auf Entropie einen riesen Wert legt, kann das mit "DiffCharsMaxMulti = 100" machen. Was noch fehlt sind erweiterte Prüfungen wie Keybord-Layout-Check, TopTen-Passwörter-Check und wohl zu aufwändig, ein Wörterbuch-Check.

***

Zum Thema Entropie und Passwortlänge:

Kein Mensch/Hacker setzt sich an den PC und probiert manuell zig Tausend Kombinationen an der Tastatur. Es ist entweder ein wissensbasierter Angriff (Geburtstag/Name des Hundes/Passwort-TopTen), der dann einen Glückstreffer bringt oder ein maschineller Angriff auf den Hashcode.

Beim Angriff mit Hashcode wird wohl erst eine Wörterbuch-Attacke (einzelne/kombinierte Wörter einer Sprache) erfolgen und danach simples BruteForce... also alle Zeichenkombinationen/Längen durchprobiert. Da bin ich davon überzeugt, das leichte Entropie und breite Nutzung des Zeichensatzes und vor allem Länge den maximalen Schwierigkeitsgrad bringen. Eine maximale Entropie ist garnicht nötig, es werden sowieso maschinell alle Zeichen durchgetestet, also die Schleifen für jede Zeichenposition immer komplett durchlaufen.

***

Ich lasse mal das ganze etwas ruhen, ich denke es wurde so ziemlich alles zum Thema angesprochen. Für mich arbeitet die Prüfmethode gut und ich werde die (Logik) ins Projekt übernehmen.

Wenn ich mit dem Hauptprojekt weiter bin, werde ich dann hier noch die resultierenden Komponenten anhängen.

[negaH]

Im originalen Thread zu PassphraseQuality habe ich geschrieben das es keine echte Funktion geben kann die die Qualität eines Passwortes errechnet und auch das die gewählten Schranken in dieser Funktion aus mathematisch krypographischer Sicht sowieso viel zu gering geählt wurden. (würde man sich an math. anerkannten Schranken orientieren so würde man mit ganzen Sätzen mit mehr als 160 Zeichen also Passwörter arbeiten müssen).

Es gibt nur sehr wenige Bewertungfunktionen die man benutzen kann und bei denen man deren Sinnhaftigkeit auch math. als sinnvoll beweisen kann.

Eine ist die Entropie. Entropie lässt sich eindeutig berechnen und ist auch ein Maß für die Zufälligkeit einer Datenmenge. Je zufälliger ein Passwort desto wertvoller. Entropie ist also ein Maß das man ohne Wissen um die vom Angreifer verwendeten Verfahren immer als Maßstab benutzen kann. Die Verfahren zur Berechnung der Entropie sind beweisbar. In meinem Fall habe ich die Enropie der deutschen/englischen Sprache zu Grunde gelegt (der Multiplikationsfaktor ist entscheidend).

Ein weiteres beweisbares Verfahren ist die Wörterdatenbank. Fast alle heutigen kryptologischen Angriffe die besser als die reine Brute Force Attacke sind sind Wörterbuchangriffe. Nachteil für unsere Funktion ist die Wörterdatenbank ansich, es ist unpraktikabel bzw. in Relation zu einem echten Zufallspasswort ist eine Wörterdatenbank für unsere Funktion vom Aufwand-Nutzen-Verhältnis absoluter Schwachsinn.

Das Problem mit solchen Bewertungsfunktion ist der Fakt das man nur gute Funktionen konstruieren kann wenn man den Angriff exakt kennt der auf das Passwort angewendet wird. Man kennt den Angriff nicht ergo kann man nur eine allgemeingültige Funktion bauen, bzw. nur das lohnt sich im Vergleich zu echten Zufallspasswörtern.

Man kann noch einfachste Kriterien berücksichtigen zb. eben Tastaturlayouts etc.pp. wie in meiner Funktion auch geschehen. Mehr lohnt aber nicht.

Fazit: solche Funktionen sind niemals ein gutes Indiz für die reale Qualität eines Passwortes. Selbst das komplizierteste, längste und zufälligste Passwort muß 0% ergeben wenn es Allen im WEB bekannt gemacht wird oder wenn es einen Hacker schon längst bekannt ist. Dann wissen wir das noch nichtmal und das zeigt schon das solche Funktionen im Grunde das Unmögliche versuchen.

Es ist und bleibt in irgendeiner Form immer eine "Gimmeck-Funktion".

Nun könnte der Einwand kommen warum ich mit dieser Überzeugung überhaupt eine solche Funktion veröffentlicht habe ?

Weil sie besser und math. korrekter ist als viele der anderen Funktionen die im WEB kursieren.
Und weil es offensichtlich einen Bedarf für solche Funktionen gibt.

Was du nun als "falsches" oder "unlogisches" Ergebnis betrachtest ist reine Ansichtssache oder besser gesagt Definitionssache. In deiner Betrachtungsweise mag dein Passwort mit den vielen t's besser sein als das mit den wenigen t's, aber kannst du mir auch math. beweisbar begründen warum ich deiner Betrachtungsweise zustimmen sollte ? Ich argumentiere das meine Funktion einfach math. die Entropie als Merkmal einer Datenmenge berechnet und daraus gewichtet die Qualität bewertet. Ich kann verargumentieren das uns dieser Weg als Denkmodel offensteht und kryptographisch korrekt sein muß innerhalb des angenommenen Modells. Dh. alles basiert auf beweisbarem Wissen und nicht gefühlsmäßigen Annahmen, und das ist der wirklich wichtige Punkt bei der ganzen Diskussion. Damit möchte ich nicht sagen das du mit deiner Annahme falsch liegst o.ä. sondern nur darlegen was man letzendlich an Informationen auswerten und als Bewertung überhaupt sinnvollerweise heran ziehen kann.

Letzendlich gilt folgendes:
1.) zufällige Passwörter sind der Maßstab an dem wir uns orientieren müssen
2.) die annerkannten Sicherheitsschranken für Zufallspasswörter sind unsere Bewertungsgrundlage, dh. also zb. > 128 Bits bei symmetrischen Verchlüsselungen. Diese Schranken sind durch Mathematiker errechnet.
3.) je weniger zufällig desto höher die Wahrscheinlichkeit für eine Semantik, desto höher die Wahrscheinlichkeit für Wörterbuchangriffe bzw. Angriffe mit bekanntem Wissen
4.) Entropie ist ein Maßstab für Zufälligkeit
5.) ergo: Entropie kann als primäres Kriterium für die Bewertung heran gezogen werden (neben der Länge des Passwortes)

Welche Gewichtung man benutzt zwischen Entropie, Länge usw. des Passwortes ist reine Erfahrungssache und du wirst darüber meiner Kenntnis nach nichts an Material im WEB finden (ausser pauschalen Aussagen). Nun, exakt diese Gewichtung der Faktoren innerhalb der Geamtbewertung der Qualität ist es die in deinem Falle so "unlogische" Resultate erzeugt. Gebe mir eine bessere Gewichtung die du eventuell an Hand von Fakten auch math. beweisen kannst.

Gruß Hagen

[Satty67]

Erst mal Danke, das du dir die Mühe gemacht hast so ausführlich zu antworten. Es war wichtig, dass Du Deinen Standpunkt hier so deutlich gemacht hast. Es erleichtert den Leuten zu entscheiden, wenn Sie eine Methode suchen.

****

Letzlich ist die Frage, ob Satty67 sicher ist als Sattttttttty67 nicht nicht zu beweisen, wenn ich deiner Argumentation folge. Deine Funktion sagt, dass o.a. kürzere Passwort ist sicherer. Ich vermute, das längere Passwort ist sicherer als das kürzere, wenn das kürzere Bestandteil des längeren ist. Das ist halt nur simple Logik. Die Anzahl unterschiedlicher Zeichen ist ja die gleiche, aber die Entropie wird schlechter, weil Gesamt-Verteilung schlechter wird. Im Prinzip kann bei strenger Entropie-Prüfung ein langes Passwort nur noch schlechter werden, wenn einem die Zeichen ausgehen. Ich könnte mich anschließen, wenn man behauptet, es wird dann nicht besser, aber schlechter kann ich einfach nicht nachvollziehen.

Es ist aber nicht wirklich schlimm, das wir da nicht 100% gleicher Meinung sind. Ich hatte es schon geschrieben und schreibe es nochmal: Deine Funktion riskiert zumindest nie, ein schlechteres Passwort besser zu bewerten.

Zitat von negaH:

Gebe mir eine bessere Gewichtung die du eventuell an Hand von Fakten auch math. beweisen kannst.

Du hast ja selbst geschrieben, dass es so einen (entgültigen) Beweis für keine Prüfmethode geben kann. Daher ist im Prinzip auch eine Diskussion um die bessere Methode sinnlos. €: Ich weis, das ich selbst die Diskussion angestossen hab', aber da kannte ich noch nicht die Gegenargumente.

[Reinhard Kern]

Zitat von negaH:

1.) zufällige Passwörter sind der Maßstab an dem wir uns orientieren müssen
2.) die annerkannten Sicherheitsschranken für Zufallspasswörter sind unsere Bewertungsgrundlage, dh. also zb. > 128 Bits bei symmetrischen Verchlüsselungen. Diese Schranken sind durch Mathematiker errechnet.
3.) je weniger zufällig desto höher die Wahrscheinlichkeit für eine Semantik, desto höher die Wahrscheinlichkeit für Wörterbuchangriffe bzw. Angriffe mit bekanntem Wissen
4.) Entropie ist ein Maßstab für Zufälligkeit
5.) ergo: Entropie kann als primäres Kriterium für die Bewertung heran gezogen werden (neben der Länge des Passwortes)

Hallo Hagen,

offensichtlich hast du die Diskussion überhaupt nicht gelesen. Deine Argumentation ist Nonsense: eine beliebige Zeichenfolge aus 7 Buchstaben ist schon ein ziemlich starkes Passwort, allerdings ist z.B. "Schatzi" völlig unbrauchbar (ich hoffe, das muss ich dir nicht auch noch erklären), und das geht aus der Entropie nicht hervor. Zudem gilt das nur in Deutschland, in Indien sind ganz andere Wörter schwache Passwörter.

Die Entropie besagt absolut nichts. Allenfalls könnte man auf sprachübliche Silben prüfen, aber damit eliminiert man sprechbare Wörter und nicht nur sinnvolle, ausserdem hat das ja auch nichts mit Entropie zu tun.

Alle existierenden Algorithmen zur Bestimmung der Passwortstärke sind hilflose Ersatzrechnereien im Bewusstsein der Tatsache, dass es keinen wirklichen Algorithmus gibt - oder eben auch ohne das Bewusstsein, davon wird der Algorithmus aber nicht besser.

Übrigens kann natürlich auch ein zufälliger Passwortgenerator "Schatzi" liefern, aber die Wahrscheinlichkeit ist erträglich gering, und der User muss es ja nicht nehmen, Verstand ist manchmal auch ganz nützlich.

Gruss Reinhard

[himitsu]

Zitat:

offensichtlich ... "Schatzi" ... schwache Passwörter.

Zu den "Wörterbüchern" hatt er doch was gesagt?

Wenn "Schatzi" demjenigen, welcher das Passwort erraten soll, nicht bekannt ist, dann ist dieses Passwort genauso sicher, wie z.B. "umflcRa".

Du müßtest allso in die Prüfung ein Wörterbuch einbinden,
nur gibt es da ein Problem. denn du kennst das Wörterbuch des Angreifers nicht.
Es gibt also vermutlich Wörter, welche der Angreifer kennt/verwendet, aber weil dein Wörterbuch es nicht kennt, würde dein Code dann behaupten das Passwort wäre sicher ... mit etwas Pech steht dieses Wort dann auch noch am Anfang der Wörterlist und ist ratzfatz geknackt.



Eventuell könnte man zur Entropie noch eine gramatikalische Prüfung nutzen, welche dann mit mehrere Sprachen prüft, ob das Word in dieses Sprachen ein "aussprechbares" Wort wäre.

Nur lassen sich "sprechbare" Wörter besser merken und werden gern benutzt.

[Satty67]

Mir ist zumindest klar, das es wohl nur schwer bis garnicht realisierbar ist, alles abzudecken. Ich kann der Argumentation (von Hagen) zumindest soweit folgen, das es zwar ein gutes aber nie ein ideales Vorschlagsystem geben kann, weil man es nicht nachweisen könnte. Das ich Ihm in Sachen Entropie nicht 100% folgen kann, habe ich ja oben geschrieben.

Mir ging es aber vor allem um eines:

Wenn der Benutzer bei der Passwort-Bewertung so ins Grübeln kommt, wie ich, dann zweifelt er an meinem ganzen Programm. Das ist nicht schön

Zitat von Reinhard Kern:

Verstand ist manchmal auch ganz nützlich.

Das ist wohl das wichtigste. Das Eingabefeld bekommt einen deutlichen Hinweis, dass die Bewertung nur eine Hilfestellung ist, aber kein Garant für ein sicheres Passwort.

PS: Auf die Bewertung verzichten will ich aber auch nicht, für die meisten ist es ein Ansporn, die LED auf "grün" zu bringen

[hathor]

Beispiel:

€~}|{`_^]\[@?>=<;:/.-,+*)('&%$#"!

Sicherheit bei annähernd 69,4%

Da habe ich mehr erwartet!
---------------------------------------------------
€~}|{`_^]\[@?>=<;:/.-,+*)('&%$#"!zZ

Sicherheit bei annähernd 91,7%
---------------------------------------------------
€~}|{`_^]\[@?>=<;:/.-,+*)('&%$#"!zZ1

Sicherheit bei annähernd 100,0%
---------------------------------------------------
{`_^]\[@?>=<;:/.-,+*)('&%$#"!zZ1

Sicherheit bei annähernd 100,0%
---------------------------------------------------
{ö_ü]ß[@?>=<;:/.-,+*)(ä&%$#"!zZ1

Sicherheit bei annähernd 100,0%

[Satty67]

...und bei PassphraseQuality? 54,9% bzw. 58,9%

Der Grund ist aber schnell genannt. Nur Sonderzeichen sind knapp 30 auf der Tastatur erreichbare Zeichen. Mit einer Ziffer erhöhst Du auf weitere 10 Zeichen... das gleiche bei Buchstaben.

Bei TPasswortCheck (Komponente auf Basis des Codes): 69,4 bzw. 77,8%

Dort wurden die Multiplikatoren nochmal justiert. Ich konnte den Code hier nicht mehr aktualisieren (24h Sperre).

***

Ich könnte den entgültigen Code, der aktuell auch in TPasswortCheck verbaut ist, hier posten. Vielleicht auch einen Moderator bitten, im ersten Post ein Verweis auf den anderen Thread zu setzen oder den Code auszutauschen.