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

[BUG]

Ich denke zwar nicht, das Google deine Passwörter (passend dazu bei xkcd) will, halte es aber einfach prinzipiell für eine nicht so tolle Idee, Geheimnisse durch die Welt zu schreien und zu hoffen, das sie im allgemeinen Rauschen untergehen :wink:

[cookie22]

[QUOTE=Reinhard Kern;1052518]

Zitat:

Zitat von BUG (Beitrag 1052469)

...Ein Passwort im Klartext zu verschicken ist zunächst nicht gefährlich, wenn keiner weiss, dass es ein (mögliches) Passwort ist...

der vorschlag ist komplett unbrauchbar. falls ein angreifer weiss, dass du genau diese software benutzt fängt er einfach alles ab, was du an google schickst. :stupid:

[hathor]

Zitat:

Zitat von Reinhard Kern (Beitrag 1052518)

...Aber würde sich mein Vorschlag allgemein durchsetzen, könnte google schnell auf die Idee kommen, für jeden Benutzer zu speichern,...

Gruss Reinhard

Das wird doch schon lange gemacht!
Wenn ich heute nach "Kaffeemaschine" oder "Hurghada" google, dann bekomme ich die folgenden Wochen oder Monate bevorzugt Werbung von und mit diesen Anbietern.

[Namenloser]

Irgendwo konnte man sich sogar bei Google eine Liste anzeigen lassen, wonach man im letzten halben Jahr (oder so) gesucht hat. Keine gute Idee!

[negaH]

Zitat:

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.

Ich denke du hast meine Argumentation nicht ganz verstanden.

1.) gefühlsmäßig logisch betrachtet hast du Recht mit der Annahme das das längere Passwort besser wäre als das kürzere
2.) meine Funktion arbeitet mit gewissen Annahmen und entsprechend diesen Annahmen errechnet sie korrekte Resultate
3.) es ist also eine Frage der Definition was meine Funktion mit welchen Methoden errechnen soll
4.) wir wissen ja nun das es im Grunde eine solche Funktion nie geben kann, bzw. man kann einfach nicht die echte Sicherheit eines Passwortes berechnen. Ganz strikt betrachtet würde das Berechnen der Qualität eines Passwortes ja die Übertragung des Passwortes zur Bewertungsfunktion bedeuten und das könnte paranoid betrachtet schon die Qualität auf 0% reduzieren.

Ergo: Du kannst meine Funktion immer verbessern wenn du möchtest, ich persönlich halte das aber für unsinnig. Die Resultate die meine Funktion liefert sind programmatisch korrekt, es ist nur eine Frage der Gewichtung. Eine beste und starre Gewichtung wird es aber niemals geben. Man kann auch bei deiner Funktion Counterexamples konstruieren die gefühlte "unlogische" Resultate liefern. Zb. "ABC" sollte immer sicherer als "AAAA" sein obwohl AAAA 4 Buchstaben enthält.


@Reinhard Kern:

mal ganz genau das http://de.wikipedia.org/wiki/Entropi...ionstheorie%29 lesen. Es geht um Redundanz und Entropie ist ein Maßstab für Redundanz. Zufall ist redundanzlos und da wir Zufall als besten Maßstab für ein Passwort definieren ist die Entropie sehr wohl eine gute Funktion für die Bewertung. Da die eingegebenen Passwörter nun auch noch von Menschen stammen, die Sparche benutzen, und somit auch sprachliche Passwörter ist die Entropie sehr wohl ein geeignetes Instrument. Gerade weil sie auch sprachabhängig ist und ich habe niemals gesagt das diese Funktion für Inder oder Chinesen tauglich wäre. Das Gegenteil ist der Fall, ich beschränke mich sogar auf eine QWERTZ/QWERTY Tatstatur und das ist offensichtlich auch sprachabhängig. Und es geht bei meiner Funktion darum das zufällig aussehende Passwörter, also möglichst sprachlich redundanzlose Passwörter, besser bewertet werden. Und das geht nur über die Entropie.

Entscheidend ist die Frage: welche Alternativen an Berechnungsfunktionen hätten wir noch um ein Passwort zu bewerten ? Versuche erstmal selber eine solche Funktion zu entwickeln und du wirst sehen das da nicht viel übrig bleibt was Sinn macht, kompakt ist und nicht selber eine Sicherheitslücke aufreist weil man das Passwort auch noch Google bekannt macht.

Übrigens lese ich immer die Threads bevor ich was poste, erst recht wenn ich per PN eingeladen wurde.

Gruß Hagen

[Reinhard Kern]

Zitat:

Zitat von negaH (Beitrag 1052552)

Zufall ist redundanzlos und da wir Zufall als besten Maßstab für ein Passwort definieren ist die Entropie sehr wohl eine gute Funktion für die Bewertung.

