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

[cookie22]

[QUOTE=Reinhard Kern;1052518]

Zitat von BUG:

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

[hathor]

Zitat von Reinhard Kern:

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

[mleyen]

Zitat von Satty67:

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.