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

[Die Muhkuh]

Zitat:

Zitat von Satty67 (Beitrag 1050392)

Ganz ehrlich, ich bin mit Auswertungsergebnis ziemlich zufrieden. Hagen hat mit Sicherheit die cryptologisch besseren Prüfmethoden verwendet, aber imho eben an einer Stelle einen Fehler drin oder zumindest ein seltsames Verhalten.

Ich würde, allein auf Grund Deiner Aussage, eher Hagens Prüfmethode bevorzugen da er, wie Du selbst sagt, die kryptologisch bessere Prüfmethode verwendet. Was bringt mir dann eine, die eine Passwortsicherheit anzeigt, die sich jemand ausgedacht hat? ;-)

Eventuell kann ja Hagen das ganze mal kommentieren, auch Deine Aussage, dass die vielen 't' hintereinander eine Brute-Force-Attacke erschweren sollte.

[Satty67]

Zitat:

Zitat von sx2008 (Beitrag 1050431)

"hey, du solltest hier besser eine Klasse draus machen!"

Es steht zwar versteckt da, aber es steht da... wird später Bestandteil eines TPasswordEdits bzw. passwordTextBox.

Zitat:

Zitat von Die Muhkuh (Beitrag 1050432)

die kryptologisch bessere Prüfmethode verwendet. Was bringt mir dann eine, die eine Passwortsicherheit anzeigt, die sich jemand ausgedacht hat?

Es gibt auch sichere Passwörter, die nicht wie von einem RandomCryptoGenerator erzeugt aussehen, da patzt nunmal meiner Meinung nach PassphraseQuality. Man kann PassphraseQuality zwar nicht vorwerfen, das es schlechte Passwörter gut bewertet, aber zumindest gleichwertige nicht gleich. Zudem denke ich, das meine Methode garnicht so übel ist, auch unter streng cryptologischen Gesichtspunkten.

Es wird eine Benutzerschnittstelle, das soll alles möglichst nachvollziehbar sein und nicht verwundern oder gar verärgern. Ich hätte mir die Arbeit ja garnicht gemacht, wenn ich nicht selbst beim Testen plötzlich ganz irritiert gewesen wäre.

Zitat:

Zitat von Die Muhkuh (Beitrag 1050432)

eine Passwortsicherheit anzeigt, die sich jemand ausgedacht hat?

Alles ist ausgedacht... von irgend jemandem, irgendwann. Ich hab's mir ja auch nicht in der dunklen Kammer ausgedacht, sondern mich durch Überlegungen und Beispiele aus dem Internet anregen lassen. Ich verfolge nur nicht die ganz strege entropologische Prüfung, weil ich davon überzeugt bin, dass es das nicht braucht.

Zitat:

Zitat von Die Muhkuh (Beitrag 1050432)

dass die vielen 't' hintereinander eine Brute-Force-Attacke erschweren sollte.

Da habe ich mich Sir Rufo's Einwänden angeschlossen und einen Kompromiss gefunden. Viele gleiche Zeichen werten ein Passwort nicht mehr auf, aber auch nicht mehr ab im vergleich zu einem gleichen Passwort, dem nur die wiederholten Zeichen fehlen.

***

Ich schreibe nacher Hagen eine Mail, er hat ja in jedem Fall viel Erfahrung in dem Bereich und möchte Stellung beziehen.

[Reinhard Kern]

Zitat:

Zitat von Satty67 (Beitrag 1050443)

Alles ist ausgedacht... von irgend jemandem, irgendwann. ....

Hallo,

ein grundsätzlicher Einwand: man kann (soll) Passwörter so erzeugen, dass die Folge völlig zufällig ist, z.B. mit einem Passwortgenerator. Das ist auch garkein Problem, aber umgekehrt ist es sehr schwer festzustellen, ob eine Buchstabenfolge zufällig ist (was immer das heisst, denn unter den zufälligen Folgen befinden sich ja auch alle sinnvollen Wörter).

Beispiele: VWLOHFZ HAMBURG LJYQXVD SCHATZI UZMZUOE

Eigentlich müssten Hamburg und Schatzi mit 0, die 3 anderen (generierten) mit 1 bzw. der für 7 Buchstaben höchsten Zahl bewertet werden. Ich schätze das geht nicht ohne Wörterbuch, und das müsste für jedes Land anders sein.