Diese Diskussion führt bei Passwörtern nur in die Irre: 123456 ist genauso zufällig wie jede andere 6stellige Zahl (auch wenn Lottospieler sowas meistens nicht glauben) und ein Zufallsgenerator spuckt sie auch mit der gleichen Wahrscheinlichkeit aus. Dass deswegen 123456 ein starkes Passwort oder eine starke PIN ist, glaube ich aber auch nicht, wenn du noch 10mal versuchst, das mathematisch zu beweisen. Mathe ist ein nettes Hilfsmittel, aber hier geht die Argumentation am Problem vorbei, weil das Problem garnicht mathematischer Art ist, sondern vor dem Bildschirm sitzt.

Jeder halbwegs qualifizierte Hacker wird zuallererst eine Attacke per Passwortliste oder Wörterbuch versuchen, weil der Quotient aus Erfolg und Aufwand dabei mit Abstand am besten ist. Du schreibst, dass du die häufigste Angriffsform einfach nicht beachtest, weil es zu viel Aufwand wäre - das ist keine Lösung, sondern ein weisses Handtuch. Das kommt mir so vor, wie wenn jemand sagt "ich weiss nicht, wie man 2 und 2 rechnet, aber ich schreib mal einen Algorithmus, bei dem 5 rauskommt - das ist besser als garkeine Software".

Um halbwegs brauchbare Passwörter zu erzwingen - worum es bei der Problemstellung ja eigentlich geht, nicht um eine Stärkedefinition in der Einheit mHagen - bleiben 2 Punkte:
1. Eine Mindestlänge. Das begründe ich jetzt mal nicht weiter.
2. Das Vorkommen eines Nichtbuchstabens. Das macht Wörterbuchattacken sehr viel schwieriger bis unmöglich, weil es z.B. kein deutsches Wort mit ! gibt.

Beides ist sinnvoll, aber so trivial, dass man dafür keinen Algorithmus braucht.

Darüber hinausgehende Zahlenangaben zur Stärke sind meiner Meinung nach die Vorspiegelung nicht vorhandenen Wissens. Und ich behaupte keineswegs, einen besseren Algo schreiben zu können, sondern vielmehr, dass sich die Arbeit nicht lohnt.

Gruss Reinhard

