Pw sicherheit anzeigen

[sakura]

Zitat von Headi:

Kann es sein dass der code nicht auf die länge achtet??

Doch, tut er. Suche mal nach der Zeile

Delphi-Quellcode:

const
  GoodLength = 10.0; // good length of Passphrases

......

[Avax2k]

hier der Link zur MD5-Unit

http://www.delphipraxis.net/internal...?p=65677#65677

allerdings ist ein kleiner Fehler in der Unit..und zwar oben bei den functions fehlt folgende Zeile:
function MD5_HashForString(aValue: String): TMD5Digest; sonst bekommt man einen Fehler

[negaH]

Bei meiner Funktion muß man immer eines bedenken, nämlich WAS gilt heutzutage als sicheres Passwort ?

Die Antwort ist:

ein mindestens 128 Bit langes Passwort das statistisch aus Zufallsähnlichen Daten besteht.

Gehen wir aber mal vom Menschlichem Input aus dann ergeben sich mehrere Probleme:

1.) der Mensch gibt sinnvolle Wörter ein
2.) der Mensch beschränkt sich auf durchschnittlich nur 36 Zeichen aus einem Zeichensatz von 256 möglichen Zeichen. Die Entropie der Passwörter ist also nur 3.6 statt 8.
3.) der Mensch nimmt sehr gerne Passwörter die identisch mit dem Tastaturlayout sind,zb. 1234567890 oder qwertz

Das heist nun der Algorithmus muß die Passwörter clever gewichten.

Ein Passwort wie P$[ mit 3 Zeichen muß aber immer schlechter als ein Passwort wir "aaaa" mit 4 Zeichen bewertet werden. Denn eine Brute Force Attacke beginnt meistens mit 1 Zeichen, a 256 Möglichkeiten, dann 2 Zeichen mit 256 * 256 Möglichkeiten dann 3 mit 256*256*256 und eben 4 mit 256*256*256*256. Ergo: das längere Passwort muß egal wie es aussieht sicherer sein.

Nun zur Entropie: wenn wir ein Passwort haben wollen das so sicher ist wie ein 128 Bit langes Passwort das per quasi zufällig erzeugt wurde aber aus deutschen/englishen Wörtern besteht dann muß diese Passwort ca. 128 * 8 / 3.6 = 285 Bits = 36 Zeichen bestehen. Meine Funktion rechnet aber mit einem 10 Zeichen Passwort schon als ein gutes Passwort. Ergo: wenn die Funktion es wirklich richtig machen wollte dann würde sie fast alle menschlichen Passwörter als sehr miserabel einstufen müssen. Ich habe also die Funktion schon stark abgeschwächt.

Und nochwas: diese Funktion dient ausschließlich zur Qualifizierung eines menschlichen Passwortes. Bei einem quasi zufälligen Maschinenpasswort das mit einer Hash Funktion erzeugt wurde ist diese Funktion sinnlos.

Gruß Hagen

[Headi]

Zitat von negaH:

Bei meiner Funktion muß man immer eines bedenken, nämlich WAS gilt heutzutage als sicheres Passwort ?

Die Antwort ist:

ein mindestens 128 Bit langes Passwort das statistisch aus Zufallsähnlichen Daten besteht.

Gehen wir aber mal vom Menschlichem Input aus dann ergeben sich mehrere Probleme:

1.) der Mensch gibt sinnvolle Wörter ein
2.) der Mensch beschränkt sich auf durchschnittlich nur 36 Zeichen aus einem Zeichensatz von 256 möglichen Zeichen. Die Entropie der Passwörter ist also nur 3.6 statt 8.
3.) der Mensch nimmt sehr gerne Passwörter die identisch mit dem Tastaturlayout sind,zb. 1234567890 oder qwertz

Das heist nun der Algorithmus muß die Passwörter clever gewichten.