Gruss Reinhard

[Namenloser]

Noch wichtiger als die Anzahl und Entropie der Zeichen wäre imo zu prüfen, ob das Passwort zum Großteil aus einem oder 2 Wörtern besteht. Die meisten Angreifer werden nicht alle Möglichkeiten bruteforcen sondern einfach eine Wörterbuchattacke durchführen, mit der sie vielleicht bei 50% der Nutzer erfolgreich sind. Es gibt im Internet Listen mit häufig verwendeten Wörtern oder sogar häufig verwendeten Passwörtern.
Wenn ein Wort gefunden wird, sollte es als nur ein (oder 2?) Buchstabe(n) gewertet werden. (DasPferdFrisstGerneGurkenSalat ist ja schließlich nicht unsicherer als SPFGGS, genauer gesagt ist es sogar sicherer, weil es mehr Wörter als Buchstaben gibt).
Kommt halt darauf an, wie viel Aufwand du in die Passwortprüfung investieren willst...
[edit]Reinhard Kern war schneller...[/edit]

[cookie22]

Zitat:

Keyboard-Layout: QWERTZ und CO, was Hagen bei sich implementiert hat

wenn du dein programm nur in einem land nutzt ist das relativ einfach, schwieriger wird es wenn es international ist.

Zitat:

Wenn eines der häufig genutzen Passwörter eingegeben wird

du kannst dir im netz ein password wörterbuch beschaffen, es gibt dort welche mit den 3000-4000 meist genuzten passwörtern.

[Satty67]

Ja, eine Liste der häufigsten Passwörter zum ausschließen ist auf der ToDo-Liste (siehe erster Post). Das mache ich aber erst, wenn der Code in ein TPasswortEdit eingebaut wird. Die Liste kommt nicht fest in den Code sondern wird per Property publiziert. Dann kann man die auch noch in der Anwendung pflegen und aktualisieren und evtl. auf Wörterbuchgröße erweitern.

Das "Wörter einer Sprache" eine großes Problem sind, hab' ich auch gelesen, genauso Namen und eben Kombinationen daraus. Derzeit ist nur ein Methode drin, die Passwörter aus nur Buchstaben abwertet. Reinhards Beispiel zeigt schön, dass es mathematisch wohl keine sprachübergreifende gute Lösung für das Problem gibt. Mein Ansatz "drängt" den Anwender nur dazu, Zahlen und Sonderzeichen einzubauen, um auf einen besseren Wert zu kommen.

Die im Moment noch als Konstanten in der Funktion vorhandenen Werte, werden später auch als Property angeboten. Um den Einwänden Rechnung zu tragen,wird noch Bewertung der Länge und Abwertung von "Nur Buchstaben"-Passwörtern einstellbar. Neben der Manupulation der Einzel-Faktoren, kann ich dann auch Profile anbieten, die von locker bis streng voreinstellen.

Ich denke der Code ist schon recht flexibel... setze ich z.B. DiffCharsMaxMulti = 100, ist die Entropie fast schon strenger wie bei PassphraseQuality.

***

Was die Komplexität angeht... für das aktuelle Projekt nicht nötig. Dort wird auch nur angezeigt, nicht ein mindest Wert vorgeschrieben. Es sind Fahrzeug-Dokumente, keine geheimen Staatsakten. Aber soll ja alles wiederverwertbar sein und notfalls auch höheren Ansprüchen genügen.

[Namenloser]

Vielleicht könnte man als Annäherung analysieren, welche Buchstaben oder Buchstabenpaare oder Silben in der jeweiligen Sprache statistisch am häufigsten aufeinander folgen und dann diese Folgen in den Passwörtern abwerten? Somit muss man nicht ein komplettes Wörterbuch "mitschleppen", sondern nur ein vergleichsweise kleines Sprachprofil. Man könnte vielleicht sogar ein neuronales Netz dafür nehmen.

Ich habe aber keine Ahnung, wie gut so etwas funktionieren würde. Möglicherweise ist die Idee auch nur Mist...

[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 :arrow: 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:

Zitat von BUG (Beitrag 1050502)

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.