[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?

[mleyen]

Zitat:

Zitat von Satty67 (Beitrag 1052504)

hab' gleich mal Satty67 und Sattttttty67 eingegeben (duck und weg...)

Ne, also sehr interessant. Man kann auch schön verfolgen, wie einzelne Eingaben bewertet werden. Allgemein geht es aber fast zu schnell Richtung 100%. Da bleibt wenig Luft für Leute, die komplexere Passwörter mögen. Aber das kann man sicher anpassen.

Hagen hat recht.
Wenn man solche Einflussfaktoren wie Länge, Wörterbuch, Zufälligkeit, etc. nicht mit einbezieht, ist es bei weitem schlechter.

Brechen wir es doch mal aufs einfachste und logischste herrunter.
Wie definiert sich grundlegend die Passwortsicherheit?
Aus der gegebenen Zeichenmenge und die Verwendung von möglichst vielen unterschiedlichen Zeichen aus dieser Zeichenmenge:

Delphi-Quellcode:

function GetPWSecurenessStandard(const AStr: string): Byte;
// Vereinfacht, man könnte zB nach der Überschreitung von MaxDfrntSgns auf die Unterschiedlichkeit prüfen (100% eig. nur erreichbar, wenn man die Länge des Inhalts kennen würde)

  function GetMaxDfrntSgns: Cardinal;
  begin
    Result := Round(Power(2, SizeOf(Char) * 8));
    // Könnte auch sowas sein:
//      Result := Ord('z')+1-Ord('a') {+ Ord('Z')+1-Ord('A')};
  end;

  function CntDfrntSgns: Cardinal;
  var
    i: Integer;
    DfrntSgns: string;
  begin
    for i := 1 to Length(AStr) do
      if Pos(AStr[i],DfrntSgns)<=0 then
        DfrntSgns := DfrntSgns + AStr[i];
    Result := Length(DfrntSgns);
  end;

var
  DfrntSgnsCnt: Cardinal;
  MaxDfrntSgns: Cardinal;
begin
  MaxDfrntSgns := GetMaxDfrntSgns;
  if AStr = '' then
  begin
    Result := IfThen(MaxDfrntSgns = 0, 100, 0);
    Exit;
  end;

  DfrntSgnsCnt := CntDfrntSgns;

  if MaxDfrntSgns = DfrntSgnsCnt then
    Result := 100
  else
    Result := Round(DfrntSgnsCnt / Length(AStr) * 100);
end;

Sobald Doppelungen vorkommen ist es halt nicht mehr die maximal mögliche Sicherheit.

Wenn man jetzt Einflussfaktoren, wie z.B. einen Längenfaktor des Passworts miteinbeziehen will, sollte man folgendes machen:

Delphi-Quellcode:

function GetPWSecurenessLengthFactored(const AStr: string): Byte;
const
  // Setze diese Einflussfaktoren auf ein Maximum, von denen du denkst das es 100% Sicherheit gewährleistet:
  MinSecurePWLength = 10;
  // Prozentuale Einflussfaktoren (0-100):
  SecurenessFactorOfPWLength = 50;

begin
  if Length(AStr) >= MinSecurePWLength then
    Result := 100
  else
    Result := Round(Length(AStr) / MinSecurePWLength * 100);

  Result := Round(
    (SecurenessFactorOfPWLength / 100 * Result) +
    (100 - SecurenessFactorOfPWLength) / 100 * GetPWSecurenessStandard(AStr)
  );
end;

Und ich denke mal genau hier muss man selber weiterdenken. Denn man weiß nicht was für wen eine 100%ig sichere Länge ist. Genausowenig wie man mathematisch weiß was Zufall ist.
Jedoch, wenn man alle Passwörter der Welt kennen würde, könnte man eine favorisierte Passwörter-Liste miteinfließen lassen.
Genauso könnte man auch favorisierte Zeichen, wie z.B.: 'a'..'z', 'A'..'Z' und die 'seltenen' Sonderzeichen mit einfließen lassen.

Nur mathematisch lässt sich sowas nicht bestimmen.
Zu guter letzt nochmal ein (nicht wiedergefundenes) Zitat von Hagen zu einem Faktor der maximalen Sicherheit:
"Das Passwort muss genauso lang sein wie der Inhalt um die mathematisch maximale Sicherheit sicherzustellen?"

Edit:
Ui, sind da noch viele Beiträge zwichenzeitlich reingekommen.
Hier nochmal Einflussfaktoren aufgelistet:
- Passwortlänge
- Die für das Passwort mögliche Zeichenmenge
- Verwendung der Zeichenmenge (zB keine Dopplungen)
- Häufigkeit eines verwendeten Passworts
- Häufigkeit der verwendeten Zeichenmenge
(- Situationsbedingt: Der bekannte verschlüsselte Inhalt, durch den sich auf das Passwort zurückschließen lässt)

Also du hättest aus "Sattttttty67" -> "Sat!ty67" machen können. Dies wäre sicherer, da mehr unterschiedliche Zeichen aus der unbekannten Zeichenmenge verwendet würden.

[Satty67]

Zitat:

Zitat von mleyen (Beitrag 1052578)

Sobald Doppelungen vorkommen ist es halt nicht mehr die maximal mögliche Sicherheit.

Ok, fangen wir mal klein an. Das ist ja die Kernaussage, die mich in meinem Ausgangspost verwirrt hatte.

Kann mir jemand irgendwie erklären, warum "ab" sicherer ist als "cc"?
Wieso ist es einfacher herauszufinden, dass erst ein "c" kommt und danach noch ein "c"?
Wieso ist es schwerer wenn ein "a" kommt, zu ermitteln, dass danach ein "b" kommt?

Das ist auf den kleinsten Nenner reduziert, was ich irgendwie nicht ganz verstehen kann. Jetzt aber bitte nicht einfach, "weil 'ab' unterschiedliche Zeichen sind", das sehe ich auch ;). Nein, warum ist es schwerer "ab" zu ermitteln, statt "cc".

***

Beides sind ja keine Passwörter aber wären Sie es, dann sieht für mich ein Angriff so aus:

aa, ab, ac, ad ... ca, cb, cc

"cc" dauert länger und "cccc" würde erheblich länger dauern. Vielleicht gibt es ja eine einfache Erklärung, die aufzeigt, warum das ein Irrglaube ist.

[mleyen]

Lass mal bitte Bruteforce aus dem Spiel. Das ist eine komplette Situation für sich.
Stell dir mal vor du müsstest dich an einem online-Account anmelden und hättest nur einen Versuch. Bei falscheingabe des Passworts wird der Account direkt gesperrt/gelöscht.

Bei "cc" könnte die Passworteingabe so lauten:
"Bitte geben Sie ein 5-9 stelliges Passwort ein, welches nur aus 'c's besteht, jedoch in der Länge variiert"
Möglichkeiten dies zu erraten: 20%

Bei "ab" könnte die Passworteingabe so lauten:
"Bitte geben Sie ein 5-9 stelliges Passwort ein, welches nur aus 'a's und 'b's besteht"
Möglichkeiten dies zu erraten: 0,001%

