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

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

[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 von negaH:

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?

[Satty67]

(Sorry für Doppelpost, aber mit dem Code im Post oben, wäre das arg unübersichtlich geworden)

Zitat von Reinhard Kern:

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

Wie gesagt, ich hab' akzeptiert das es ein riesen Projekt werden würde und eine ideale Prüfmethode fast unmöglich. Mein Ziel, wenigstens nicht unlogisch "auszusehen" habe ich aber mit der letzten Version annähernd erreicht.

Die Idee mit Google ist übrigens richtig gut, denke da werden auch verschiedene Sprachen gut abgedeckt. €: Wäre es ein Passwort-Generator, wäre das eine gute Methode, um das zufällig erzeugte Passwort nochmal zu checken.

[BUG]

Zitat von Satty67:

Die Idee mit Google ist übrigens richtig gut, denke da werden auch verschiedene Sprachen gut abgedeckt. €: Wäre es ein Passwort-Generator, wäre das eine gute Methode, um das zufällig erzeugte Passwort nochmal zu checken.

Ein Passwort im Klartext durchs Internet an Google zu schicken ist eine gute Idee?