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

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

[Reinhard Kern]

Hallo,

es ist zwar schon alles gesagt, wenn auch noch nicht von allen im Forum, aber noch eine kleine Frage zur Ergänzung:

wie stark ist das Passwort "Cwmdauddwr" ?

Auflösung: das ist ein Vorort von Rhayader in Wales, google liefert 44000 Treffer. Die Passwortstärke sollte also in der gegend von Null liegen.

Was mich auf die Idee bringt, ein mögliches Passwort zu googlen und den Kehrwert der Treffer zu verwenden.

Gruss Reinhard

[hathor]

Cwmdauddwr

21,8%

[Satty67]

...und bei PassphraseQuality? und bei der verfeinerten Funktion in TPasswortCheck?

Ich erspare mir alle genannten Beispiele mit den Alternativen zu vergleichen. Wer ernsthaft vergleichen will, kann es selber machen. Wie gesagt, eine perfekte Funktion kann es nicht geben, zuviele Fallen.

Hier die entgültige Methode, wie sie im Forum in TPasswortCheck vorgestellt wurde. (Nur schnell wieder aus der Komponente rausgeschnippelt, kein Schönheitspreis erwartet )

Delphi-Quellcode:

unit UPasswordCheckFunktion;

interface

function GetPasswordStrength(Password: String; ForceEntropy : Boolean = false): Extended;

implementation

uses
  SysUtils, math;

function RemoveRepetitions(const AString : string): String;
var
  i : Integer;
begin
  Result := AString;
  i := 2;
  while i <= Length(Result) do
  begin
    if Result[i] = Result[i-1] then
      Delete(Result, i, 1)
    else
      inc(i);
  end;
end;

function RemoveDateSeparator(const AString : string): String;
var
  i : Integer;
  dt : TDateTime;
begin
  i := Length(AString);
  if (i > 0) and (AString[i] = DateSeparator) then
    Result := Copy(AString, 1, i-1)
  else
    Result := AString;

  if TryStrToDate(Result, dt) then
    Result := StringReplace(AString, DateSeparator, '', [rfReplaceAll]);
end;

function GetPasswordStrength(Password: String; ForceEntropy : Boolean = false): Extended;
var
  FLowerMultiplicator   : Extended;
  FUpperMultiplicator   : Extended;
  FNumericMultiplicator : Extended;
  FSignMultiplicator    : Extended;
  FDiffCharsMaxMulti    : Extended;
  FLengthMultiplicator  : Extended;

  FMinPasswordLength    : Integer;
  FMaxPasswordLength    : Integer;

  procedure InitPasswordCheck(ForceEntropie : Boolean);
  begin
    FLowerMultiplicator   := 19;
    FUpperMultiplicator   := 21;
    FNumericMultiplicator := 15;
    FSignMultiplicator    := 25;
    FDiffCharsMaxMulti    := 100;
    FLengthMultiplicator  := 20;

    FMinPasswordLength    := 4;
    FMaxPasswordLength    := 32;

    if ForceEntropie then
      FDiffCharsMaxMulti := FDiffCharsMaxMulti * 10;
  end;

  function LengthMul(const CurrentLength, MaxLength : Integer): Extended;
  begin
    if CurrentLength > MaxLength then
      Result := Math.Log2(MaxLength) * Math.Log2(MaxLength)
    else
      Result := Math.Log2(CurrentLength) * Math.Log2(CurrentLength);

    Result := Result * FLengthMultiplicator;
  end;

  function CalculateEntropie(CleanPWLength, DiffCharsCount : Integer;
                  LowerMul, UpperMul, NumericMul, SignMul: Extended):Extended;
  begin
    Result := (DiffCharsCount * FDiffCharsMaxMulti) / CleanPWLength;
    if (NumericMul + SignMul) = 0 then
      Result := Result + ((LowerMul + UpperMul) / 2)
    else
      Result := Result + LowerMul + UpperMul + NumericMul + SignMul;
  end;

  function GetBestResult: Extended;
  begin
    Result := CalculateEntropie(1, 1, FLowerMultiplicator, FUpperMultiplicator,
                                FNumericMultiplicator, FSignMultiplicator);
    Result := Result * LengthMul(FMaxPasswordLength, FMaxPasswordLength);
  end;

var
  i, CleanPWLength : Integer;
  CleanPassword,
  DiffChars : String;
  EntropieMul,
  LowerMul, UpperMul,
  NumericMul, SignMul : Extended;
begin
  Result     := 0;

  LowerMul   := 0;
  UpperMul   := 0;
  NumericMul := 0;
  SignMul    := 0;

  InitPasswordCheck(ForceEntropy);
  CleanPassword := Trim(Password);
  CleanPassword := RemoveDateSeparator(CleanPassword);
  CleanPassword := RemoveRepetitions(CleanPassword);

  CleanPWLength := Length(CleanPassword);
  if (CleanPWLength >= FMinPasswordLength) then
  begin

    for i := 1 to Length(CleanPassword) do
    begin
      case CleanPassword[i] of
        'a'..'z', ' ' : LowerMul   := FLowerMultiplicator;
        'A'..'Z' : UpperMul   := FUpperMultiplicator;
        '0'..'9' : NumericMul := FNumericMultiplicator;
      else
        SignMul := FSignMultiplicator;
      end;

      if Pos(CleanPassword[i], DiffChars) < 1 then
        DiffChars := DiffChars + CleanPassword[i];
    end;

    EntropieMul := CalculateEntropie(CleanPWLength, Length(DiffChars),
                                     LowerMul, UpperMul, NumericMul, SignMul);

    Result := EntropieMul * LengthMul(CleanPWLength, FMaxPasswordlength);
    Result := Result / GetBestResult;
  end;
end;

end.