Wenn man jetzt wüsste, dass die Eingabemöglichkeiten gleich sind, dann kann man auch sagen die Passwörter sind gleich 'gut'.

[Satty67]

und wenn die Aufforfderung lautet:
"Bitte geben Sie ein 5-9 stelliges Passwort ein, welches nur aus 'a's und/oder 'b's und/oder 'c's besteht"

Hier wurde doch (im ersten Fall) schon wieder ein Sonderfall als Erklärung konstruiert, dass der Angreifer weis, das Passwort besteht nur aus "c"s.

Ich weis, dass niemand mir das erklären muss, vor allem weil ich stur und gerne starrköpfig bin, auch nicht so einfach. Ihr könnt mich auch mit meinem Irrglauben alleine in der Wüste stehen lassen ;) Aber das ist halt der Punkt, wo ich irgendwie (beim Verstehen) klemme...

[Sir Rufo]

Ein Grund wäre z.B. wenn das Passwort auch für eine Verschlüsselung benutzt wird (WLAN).

Dann schwächen viele sich wiederholende Zeichen die Verschlüsselung.

[Satty67]

Also die Verschlüsselung wird dadurch schwächer. Ok, das kann ich verstehen.

Das der Programmierer das Passwort direkt dafür einsetzt wäre natürlich doof, aber das kann die Testfunktion ja nicht wissen und muss den schlimmsten Fall annehmen.

Ich weis nicht ob es am Wetter liegt oder was sonst ist. Aber hier im Forum herrscht im Moment eine großzügige Gelassenheit. Nicht nur mein Thread ist sicher nervend, auch einige Anfänger-Threads wurden sehr gelassen ohne Aggression behandelt. Macht im Moment richtig Spass, im Forum zu lesen...

[negaH]

Der offensichtliche Unterschied zwischen den 3 Zeichen Passwörtern "ccc" und "abc" besteht in der Varianz.

Beide Passwörter haben 3 Zeichen. Aber nur das Passwort "abc" hat 3 Zeichen aus einem Alphabet von 3 Zeichen. Das Passwort "ccc" hat 3 Zeichen aus einem Alphabet von 1 Zeichen.

Nun beweise mir das der Angreifer nicht nur das Alphabeth "c" benutzt sondern eben immer das komplette Alphabet bei seinem Angriff benutzt. Denn falls er seinen Angriff nur mit dem Symbolraum "c" durchführt dann kann er das Passwort "ccc" nach 3 Versuchen knacken. Beim Symbolraum "abc" benötigt er aber schon 6 Versuche. Dh. an Hand des Passwortes kann man sehr wohl den nötigen Aufwand festlegen den der Hacker aufwenden muß. Jede andere Annahme führt die auf Passwörtern basierende Kryptographie ad absurdum.

Wenn du eine Funktion bauen möchtest die die Qualität eines Passwortes bewertet dann muß man sich eben über verschiedene Punkte im Klaren sein:

1.) die einzige, harte Ausgangsbasis ist der Fakt das wir ein Passwort für eine Verschlüsselung bewerten wollen. Dh. die für die Verschlüsselungen anerkannten Regeln für gute Passwörter müssen als Bewertungsfunktion benutzt werden. Die beiden wichtigsten Regeln für Passörter in Verschlüsselungen sind die Länge des Passwortes und die Gleichverteilung der Wahrscheinlichkeit des ausgewählten Schlüssels im Schlüsselraum der Verschlüsselung. Letzteres mal verkürzt ausgedückt: das Passwort sollte zufällig sein.

2.) Irgendwelche Annahmen mit welchem Verfahren, also wie und welche Verfahren ein möglicher Angreifer konkret benutzt sind enorm schwierig. Im Grunde wäre das Hellsehen.

3.) man kann abstrahieren und wird feststellen das bessere Angriffe die Eigenheiten der Menschen bei der Wahl der Passwörter ausnutzen. Dh. ein Angreifer wird nicht alle 256 Zeichen des ASCII Alphabetes benutzen sondern im Idealfall die Buchstaben gewichtet nach ihrer Häufigkeit in unserer Sprache.

Berachtet man nun alle Fakten was wir überhaupt tuen können dann bleibt im Grunde nur das was ich in meiner Funktion versucht habe zu bewerkstelligen.

Nun, meine Funktion bewertet nicht auf "faire" Art & Weise alle möglichen Passwörter, das ist vom Rainhard Kern schon korrekt herausgearbeitet worden. Denn ein Passwort aus lauter Nullen ist ebenso wahrscheinlich wenn man es zufällig erzeugt und könnte ebenso gut bewertet werden. Meine Funktion hat nur die Aufgabe ein Passwort besser zu bewerten wenn es komplexer ist als andere. Und das heist letzendlich: möglichst lang, möglichst viele verschiedene Buchstaben, möglichst wenig wiederholende Muster (und "ccc" ist ein Muster, 3x "c"), möglichst wenig Entropie und damit wenig Redundanzen.