Ein Passwort wie P$[ mit 3 Zeichen muß aber immer schlechter als ein Passwort wir "aaaa" mit 4 Zeichen bewertet werden. Denn eine Brute Force Attacke beginnt meistens mit 1 Zeichen, a 256 Möglichkeiten, dann 2 Zeichen mit 256 * 256 Möglichkeiten dann 3 mit 256*256*256 und eben 4 mit 256*256*256*256. Ergo: das längere Passwort muß egal wie es aussieht sicherer sein.

Nun zur Entropie: wenn wir ein Passwort haben wollen das so sicher ist wie ein 128 Bit langes Passwort das per quasi zufällig erzeugt wurde aber aus deutschen/englishen Wörtern besteht dann muß diese Passwort ca. 128 * 8 / 3.6 = 285 Bits = 36 Zeichen bestehen. Meine Funktion rechnet aber mit einem 10 Zeichen Passwort schon als ein gutes Passwort. Ergo: wenn die Funktion es wirklich richtig machen wollte dann würde sie fast alle menschlichen Passwörter als sehr miserabel einstufen müssen. Ich habe also die Funktion schon stark abgeschwächt.

Und nochwas: diese Funktion dient ausschließlich zur Qualifizierung eines menschlichen Passwortes. Bei einem quasi zufälligen Maschinenpasswort das mit einer Hash Funktion erzeugt wurde ist diese Funktion sinnlos.

Gruß Hagen

vielen dank für die Aufklärung

Achja eine Frage habe ich noch, man hört immer so
von wegen ein passwort ist nur sicher, wenn es möglichst hoch verschlüsselt ist und so.
Was ist denn da der Unterschied zu einem normalen passwort?

Ich meine wenn ich mich hier auf dem Forum mit "wpo34vxç%ypv5kl*çu34" anmelde, denke ich ist das ziehmlich sicher
und ich habe da auch gar nichts verschlüsselt oder so.

Sind die verschlüsselten Passwörter einfach für Programme, die diese dann auch wieder entschlüsseln?


vielen dank schonmal

mfg headi

[negaH]

Verschlüsselt ist der falsche Begriff da er suggeriert das man es auch wieder "ent-schlüsseln" kann.

Um das reale Passwort, zb. "Test" zu schützen sollte man daraus quasi einen Sessionkey erzeugen. Dazu wird mit Hilfe einer Hash Funktion, einer "secure Oneway function", sichere Einweg-"verschlüsselung" aus dem "Test" ein binärer Wert erzeugt. Je nachdem welchen Algo man benutzt wird dieser binäre Wert dann immer 128 oder zb. 256 Bit groß sein. Man könnte das eher als "Prüfsumme" bezeichnen.

Wichtig an dieser Hash Funktion ist aber das man nur von A nach B rechnen kann und nicht mehr von B nach A, praktisch gesehen wohlgemerkt. Man kann also aus "Test" einen Hash erzeugen aber ausgehend von einem beliebigen Hash ist es fast unmöglich wieder "Test" zu berechnen.

Dies dient primär zum Schutz DEINES Passwortes. Denn ein Login zb. hier in der DP würde praktisch gesehen so aussehen:

Du erzeugst erstmal einen Zufallswert, sogenanter Salt. Dieser sollte ca. 128 Bit groß sein.
Du erzeugst aus dem Salt + Passwort mit einer Hashfunktion einen sogenannten Hash-Digest. Durch den Zufallssalt wird dieser Wert jedesmal anders aussehen.
Beides sendest du an den DP Server. Der DP-Server nimmt den Salt + das gespeicherte Passwort und erzeugt seinerseits diesen Hashdigest. Er vergleicht nun deinen errechneten Wert mit seinem. Wenn beide gleich sind dann ist sicher das Du das gleiche Passwort kennst wie das das auf dem DP Server gespeichert wurde.

Ein Angreifer der nun diesen Hash-Digest unterwegs abhört wird nun eben nicht dein Reales Passwort "Test" lesen können, da es quasi nur INDIREKT und sogar noch pseudozufällig in dem Hashdigest vorkommt. Mathematisch praktisch gesehen müsste dieser Angreifer den Salt abfangen und deinen Hashdigest. Dann fängt er an ALLE Kombinationen von Passwörtern durchzuprobieren solange bis er den gleichen Hashdigest erzeugt hat. Dies IST die EINZIGSTE Möglichkeit einen solchen Hashdigest zu knacken und nennt sich Brute Force Attacke, Durchprobieren! Aber jetzt kommt der klitzekleine und fiese Hacken den die Mathematiker eingebaut haben zum tragen. Denn dieser Hash-Digest ist 128 Bit groß und der Salt sollte ebenfalls 128 Bit groß sein. Damit haben die mathematiker die Kombinationsvielfalt so hoch gesetzt das es bis zur Implosion der Sonne dauern würde so einen Angriff praktisch durchzuführen.

Ergo: auf diesem Wege kann zb. ein Server überprüfen ob du ein Geheimnis kennst das er ebenfalls kennt und das ohne das man beim Lauschen an der Kommunikation irgendwelche brauchbaren Informationen kommt.
Es schützt also DICH und DEIN Passwort.

Hashfunktionen sind Algortihmen der Kryptographie, sehr richtig, sie sind aber eben keine "Ver-schlüsselungen" im wörtlichen Sinne, da sie eben Einweg sind.

Gruß Hagen

[Headi]

@ negaH: vielen dank jetzt habe ich das glaube kapiert


vielen dank auch nochmals allen anderen!

mfg headi