Das heist das eine Passwort-Bewertungs-Funktion immer wie ein Sieb arbeitet und aus der Menge aller Passwörter diejenigen auswählt bei denen wir die Möglichkeit haben zu beweisen das sie gut sein müssen im Rahmen unserer gewählten Bewertungsfunktion. Dabei müssen je nach Bewertungsfunktion, quasi Kollateralschäden entstehen und ansonsten gute Passwörter als schlechter bewertet werden.

Mehr können wir nicht bewerten und macht auch keinen Sinn.

Schlußendlich gibt es bei zb. einer 128 Bit Verschlüsselung 2^128 verschiede starke 128 Bit lange Passwörter. Alle sollten sie identich stark sein, wenn die Verschlüsselung gut ist. Insofern hat Rainhard bis hier auch Recht. Das was nun verschiedene Passwörter so schlecht macht sind die ausgefeilten Angriffe auf verschiedene Passwörter. Fast alle diese Angriffe basieren auf der Annahme das von Menchen ausgedachte und eingebbare Passwörter benutzt wurden. Ergo: die Angriffe schränken als erstes den Suchraum ein indem sie den benutzen Symbolraum einschränken. Statt einen Suchraum von 256 ASCII Zeichen pro Symbol nutzen sie zb. nur das Alphabet und die Ziffern als eingeschränkten Suchraum. Zudem sortieren sie diese Menge noch nach Häufigkeiten der Buchstaben, also zb. "e" wird im Angriff häufiger und früher verwendet als "ß" oder "z" usw.
Weiter führend wird dieser Angriff in den höherwertigen Symbol Raum "Wörter" überführt, wo wir dann bei der Wörterbuchattacke angekommen wären.

Der Angreifer macht also nichts anderes als die Entropie unserer Sprache auszunutzen um seinen Suchraum effizienter zu gestalten. Sowohl auf Symbolebene wie auch Wortebene nutzt er diesen Trick.
Die Aufgabe eines "Gegners" des Hackers ist es also ebenfalls die Entropie zu benutzen um möglichst schwer erratbare Passwörter als besser zu bewerten.

Eine Passwort-Bewertungs-Funktion wird also immer nur die Komplexität eines Passwortes bewerten können. Und das heist: maximale Länge + maximale Ausnutzung des Symbolraumes + maximale Varianz der ausgewählten Symbole aus dem Symbolraum (keine Wiederholungen).

Ich stimme aber mit Rainhard nicht übereine wenn er behauptet das man Passwörter nicht bewerten kann. Das geht sehr wohl und muß auch gehen da ansonsten wiederum die Kryptographie basiernd auf Passwörtern sinnfällig würde. Die Frage ist welche Bewertung kann man praktisch programmieren und macht noch einen Sinn. Und da habe ich von Anfang an betont das man nie die Qualität eines Passwortes bewerten kann wenn man als Angriff eine Wörterbuchattacke mit unbekannten Wörterbuch annimmt. Insofern verstehe ich auch nicht warum immer wieder dahingehend argumentiert wird.
Allerdings kann man davon ausgehen das ein Angreifer in seinem Wörterbuch die häufigst benutzten Passwörter abgespeichert hat, logisch oder ? Und da diese Passwörter bisher noch von Menschen ausgedacht wurden und damit sehr nahe an unserer Sprache liegen, ist die Entropie als eine Funktion der Bewertung von Redundanz in unserer Sprache sehr wohl eine brauchbare Funktion um Passwörter zu qualifizieren.

Nun kommen wir wieder zum Anfang der Geschichte: als ich sagte das es am Wichtigsten ist das man weiß was man tut und warum man es tut. Meine Funktion habe ich exakt aus all diesen Erwägungen heraus gezielt so konstruiert wie sie jetzt ist. Nicht weil ich gefühlsmäßig meinte das ist richtig und jenes wäre unlogisch oder so.

Gruß Hagen

[Satty67]

Es ist schon richtig, das ich mich hier viel zu stark auf mein Gefühl, statt auf mathematisch belegbare Methoden verlassen habe. Zumindest was das Kernproblem "ccc" angeht.

Dein letzter Post ist da für auch nochmal deutlicher, was das Problem bei einer Bewertung angeht. Auch das ich bestimmte Angriffsmethoden vorausgesetzt habe und andere quasi ausgeschlossen (z.B. Verwendung eines sehr stark eingeschränkten Zeichensatzes), war wohl nicht zielführend.

Satttttttty fällt quasi aus der Bewertung, weil es zwar sicherer sein könnte als Satty, es aber nicht belegbar ist bzw. nicht alle belegbaren Sicherheitsmerkmale erfüllt.

***

Im Eingabe-Dialog für das Masterpasswort will ich nicht auf eine Bewertung verzichten. Ich müsste dort halt dem Anwender klarmachen, das ich nicht ungenau bewerte (wie es für Unwissende fälschlichweise aussieht), sondern nur nach belegbaren Kriterien bewerte (wenn ich PassphraseQuality verwende).

[hathor]

Zitat:

Zitat von negaH (Beitrag 1052663)

...Beim Symbolraum "abc" benötigt er aber schon 6 Versuche...

Gruß Hagen

27.

Den Rest habe ich nicht gelesen!

[hathor]

Info:
http://www.passwordmeter.com/

[Sir Rufo]

Zitat:

Zitat von hathor (Beitrag 1096772)

Info:
http://www.passwordmeter.com/

Schau mal in Post #34 und #36 ;)

[hathor]

Falls da IRGENDETWAS von dem Link steht:
Die SUFU hat es nicht gefunden!!!

[Shark99]

Zitat:

Zitat von Sir Rufo (Beitrag 1052507)

Ich habe das mal übersetzt

Delphi-Quellcode:

unit uPassStrength;

interface

type
  TPassphraseStrength = ( psVeryWeak, psWeak, psGood, psStrong, psVeryStrong );

  TPassphraseInfo = record
    Length : integer;
    AlphaUC : integer;
    AlphaLC : integer;
    Number : integer;
    Symbol : integer;
    MidChar : integer;
    Requirements : integer;
    AlphasOnly : integer;
    NumbersOnly : integer;
    UnqChar : integer;
    RepChar : integer;
    RepInc : Extended;
    ConsecAlphaUC : integer;
    ConsecAlphaLC : integer;
    ConsecNumber : integer;
    ConsecSymbol : integer;
    ConsecCharType : integer;
    SeqAlpha : integer;
    SeqNumber : integer;
    SeqSymbol : integer;
    SeqChar : integer;
    ReqChar : integer;
    MultConsecCharType : integer;
    function Score : integer;
    function ScoreStr : string;
    function Strength : TPassphraseStrength;
    procedure Clear;
  end;

procedure PassphraseAnalyseEx( const Password : string; out PassphraseInfo : TPassphraseInfo );
function PassphraseScore( const Password : string ) : integer;
function PassphraseStrength( const Password : string ) : TPassphraseStrength;

implementation

uses
  SysUtils, Math;

function StringReverse( const Str : string ) : string;
  var
    idx : integer;
  begin
    Result := '';
    for idx := 1 to Length( Str ) do
      Result := Str[ idx ] + Result;
  end;

procedure PassphraseAnalyseEx( const Password : string; out PassphraseInfo : TPassphraseInfo );
  const
    AlphasUC = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ';
    AlphasLC = 'abcdefghijklmnopqrstuvwxyz';
    Alphas = 'abcdefghijklmnopqrstuvwxyz';
    Numerics = '0123456789';
    Symbols = ')!@#$%^&*()';
    MinLength = 8;
    MinAlphaUC = 1;
    MinAlphaLC = 1;
    MinNumber = 1;
    MinSymbol = 1;
  var
    a : integer;
    TmpAlphaUC, TmpAlphaLC, TmpNumber, TmpSymbol : integer;
    b : integer;
    CharExists : Boolean;
    S : integer;
    Fwd, Rev : string;
    pwd : string;
  begin
    // Initialisierung
    TmpAlphaUC := 0;
    TmpAlphaLC := 0;
    TmpNumber := 0;
    TmpSymbol := 0;

    pwd := StringReplace( Password, ' ', '', [ rfReplaceAll ] );

    PassphraseInfo.Clear;
    PassphraseInfo.Length := Length( pwd );

    // Durchsuche das Passwort nach Symbolen, Nummern, Groß- und Kleinschreibung
    for a := 1 to Length( pwd ) do
      begin

        // Großbuchstaben
        if Pos( pwd[ a ], AlphasUC ) >= 1 then
          begin
            if ( TmpAlphaUC > 0 ) then
              begin
                if ( TmpAlphaUC + 1 = a ) then
                  begin
                    inc( PassphraseInfo.ConsecAlphaUC );
                    inc( PassphraseInfo.ConsecCharType );
                  end;
              end;
            TmpAlphaUC := a;
            inc( PassphraseInfo.AlphaUC );
          end

          // Kleinbuchstaben

        else if Pos( pwd[ a ], AlphasLC ) >= 1 then
          begin
            if ( TmpAlphaLC > 0 ) then
              begin
                if ( TmpAlphaLC + 1 = a ) then
                  begin
                    inc( PassphraseInfo.ConsecAlphaLC );
                    inc( PassphraseInfo.ConsecCharType );
                  end;
              end;
            TmpAlphaLC := a;
            inc( PassphraseInfo.AlphaLC );
          end

          // Ziffern

        else if Pos( pwd[ a ], Numerics ) >= 1 then
          begin
            if ( a > 1 ) and ( a < Length( pwd ) ) then
              inc( PassphraseInfo.MidChar );
            if ( TmpNumber > 0 ) then
              begin
                if ( TmpNumber + 1 = a ) then
                  begin
                    inc( PassphraseInfo.ConsecNumber );
                    inc( PassphraseInfo.ConsecCharType );
                  end;
              end;
            TmpNumber := a;
            inc( PassphraseInfo.Number );
          end

          // Symbole

        else if Pos( pwd[ a ], AlphasLC + AlphasUC + Numerics ) < 1 then
          begin
            if ( a > 1 ) and ( a < Length( pwd ) ) then
              inc( PassphraseInfo.MidChar );
            if ( TmpSymbol > 0 ) then
              begin
                if ( TmpSymbol + 1 = a ) then
                  begin
                    inc( PassphraseInfo.ConsecSymbol );
                    inc( PassphraseInfo.ConsecCharType );
                  end;
              end;
            TmpSymbol := a;
            inc( PassphraseInfo.Symbol );
          end;

        // Doppelte Zeichen prüfen
        CharExists := False;
        for b := 1 to Length( pwd ) do
          if ( a <> b ) and ( pwd[ a ] = pwd[ b ] ) then
            begin
              CharExists := true;
              PassphraseInfo.RepInc := PassphraseInfo.RepInc + ( Length( pwd ) / Abs( b - a ) );
            end;
        if CharExists then
          begin
            inc( PassphraseInfo.RepChar );
            PassphraseInfo.UnqChar := Length( pwd ) - PassphraseInfo.RepChar;
            if PassphraseInfo.UnqChar <> 0 then
              PassphraseInfo.RepInc := Ceil( PassphraseInfo.RepInc / PassphraseInfo.UnqChar )
            else
              PassphraseInfo.RepInc := Ceil( PassphraseInfo.RepInc );
          end;
      end; // for a := 1 to Length( pwd ) do

    for S := 1 to Length( Alphas ) - 2 do
      begin
        Fwd := Copy( Alphas, S, 3 );
        Rev := StringReverse( Fwd );
        if ( Pos( Fwd, LowerCase( pwd ) ) >= 1 ) or ( Pos( Rev, LowerCase( pwd ) ) >= 1 ) then
          begin
            inc( PassphraseInfo.SeqAlpha );
            inc( PassphraseInfo.SeqChar );
          end;
      end;

    for S := 1 to Length( Numerics ) - 2 do
      begin
        Fwd := Copy( Numerics, S, 3 );
        Rev := StringReverse( Fwd );
        if ( Pos( Fwd, LowerCase( pwd ) ) >= 1 ) or ( Pos( Rev, LowerCase( pwd ) ) >= 1 ) then
          begin
            inc( PassphraseInfo.SeqNumber );
            inc( PassphraseInfo.SeqChar );
          end;
      end;

    for S := 1 to Length( Symbols ) - 2 do
      begin
        Fwd := Copy( Symbols, S, 3 );
        Rev := StringReverse( Fwd );
        if ( Pos( Fwd, LowerCase( pwd ) ) >= 1 ) or ( Pos( Rev, LowerCase( pwd ) ) >= 1 ) then
          begin
            inc( PassphraseInfo.SeqSymbol );
            inc( PassphraseInfo.SeqChar );
          end;
      end;

    if ( PassphraseInfo.AlphaLC + PassphraseInfo.AlphaUC > 0 ) and ( PassphraseInfo.Symbol = 0 ) and
      ( PassphraseInfo.Number = 0 ) then
      PassphraseInfo.AlphasOnly := Length( pwd );

    if ( PassphraseInfo.AlphaLC + PassphraseInfo.AlphaUC = 0 ) and ( PassphraseInfo.Symbol = 0 ) and
      ( PassphraseInfo.Number > 0 ) then
      PassphraseInfo.NumbersOnly := Length( pwd );

    if ( PassphraseInfo.Length > 0 ) and ( PassphraseInfo.Length >= MinLength ) then
      inc( PassphraseInfo.ReqChar );
    if ( PassphraseInfo.AlphaUC > 0 ) and ( PassphraseInfo.AlphaUC >= MinAlphaUC ) then
      inc( PassphraseInfo.ReqChar );
    if ( PassphraseInfo.AlphaLC > 0 ) and ( PassphraseInfo.AlphaLC >= MinAlphaLC ) then
      inc( PassphraseInfo.ReqChar );
    if ( PassphraseInfo.Number > 0 ) and ( PassphraseInfo.Number >= MinNumber ) then
      inc( PassphraseInfo.ReqChar );
    if ( PassphraseInfo.Symbol > 0 ) and ( PassphraseInfo.Symbol >= MinSymbol ) then
      inc( PassphraseInfo.ReqChar );

    PassphraseInfo.Requirements := PassphraseInfo.ReqChar;
  end;

function PassphraseScore( const Password : string ) : integer;
  var
    pi : TPassphraseInfo;
  begin
    PassphraseAnalyseEx( Password, pi );
    Result := pi.Score;
  end;

function PassphraseStrength( const Password : string ) : TPassphraseStrength;
  var
    pi : TPassphraseInfo;
  begin
    PassphraseAnalyseEx( Password, pi );
    Result := pi.Strength;
  end;

{ TPassphraseInfo }

procedure TPassphraseInfo.Clear;
  begin
    Length := 0;
    AlphaUC := 0;
    AlphaLC := 0;
    Number := 0;
    Symbol := 0;
    MidChar := 0;
    Requirements := 0;
    AlphasOnly := 0;
    NumbersOnly := 0;
    UnqChar := 0;
    RepChar := 0;
    RepInc := 0;
    ConsecAlphaUC := 0;
    ConsecAlphaLC := 0;
    ConsecNumber := 0;
    ConsecSymbol := 0;
    ConsecCharType := 0;
    SeqAlpha := 0;
    SeqNumber := 0;
    SeqSymbol := 0;
    SeqChar := 0;
    ReqChar := 0;
    MultConsecCharType := 0;
  end;

function TPassphraseInfo.Score : integer;
  const
    MultLength = 4;
    MultRepChar = 1;
    MultMidChar = 2;
    MultRequirements = 2;
    MultConsecAlphaUC = 2;
    MultConsecAlphaLC = 2;
    MultConsecNumber = 2;
    MultConsecCharType = 0;
    MultConsecSymbol = 1;
    MultAlphaUC = 2;
    MultAlphaLC = 2;
    MultSeqAlpha = 3;
    MultSeqNumber = 3;
    MultSeqSymbol = 3;
    MultNumber = 4;
    MultSymbol = 6;
  begin
    Result := 0;
    // Additions
    Result := Result + Length * MultLength;
    if ( AlphaUC > 0 ) and ( AlphaUC < Length ) then
      Result := Result + ( Length - AlphaUC ) * MultAlphaUC;
    if ( AlphaLC > 0 ) and ( AlphaLC < Length ) then
      Result := Result + ( Length - AlphaLC ) * MultAlphaLC;
    if ( Number > 0 ) and ( Number < Length ) then
      Result := Result + Number * MultNumber;
    Result := Result + Symbol * MultSymbol;
    Result := Result + MidChar * MultMidChar;
    if Requirements > 3 then
      Result := Result + Requirements * MultRequirements;
    // Deducations
    Result := Result - AlphasOnly;
    Result := Result - NumbersOnly;
    Result := Result - Trunc( RepInc );
    Result := Result - ConsecAlphaUC * MultConsecAlphaUC;
    Result := Result - ConsecAlphaLC * MultConsecAlphaLC;
    Result := Result - ConsecNumber * MultConsecNumber;
    Result := Result - SeqAlpha * MultSeqAlpha;
    Result := Result - SeqNumber * MultSeqNumber;
    Result := Result - SeqSymbol * MultSeqSymbol;

    if Result > 100 then
      Result := 100
    else if Result < 0 then
      Result := 0;
  end;

function TPassphraseInfo.ScoreStr : string;
  begin
    case Strength of
      psVeryWeak :
        Result := 'sehr schwach';
      psWeak :
        Result := 'schwach';
      psGood :
        Result := 'gut';
      psStrong :
        Result := 'stark';
      psVeryStrong :
        Result := 'sehr stark';
    end;
  end;

function TPassphraseInfo.Strength : TPassphraseStrength;
  var
    sc : integer;
  begin
    sc := Score;
    if sc >= 80 then
      Result := psVeryStrong
    else if sc >= 60 then
      Result := psStrong
    else if sc >= 40 then
      Result := psGood
    else if sc >= 20 then
      Result := psWeak
    else
      Result := psVeryWeak;
  end;

end.

Sorry, dass ich einen alten Thread herauskrame, aber ich habe den Code eben eingebaut und dabei ist mir was aufgefallen.

azxopqfgby hat eine Passwordstärke von 9%
. hat eine Passwordstärke von 10%

Der zweite Wert ist schlichtwert absurd.