128 Bit Schlüssel erzeugen

[sp7]

Moin

Ich soll mit AES einen Text verschlüsseln. Dazu verwende ich einen 128bit Key. Dieser soll aus einem String (dem Passwort des Users) beliebiger Länge erzeugt werden.
Existiert dazu ein gängiger Algorithmus?

Beim Googeln hab ich folgendes gefunden:

1    // create a 16 byte key from passcode
2    byte[] kb = new byte[16];
3    for (int i = 0; i < kb.length; i++)
4      kb[i] = (byte) (i + 20);
5    byte[] pb = passcode.getBytes();
6    for (int ki = 0, pi = 0; pi < pb.length; pi++) {
7      kb[ki] += pb[pi];
8      ki = (ki + 1) % 16;
9    }

Ich verstehe auch, wie das Ding funktioniert. Was mir nicht klar ist, weshalb in Zeile 4 jedes Feld in kb mit (i + 20) initialisiert wird. Warum gerade 20?

Danke, sp7

[Elderan]

Moin

Existiert dazu ein gängiger Algorithmus?

Naja soschwer ist es auch nicht ;)
Es kommt immer auf die Key schedule des Algorithmus an.

Ich denke mal du programmierst für 32 Bit Plattformen, ich habe es wie folgt gelöst:

Key: abcdefghijklmnop (16 Byte = 128 Bit)

Key in 4 Byte (32 Bit) unterteilen:
Key: abcd efgh ijkl mnop

Dann die Strings in Integer umrechnen:
a<<24+b<<16+c<<8+d
Dabei wird a,b,c,d durch deren ASCII Code ersetzt, also
97<<24+98<<16+99<<8+100.

Jetzt hast du 4 mal 32 Bit Integer. Anstatt einen String kannst du den User natürlich auch 4 mal einen 32 Bit Integer (als hexadezimal) eingeben lasse, dann enfällt das.

Also Schleife in C sieht das wie folgt aus:
for(i=0;i<4;i++)
     {
     k[i] = (key[i*4]<<24)+(key[i*4+1]<<16)+(key[i*4+2]<<8)+(key[i*4+3]);
     }
Dabei ist key[] das String-Array, und k[] ist das 32 Bit Integer.

So der nächste Schritt ist bei AES w[0],w[1],w[2],w[3] die vier 32 Bit Werte zuzuweisen.

Komplett in PHP sieht es so aus:

  
function key($string) {  
$w = array();  
$w = str2long($string); //$key in 4 in 32 Bit Werte aufteilen  
$w[0] = $key[0]; //Die ersten 4 $w Elemente sind die 4x32 Bit werden  
$w[1] = $key[1];  
$w[2] = $key[2];  
$w[3] = $key[3];  
  
for($i=4;$i<44;$i++)  
  {  
  $temp = $w[$i-1];  
  
  if($i%4==0) //Vielfaches von 4  
     {  
     //$temp in Bytes zerlegen  
     $t2 = array();  
     $t2[3] = $temp & 0xFF;  
     $t2[2] = $temp>>8 & 0xFF;  
     $t2[1] = $temp>>16 & 0xFF;  
     $t2[0] = $temp>>24 & 0xFF;  
  
     $t2 = array($t2[1],$t2[2],$t2[3],$t2[0]); //RotWord: Rotat the Bytes/Array-Elements left  
     $t2 = SubWord($t2,0); //Funktion  
     $t2[0] ^= Rcon($i>>2); //Rcon ist eine Funktion  
  
     $temp = $t2[3]+($t2[2]<<8)+($t2[1]<<16)+($t2[0]<<24);  
     }  
  
   $w[$i] = $w[$i-4]^$temp;  
   $j++;  
   }  
  
return $w; //$w wird als Key für die einzelnen Runden benutzt.  
}  

(Dieser Funktion wurde mit offizielle&inoffizielle Testvektor positiv getestet)

MFG Elderan

[Sven Rautenberg]

Moin!

Ich denke mal du programmierst für 32 Bit Plattformen, ich habe es wie folgt gelöst:

Key: abcdefghijklmnop (16 Byte = 128 Bit)

Das Problem ist nur: Wie kriegt man den Benutzer dazu, sich ein exakt 16 Zeichen langes Passwort auszudenken, welches man hier verwenden kann? :)

- Sven Rautenberg

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

Das Problem ist nur: Wie kriegt man den Benutzer dazu, sich ein exakt 16 Zeichen langes Passwort auszudenken, welches man hier verwenden kann? :)

So:
Als Passwort müssen Sie eine 16 Zeichen lange Zeichenkette eingeben.

Oder man macht halt sowas:
$passwort = substr(sha1($_GET['passwort']), 0, 16);

Ich kann aber nicht beurteilen, wie sicher/unsicher das ist.

Gruß
Alexander Brock

[Elderan]

Hallo,

Oder man macht halt sowas:
$passwort = substr(sha1($_GET['passwort']), 0, 16);

Ich kann aber nicht beurteilen, wie sicher/unsicher das ist.

das ist deutlich unsicherer, den der SHA1 Hash besteht aus Hexadezimal, also nur 32 Zeichen anstatt 256 Zeichen.

Dadurch hätte man nur einen Schlüsselraum von: 32^16 = 1,2*10^24
Möglich wäre aber: 3,4*10^38
Also ist der Schlüsselraum um ca. 10^14 mal kleiner.

Also man kann es so machen

C:
for(i=0;i<4;i++)
     {
     k[i] = (key[(i*4)%lng]<<24)+(key[(i*4+1)%lng]<<16)+(key[(i*4+2)%lng]<<8)+(key[(i*4+3)%lng]);
     }

Dabei enthält lng die Länge des PWs.
Wenn es z.B. 7 Zeichen hat, dann würde der 128 Bit Key wie folgt berechnet:
0123 4560 1234 5601

Dabei ist die Zahl (0,1,2,3...) jeweils der x Buchstabe im Key, angefangen beim 0. (ersten) Buchstaben.

Oder man schickt den Key durch den MD5 Algorithmus, als Ausgabe erhält man einen 128 Bit Hash (als Hexadezimal).
Man _muss_ diese Ausgabe als Hexadezimal, und _nicht_ als String betrachten.

Oder noch ne Möglichkeit in PHP:
$key = str2long(substr(str_pad($key, 16, md5($key)),0,16));
str2long(); wandelt den Key in Long Zahlen um.
str_pad(); füllt den $key auf 16 Zeichen auf (mit dem MD5 Hash).
substr(); würde einen zulangen Key auf 16 Zeichen kürzen.

Grüße
Elderan

[Christoph Zurnieden]

Hi,

Oder man macht halt sowas:
$passwort = substr(sha1($_GET['passwort']), 0, 16);

Ich kann aber nicht beurteilen, wie sicher/unsicher das ist.
das ist deutlich unsicherer, den der SHA1 Hash besteht aus Hexadezimal, also nur 32 Zeichen anstatt 256 Zeichen.

"Äh, nein. Was Du meinst ist der menschenlesbare Ausdruck. SHA schmeißt 20 Bytes raus, wenn Du davon die ersten 16 benutzt ist das vollkommen in Ordnung und auch sicher denn die Bits im SHA-Hash sind gleichmäßig verteilt."

Soweit war ich schon, bis ich sicherheitshalber mal in die Doku zu SHA1() geschaut habe und mit bassem Erstaunen feststellen mußte, das diese Funktion aus wirklich unerfindlichen Gründen eine hexadezimale Zahl ausgibt. Was soll denn der Unsinn?
Naja, dann muß das eben so lauten:

$passwort = substr(pack("H*",sha1($_GET['passwort'])), 0, 16);

(ungetestet, kann Tipfehler und schlimmeres enthalten)

so short

Christoph Zurnieden

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

Soweit war ich schon, bis ich sicherheitshalber mal in die Doku zu SHA1() geschaut habe und mit bassem Erstaunen feststellen mußte, das diese Funktion aus wirklich unerfindlichen Gründen eine hexadezimale Zahl ausgibt. Was soll denn der Unsinn?
Naja, dann muß das eben so lauten:

$passwort = substr(pack("H*",sha1($_GET['passwort'])), 0, 16);

Ergänzung: Seit PHP 5.0.0 kann man das auch so schreiben:
$passwort = sha1($_GET['passwort'], true);

Gruß
Alexander Brock

[Elderan]

Hallo,

Soweit war ich schon, bis ich sicherheitshalber mal in die Doku zu SHA1() geschaut habe und mit bassem Erstaunen feststellen mußte, das diese Funktion aus wirklich unerfindlichen Gründen eine hexadezimale Zahl ausgibt. Was soll denn der Unsinn?

Es gibt Zeichen im ASCII Alphabet, die nicht Darstellbar sKästchen.
Da aber bei dem SHA1-Hash die Bits gleichverteilt sind, wäre die Wahrscheinlichkeit ein Steuerzeichen zu erhalten, genauso groß wie ein a oder b oder c.

Darum sind Ausgabe/Eingaben von solchen Algorithmen meistens Hexadezimal dargestellt, dann hat man damit keine Probleme.
Außerdem kann man den Hash dann auch sicher per Email übertragen, denn dort wird i.d.R. nur 7 Bit pro Zeichen benutzt.

Grüße
Elderan

[Christoph Zurnieden]

Hi,

Darum sind Ausgabe/Eingaben von solchen Algorithmen meistens Hexadezimal dargestellt, dann hat man damit keine Probleme.

Was für Probleme, die man nicht mit pack() lösen könnte? Das einzige Problem ist im Grunde nur die Darstellung des Hashes. Bis auf Dokumentationen und Debugging gibt es jedoch keinen Grund zur Ausgabe und damit zur Darstellung.

Nein, ich bin immer noch der festen Meinung, das es blanker Unsinn ist sha1() als Hexadezimalzahl zurückzugeben. Die PHP Entwickler scheinen es auch eingesehen zu haben, denn in PHP5 gibt es einen Schalter zur Rohausgabe.

Außerdem kann man den Hash dann auch sicher per Email übertragen, denn dort wird i.d.R. nur 7 Bit pro Zeichen benutzt.

Dafür wäre dann base64() die bessere Wahl, meinst Du nicht auch?

so short

Christoph Zurnieden

[Elderan]

Hallo,

Bis auf Dokumentationen und Debugging gibt es jedoch keinen Grund zur Ausgabe und damit zur Darstellung.

Bist du dir da sicher?!?

Also mal überlegen, wo man den MD5/SHA1 Hash benötigt, typische Anwendungsbeispiele sind:
-Hash von einer Datei, wurde diese geändert (Hash muss gespeichert&Ausgegeben werden)
Z.B. bei Dateien die zum Download angeboten werden. (Hexadezimal sinnvoll)

• Hash von einer Nachricht die man signieren möchte (Hash muss übertragen werden) (ink. Zertifikate)
  (Hexadezimal Sinnvoll)

• Hash als Key-Expansion (hier wäre String sinvoller).

Aber vorallem für PHP-Programmieren:
Passwort als Hash in der DB/Textdatei speichern. (Hexadezimal sinnvoll)

Das sind die primären Anwendungsgebiete eines Hashwertes. Würde man den Hash als String speichern, könnte es Verluste geben (Steuerzeichen).
Und meistens muss er auch ausgegeben werden, und zwar so dass ein Mensch ihn lesen kann, also ohne Steuerzeichen.
Also muss man ihn kodieren, da müsste man sich aber auf einen Kodierungstandard einigen.

Desweiteren hat die Berechnung eines MD5/SHA1 Hashes genau 4x32-Bit bzw. 5x32-Bit Integer Ausgaben, ist es sehr leicht, diese Zahlen als Hexadezimal darzustellen.
Diese 4/5 Ausgaben werden dann einfach aneinandergehängt, fertig ist der Hashwert..

Und hast du schon mal an die xxxxxxxxxxxxx Personen gedacht, die kein ASCII als Standard-Zeichensatz benutzen?
Auf japanisch ist das Byte 0x64 (100) bestimmt nicht wie beim ASCII ein: d.
Was ist wenn die erste 32 Bit Variable folgendes Wert enthält:
0x61626364

ASCII: abcd
Aber bei einem japanischem Zeichensatz??

Und da Hexadezimal Weltweit eindeutig ist, gibt es dort keine Verwechslungen.
So können Deutsche und Japaner ohne Probleme Hashwerte austauschen, ohne sich auf eine gemeinsame Kodierung einigen zu müssen.

Zusammengefasst: Nur zum Key-Crunching wäre es Sinvoller, würde die Funktion den Hash als String zurückgeben. Sonst ist der Hexadezimalwert sinnvoller.

Grüße
Elderan

[Christoph Zurnieden]

Hi,

Bis auf Dokumentationen und Debugging gibt es jedoch keinen Grund zur Ausgabe und damit zur Darstellung.
Bist du dir da sicher?!?

Ja, vollkommen.

Also mal überlegen, wo man den MD5/SHA1 Hash benötigt, typische Anwendungsbeispiele sind:
-Hash von einer Datei, wurde diese geändert (Hash muss gespeichert&Ausgegeben werden)

Dazu gibt es mehrere Methoden wobei eine Hexadezimalzahl nicht immer sinnvoll ist. Ausgegeben wird dabei übrigens auch nichts, was nachher menschenlesbar dargestellt werden muß.

BTW: MD5 sollte mittlerweile als gebrochen angesehen und zu kryptographischen Zwecken nicht mehr benutzt werden.

Z.B. bei Dateien die zum Download angeboten werden. (Hexadezimal sinnvoll)

s.o.

• Hash von einer Nachricht die man signieren möchte (Hash muss übertragen werden) (ink. Zertifikate)
  (Hexadezimal Sinnvoll)

s.o.

• Hash als Key-Expansion (hier wäre String sinvoller).

s.o.

Aber vorallem für PHP-Programmieren:
Passwort als Hash in der DB/Textdatei speichern. (Hexadezimal sinnvoll)

Da ist es völlig egal. Wenn es trotzdem Probleme bereitet ist eines der beteiligten Programme kaputt oder schlecht programmiert.

Das sind die primären Anwendungsgebiete eines Hashwertes. Würde man den Hash als String speichern, könnte es Verluste geben (Steuerzeichen).

Wo bitte sollte es Verluste geben? Nein, Unfähigkeit des Programmierers ist kein Grund.

Und meistens muss er auch ausgegeben werden, und zwar so dass ein Mensch ihn lesen kann, also ohne Steuerzeichen.

Ja, das ist wohl wahr und zwar in Dokus und Debuggingsessions. Sonst nirgends. Was soll auch ein Mensch damit sonst anfangen?

Also muss man ihn kodieren, da müsste man sich aber auf einen Kodierungstandard einigen.

Der Codierungsstandard ist einfach "roh". Will man etwas anderes haben kann man sich etwas anderes draus basteln.

Desweiteren hat die Berechnung eines MD5/SHA1 Hashes genau 4x32-Bit bzw. 5x32-Bit Integer Ausgaben, ist es sehr leicht, diese Zahlen als Hexadezimal darzustellen.

Oder auch in jeglicher anderen Darstellung. Das macht man ja nicht selber, das macht der Rechner. Das muß aber programmiert werden, deshalb ist es ideal, wenn man die Rohware zur Verfügung hat, da kann man besser mit Arbeiten.

Diese 4/5 Ausgaben werden dann einfach aneinandergehängt, fertig ist der Hashwert..

Der Hashwert ist schon vorher fertig, der muß nicht noch weiter bearbeitet werden.

Und hast du schon mal an die xxxxxxxxxxxxx Personen gedacht, die kein ASCII als Standard-Zeichensatz benutzen?

Was ist mit denen? Die können damit auch keine Hexadezimalen Zahlen darstellen, also wie kommst Du auf diese Leute?

Auf japanisch ist das Byte 0x64 (100) bestimmt nicht wie beim ASCII ein: d.

Doch, da ist es auch ein 'd'. Steht im Gegensatz zu meinem Satz oben? Nein, seit Unicode nicht mehr. Ob der Font den Buchstaben enthält ist natürlich unbekannt.

Was ist wenn die erste 32 Bit Variable folgendes Wert enthält:
0x61626364

ASCII: abcd

Das ist nicht sicher, das kannst Du so nicht behaupten. Das kann selbst bei ASCII auch "dcba" oder gar "badc" sein.

Aber bei einem japanischem Zeichensatz??

Keine Ahnung, müßte ich nachschauen (brauche dafür aber den genauen Zeichensatz. Ja, da gibt es wirklich mehrere). Sollte aber das gleiche bei rauskommen.

Und da Hexadezimal Weltweit eindeutig ist, gibt es dort keine Verwechslungen.

Eben sagtest Du noch, das sowas im japanischem Zeichensatz nicht geht, denn die für hexadezimale Darstellung nötigen ASCII-Zeichen "a,b,c,d,e,f" soll es da ja nicht geben.

So können Deutsche und Japaner ohne Probleme Hashwerte austauschen, ohne sich auf eine gemeinsame Kodierung einigen zu müssen.

Und was spricht jetzt gegen die Rohware? Nicht jede Programmiersprache/jedes Transportprotokoll ist derart unfähig mit sowas nicht umgehen zu können.

Zusammengefasst: Nur zum Key-Crunching wäre es Sinvoller, würde die Funktion den Hash als String zurückgeben. Sonst ist der Hexadezimalwert sinnvoller.

Ich kann immer noch nicht nachvollziehen, warum eine Hexadezimalzahl außer in seltenen und zudem nicht produktionsrelevanten Ausnahmen die ideale Lösung darstellen soll.

so short

Christoph Zurnieden

[Elderan]

Hallo,

BTW: MD5 sollte mittlerweile als gebrochen angesehen und zu kryptographischen Zwecken nicht mehr benutzt werden.

Dies ist teilweise Unfug. Was gebrochen wurde, ist die starke Kollisionsresistenz, diese besagt:
Es ist praltisch Unmöglich, zwei verschiedene Nachrichten mit dem gleichen Hashwert zu finden:
M != M' ; h(M) = h(M')
Die Nachrichten kann man frei wählen. Dieses wurde aber auch bei SHA1  gebrochen.
Dennoch ist es schwer, zwei _Sinnvolle_ Nachrichten mit dem gleichen Hashwert zu finden.

Die schwache Kollisionsresistenz ist aber weiterhin gegeben, diese besagt: Zu einer gegebenen Nachricht ist es schwer, ein zweite verschiedene mit dem gleichen Hashwert zu finden.
Wäre dies nicht vorhanden, hätte man ein Problem beim Speichern von Passwörtern.

Z.B. bei Dateien die zum Download angeboten werden. (Hexadezimal sinnvoll)

Wenn ich mir ein Programm herrunterlade (z.B. php), und schauen möchte ob dies fehlerfrei Übertragen wurde, dann geh ich auf die Homepage, da findet man oft soetwas:
md5: fb1aac107870f897d26563a9cc5053c0

Dann starte ich mein altes Dos Programm, gebe den Pfad zu Datei an, dies berechnet den Hashwert und gibt ihn als Hexadezimal aus. Per Auge überprüfe ich ob die Hashwerte identisch sind.

Angenommen auf der PHP Homepage wäre die Ausgabe als ASCII-String. Hmm nicht gut, denn der Browser kann keine Steuerzeichen ausgeben. Außerdem sehen manche Buchstaben unter DOS anders aus als die Ausgabe per Browser.
Also müsste man beide Ausgaben kodieren, was für den Programmierer wieder bedeutet, dass er die Koderiungsfunktion implementieren müsste.
Anstatt, wie es bisher ist, folgendes zu benutzen:
printf("%08x%08x%08x%08x",A,B,C,D);
Müsste dieser erst A,B,C,D kodieren. Benutzt man z.B. Base64, dort werden 3 Byte in 4 Byte "überführt". Allerdings besitzt jede Variable 4 Byte/32 Bit.
Und des weiteren hat man ein Problem, wenn das Programm z.B. Base32 benutzt, auf der PHP Homepage aber der Hashwert als Base64 angegeben wird.

Also das ist ein deutlicher Mehraufwand für Programmierer, außerdem wäre es dann Sinnvoll, wenn MD5 einen Kodierungstandard vorgibt, damit nicht jeder macht was er möchte.
Aber warum benutzt man dann nicht gleich Hexadezimal?

Da ist es völlig egal. Wenn es trotzdem Probleme bereitet ist eines der beteiligten Programme kaputt oder schlecht programmiert.

Wenn man z.B. eine .exe Datei im Editor/Notepad öffnet, dort einen Buchstaben einfügt und diesen wieder löscht => speichern, so wird das Programm aufgrund der Steuerzeichen nicht mehr funktionieren.
Also könnte man z.B. eine Passwortdatei nicht per Notepad bearbeiten.  Und wenn ich per phpMyAdmin den Datensatz anschaue, dann müssen im Formular auch steuerzeichen dargestellt werden, was zu Problemen führt.
Lösung => Kodierung (warum kein Hexadezimal)

Wo bitte sollte es Verluste geben? Nein, Unfähigkeit des Programmierers ist kein Grund.

Siehe .exe Beispiel.

Ja, das ist wohl wahr und zwar in Dokus und Debuggingsessions. Sonst nirgends. Was soll auch ein Mensch damit sonst anfangen?

Ihn vergleichen? Ihn evt. selber erstellen? Wenn man ein AdminCP schützen möchte, so überprüft man oft:
if(md5($pw)) == "fb1aac107870f897d26563a9cc5053c0");

Oder auch in jeglicher anderen Darstellung. Das macht man ja nicht selber, das macht der Rechner. Das muß aber programmiert werden, deshalb ist es ideal, wenn man die Rohware zur Verfügung hat, da kann man besser mit Arbeiten.

Das muss aber alles, evt. Umständlich programmiert werden. Sofern man noch andere Sprachen als PHP kennt, weiß man wie dämlich es ist, verschiedene String Arrays in Base64 zu kodieren, denn dort muss man immer ein vielfaches von 3 Suchen, was nicht immer leicht möglich ist.
Außerdem kann man den Hashwert als Hexadezimal wieder sehr leicht in Integer überführen:
fb1aac107870f897d26563a9cc5053c0
fb1aac10 7870f897 d26563a9 cc5053c0
Und auf Basis dieser Hexadezimal Darstellung kann man dann wieder sehr leicht alle andere Formate erhalten.

Diese 4/5 Ausgaben werden dann einfach aneinandergehängt, fertig ist der Hashwert..

Der Hashwert ist schon vorher fertig, der muß nicht noch weiter bearbeitet werden.

Hast du schonmal den MD5 Algorithmus _selbst_ programmiert?
Der return in PHP sieht wie folgt aus:
return hex($a).hex($b).hex($c).hex($d);
hex(); wandelt dabei Integer in Hexadezimal Darstellung um.

Und hast du schon mal an die xxxxxxxxxxxxx Personen gedacht, die kein ASCII als Standard-Zeichensatz benutzen?

Was ist mit denen? Die können damit auch keine Hexadezimalen Zahlen darstellen, also wie kommst Du auf diese Leute?

Die Mathematik ist die einzige Sprache, die international ist. Sowohl ein Deutscher, als auch Japaner kann die Hexadezimaldarstellung Interpretieren, und wieder in die _orginal_ Werte zurücküberführen.

Was ist wenn die erste 32 Bit Variable folgendes Wert enthält:
0x61626364

ASCII: abcd

Das ist nicht sicher, das kannst Du so nicht behaupten. Das kann selbst bei ASCII auch "dcba" oder gar "badc" sein.

Gut das stimmt, es kommt auf die Plattform drauf an. Aber der Wert: 0x61626364 wäre weltweit eindeutig, ganz im gegensatz zu: abcd.

Und da Hexadezimal Weltweit eindeutig ist, gibt es dort keine Verwechslungen.

Eben sagtest Du noch, das sowas im japanischem Zeichensatz nicht geht, denn die für hexadezimale Darstellung nötigen ASCII-Zeichen "a,b,c,d,e,f" soll es da ja nicht geben.

Die Buchstaben a,b,c,d,e,f stehen aber nicht für den Wert des ASCII Wertes, sondern für 10,11,12,13,14,15.
Dies ist Weltweit eindeutig.

Ich kann immer noch nicht nachvollziehen, warum eine Hexadezimalzahl außer in seltenen und zudem nicht produktionsrelevanten Ausnahmen die ideale Lösung darstellen soll.

Was spricht denn gegen die Hexadezimal darstellung?
1. Anders als bei einer Kodierung verbraucht der Wert nicht unnötig mehr Platz, denn man kann diese als "Binär" speichern, also braucht er nur 16 Byte anstatt 32 Byte wenn man ihn als ASCII String speichert.
2. Der Binärwert ist weltweit eindeutig
3. Programmierer können eine Hexadezimal Ausgabe lachhaft einfach realisieren.
4. Man muss sich nicht auf ein Kodierungstandard einigen.
5. Man kann ihn sehr leicht in jede weiter Form überführen

Das Hexadezimalsystem eignet sich sehr gut, um Folgen von Bits (verwendet in der Digitaltechnik) darzustellen (Wikipedia)

Tja und MD5 gibt einfach eine Folge von Bits zurück.

Grüße
Elderan

[Christoph Zurnieden]

Hi,

BTW: MD5 sollte mittlerweile als gebrochen angesehen und zu kryptographischen Zwecken nicht mehr benutzt werden.
Dies ist teilweise Unfug.

Es mag dem einem oder anderem als paranoid erscheinen, aber es ist keinesfalls Unfug.

Dennoch ist es schwer, zwei _Sinnvolle_ Nachrichten mit dem gleichen Hashwert zu finden.

Es kommt hierbei auf das Format an:
http://www.cits.rub.de/MD5Collisions/
Deshalb sind kryptographische Hashes bei Text auf den rohen, unformatierten Text anzuwenden. Das bedeutet auch, das die Benutzung von unbekannten Formaten (z.B. ein MS-Word-Dokument) ein Sicherheitsrisiko darstellt.

Die schwache Kollisionsresistenz ist aber weiterhin gegeben, diese besagt: Zu einer gegebenen Nachricht ist es schwer, ein zweite verschiedene mit dem gleichen Hashwert zu finden.

Das ist bei MD5 nicht mehr schwer genug. Insbesondere bei Paßwörtern:

Wäre dies nicht vorhanden, hätte man ein Problem beim Speichern von Passwörtern.

Es gibt tatsächlich ein Problem damit, MD5 ist als Eiweghash nicht mehr zu empfehlen. Es gibt eine großangelegte Aktion, die zu allen möglichen Hashes ein passendes Paßwort sucht, das kann dann nachgeschaut werden anstatt mühselig probiert.

Z.B. bei Dateien die zum Download angeboten werden. (Hexadezimal sinnvoll)

Wenn ich mir ein Programm herrunterlade (z.B. php), und schauen möchte ob dies fehlerfrei Übertragen wurde, dann geh ich auf die Homepage, da findet man oft soetwas:
md5: fb1aac107870f897d26563a9cc5053c0

Auf der gleichen Homepage wo Du es auch herunterlädst? Dann ist sowas eh zweckfrei.
Zudem wäre auch hier zwar base64() sinnvoller, aber es spart nicht viel und ist dem C&P auch egal.
Diese Anwendung würde ich übrigens auch unter meine Ausnahmen "Dokumentation&Debugging" setzen.

Dann starte ich mein altes Dos Programm, gebe den Pfad zu Datei an, dies berechnet den Hashwert und gibt ihn als Hexadezimal aus. Per Auge überprüfe ich ob die Hashwerte identisch sind.

_Mußt_ Du das per Auge überprüfen oder wäre es nicht doch sinnvoller weil fehlerresistenter, diesen Vergleich einen Automaten machen zu lassen? Ich glaube schon.

Angenommen auf der PHP Homepage wäre die Ausgabe als ASCII-String.

Wie wäre es denn mit einem passendem Mimetypen?

Anstatt, wie es bisher ist, folgendes zu benutzen:
printf("%08x%08x%08x%08x",A,B,C,D);
Müsste dieser erst A,B,C,D kodieren. Benutzt man z.B. Base64, dort werden 3 Byte in 4 Byte "überführt". Allerdings besitzt jede Variable 4 Byte/32 Bit.

Den Weg zum "allerdings" verstehe ich nicht.

Und des weiteren hat man ein Problem, wenn das Programm z.B. Base32 benutzt, auf der PHP Homepage aber der Hashwert als Base64 angegeben wird.

Wie gesagt, ein passender Mimetype regelt sowas.

Also das ist ein deutlicher Mehraufwand für Programmierer, außerdem wäre es dann Sinnvoll, wenn MD5 einen Kodierungstandard vorgibt, damit nicht jeder macht was er möchte.
Aber warum benutzt man dann nicht gleich Hexadezimal?

Warum nimmt man denn nicht gleich Base64?
Oder die Rohware mit passendem Mimetypen?

Nein, die Ausgabe als hexadezimalen String bringt keinerlei Vorteile.

Da ist es völlig egal. Wenn es trotzdem Probleme bereitet ist eines der beteiligten Programme kaputt oder schlecht programmiert.
Wenn man z.B. eine .exe Datei im Editor/Notepad öffnet, dort einen Buchstaben einfügt und diesen wieder löscht => speichern, so wird das Programm aufgrund der Steuerzeichen nicht mehr funktionieren.

Dann ist also Notepad beschädigt oder schlecht programmiert. Denn ein Editor, der die geladenen Dateien ohne Auftrag des Benutzer verändert ist nicht zu gebrauchen.
In den von mir benutzten Editoren funktioniert sowas wie von Dir beschrieben übrigens problemlos.

Also könnte man z.B. eine Passwortdatei nicht per Notepad bearbeiten.

Dann laß es doch und nimm das dazu vorgesehene Programm!

Und wenn ich per phpMyAdmin den Datensatz anschaue, dann müssen im Formular auch steuerzeichen dargestellt werden, was zu Problemen führt.

Dann ist das Programm phpMyAdmin zum Anschauen ungeeignet.
Ich benutze hier meist Nedit als Editor, das zur Darstellung und Eingabe von Steuerzeichen in der Lage ist. Warum kann es phpMyAdmin nicht? Kaputt?
Aber wie ich selber schon sagte:

Lösung => Kodierung (warum kein Hexadezimal)

zu Dokumentations und Debuggingzwecken ist eine Codierung als hexadezimalen String genehmigt und auch willkürlicher Quasistandard.

Wo bitte sollte es Verluste geben? Nein, Unfähigkeit des Programmierers ist kein Grund.
Siehe .exe Beispiel.

Ja, das war ein gutes Beipiel, wenn auch nicht in Deinem Sinne.

Ja, das ist wohl wahr und zwar in Dokus und Debuggingsessions. Sonst nirgends. Was soll auch ein Mensch damit sonst anfangen?
Ihn vergleichen?

Das sollte der Mensch tunlichst lassen und ein Programm dafür nutzen. Ausnahme: Debugging.

Ihn evt. selber erstellen?

Das will ich sehen, wie Du auch nur TEA im Kopf berechnest!
Na gut, ich gestehe Dir Papier und Bleistift zu, nicht jedem ist ein gutes Gedächtnis gegeben.

Wenn man ein AdminCP schützen möchte, so überprüft man oft:
if(md5($pw)) == "fb1aac107870f897d26563a9cc5053c0");

Und in base64 wäre es sowas wie
if(md5($pw)) == "+xqsEHhw+JfSZWOpzFBTwA==");

Wäre sogar noch ein wenig kürzer, wie man sieht. Ansonsten rein gar kein Unterschied.

Die "Klartext"-Schreibweise ist auch unnötig, wenn z.B. eine Paßwortdatei benutzt wird, in denen die Hashes aufbewahrt werden. Auslesen erfordert keinerlei menschliches Eingreifen und Umwandeln. Hardcodierte Hashes wie in Deinem Beispiel sollten nicht benutzt werden, sie sind mindestens ein Zeichen schlechten Stils, meist jedoch noch mehr.
In einem Tutorial o.ä. ist sowas natürlich i.O., aber da wären wir wieder bei den beiden Ausnahmen: Dokumentation und Debugging.

Das muss aber alles, evt. Umständlich programmiert werden.

Es ist selten wirklich umständlicher.

Sofern man noch andere Sprachen als PHP kennt, weiß man wie dämlich es ist, verschiedene String Arrays in Base64 zu kodieren, denn dort muss man immer ein vielfaches von 3 Suchen, was nicht immer leicht möglich ist.

Hängst Du Dich jetzt an Embededhardware mit begrenztem Speicher? Da würde ich erst recht die Rohware nehmen, die ist ja immer noch am kleinstem!
Und wenn nicht: base64 ist um einiges kleiner als ein hexadezimaler String, der für jedes Byte, das er darstellt satte zwei Byte Platz benötigt.

Außerdem kann man den Hashwert als Hexadezimal wieder sehr leicht in Integer überführen:
fb1aac107870f897d26563a9cc5053c0
fb1aac10 7870f897 d26563a9 cc5053c0
Und auf Basis dieser Hexadezimal Darstellung kann man dann wieder sehr leicht alle andere Formate erhalten.

Noch einfacher kann ich die Bytes der Rohware in Integer überführen, da sie ja sogar schon meist direkt so geliefert werden. Nur halt bei PHP nicht.

Diese 4/5 Ausgaben werden dann einfach aneinandergehängt, fertig ist der Hashwert..

Der Hashwert ist schon vorher fertig, der muß nicht noch weiter bearbeitet werden.
Hast du schonmal den MD5 Algorithmus _selbst_ programmiert?

Ja, warum?

Der return in PHP sieht wie folgt aus:
return hex($a).hex($b).hex($c).hex($d);
hex(); wandelt dabei Integer in Hexadezimal Darstellung um.

Und wozu? Laß doch das Array mit den 4 Integern, stört doch keinen!

BTW: ich hoffe nicht, das in PHP der MD5-Algorithmus in PHP geschrieben ist. Aber mich wundert bei PHP ja eh schon nicht mehr viel.

Was ist mit denen? Die können damit auch keine Hexadezimalen Zahlen darstellen, also wie kommst Du auf diese Leute?
Die Mathematik ist die einzige Sprache, die international ist. Sowohl ein Deutscher, als auch Japaner kann die Hexadezimaldarstellung Interpretieren, und wieder in die _orginal_ Werte zurücküberführen.

Nun, Du benötigst aber zur Darstellung dieser Hexadezimalzahlen -- die ja als Strings dargestellt werden -- den ASCII Zeichensatz, oder? Den haben sie aber nicht, deshalb können sie auch mit den Hexadezimalzahlen nichts anfangen. Können sie das doch ist Dein Argument, das diese Leute eben jene Hexadezimalzahlen benötigen, da sie kein ASCII können hinfällig.

Das ist nicht sicher, das kannst Du so nicht behaupten. Das kann selbst bei ASCII auch "dcba" oder gar "badc" sein.
Gut das stimmt, es kommt auf die Plattform drauf an. Aber der Wert: 0x61626364 wäre weltweit eindeutig, ganz im gegensatz zu: abcd.

Und wie möchtest Du ihn rüberbringen den Wert 0x61626364? Als Zahl? Dann mußt Du sie kodieren und zwar in etwas in des Nachbarn Zeichensatz. Kein ASCII: keine Hexadezimalzahl -- doch ASCII: "abcd" funktioniert, Hexadezimalzahl ist überflüssig.

Die Buchstaben a,b,c,d,e,f stehen aber nicht für den Wert des ASCII Wertes, sondern für 10,11,12,13,14,15.
Dies ist Weltweit eindeutig.

Das sind aber wiederum keine Hexadezimalzahlen, die Du doch zu verteidigen suchtest!

Was spricht denn gegen die Hexadezimal darstellung?

1. Anders als bei einer Kodierung verbraucht der Wert nicht unnötig mehr Platz, denn man kann diese als "Binär" speichern, also braucht er nur 16 Byte anstatt 32 Byte wenn man ihn als ASCII String speichert.

Ah, ich glaube ich verstehe so langsam. Du sitzt einem Trugschluß auf. Die hexadezimale Darstellung _ist_ ein String. Du benötigst also zur Darstellung doppelt soviele Bytes, wie das Original. Um nochmal auf Dein Beispiel weiter oben zurückzukommen:
if(md5($pw)) == "fb1aac107870f897d26563a9cc5053c0");
Hier ist "fb1aac107870f897d26563a9cc5053c0" ein String, keine Zahl! Eine Zahl wäre \xfb1aac107870f897d26563a9cc5053c0, wobei die aber wahrscheinlich zu groß für viele Sprachen wäre da sie 1:1 nur in eine 128 Bit-Architektur passen würde. Ich konnte mir bis hierhin noch keinen 64Bit Rechner leisten, deshalb habe ich mich noch nicht mit den jeweiligen Opcodes bekannt gemacht. Es ist also durchaus möglich, das es dort funktioniert.

2. Der Binärwert ist weltweit eindeutig

Ist er nicht, es gibt mehr Architekturen als nur welche mit 2er-Komplement.

3. Programmierer können eine Hexadezimal Ausgabe lachhaft einfach realisieren.

Kannst Du es? Bitte beschreibe in einem Satz, wie sowas funktioniert und begründe es in einem weiterem.

4. Man muss sich nicht auf ein Kodierungstandard einigen.

Doch, auf den Zeichensatz.

5. Man kann ihn sehr leicht in jede weiter Form überführen

Das kann man mit der Rohware auch und hat sich sogar einen Schritt gespart.

Das Hexadezimalsystem eignet sich sehr gut, um Folgen von Bits (verwendet in der Digitaltechnik) darzustellen (Wikipedia)

Ich dachte immer, das wäre mit Nullen und Einsen einfacher?
Aber Scherz beiseite: genau das ist ja eine der von mir beschrieben Ausnahmen, die da lauten: Dokumentation und Debugging.

Tja und MD5 gibt einfach eine Folge von Bits zurück.

Nein, so einfach ist das nicht, da die Reihenfolge je nach Architektur aufbereitet werden muß. Aber ist ja auch völlig egal, denn jede Rückgabe besteht, falls überhaupt vorhanden aus einer Folge von Bits. Ob von MD5(), base64() oder wie die Millionen und Abermillionen von Funktionen, die je geschrieben wurden heißen mögen, die etwas zurückgeben.

so short

Christoph Zurnieden

[Christian Kruse]

你好 Christoph,

3. Programmierer können eine Hexadezimal Ausgabe lachhaft einfach
   realisieren.

Kannst Du es? Bitte beschreibe in einem Satz, wie sowas funktioniert und
begründe es in einem weiterem.

Ich wusste gar nicht, dass du so abgrundtief gehässig und gemein sein
kannst ;-)

再见,
 克里斯蒂安

[Christoph Zurnieden]

Hi,

Ich wusste gar nicht, dass du so abgrundtief gehässig und gemein sein
kannst ;-)

Nun, ich bin mit zwei Schwestern aufgewachsen, da lernt man so einiges in dieser Richtung ;-)

Aber hast natürlich Recht, ich sollte mehr an mich halten und die Ruhe bewahren.

so short

Christoph Zurnieden

[Christian Kruse]

你好 Christoph,

Ich wusste gar nicht, dass du so abgrundtief gehässig und gemein sein
kannst ;-)

Nun, ich bin mit zwei Schwestern aufgewachsen, da lernt man so einiges in
dieser Richtung ;-)

Hehe, ich bin unter vier Brüdern und drei Schwestern aufgewachsen, trotdem
schlägst du mich noch um Längen, was das angeht *fg*

再见,
 克里斯蒂安

[Elderan]

Hallo,
wollen wir uns nicht mehr weiter streiten, aber:

Die schwache Kollisionsresistenz ist aber weiterhin gegeben, diese besagt: Zu einer gegebenen Nachricht ist es schwer, ein zweite verschiedene mit dem gleichen Hashwert zu finden.

Das ist bei MD5 nicht mehr schwer genug. Insbesondere bei Paßwörtern:

Also die schnellste Methode dafür ist immer noch Brute Force, und wenn das Passwort gut gewählt ist, dauert das Millionen von Jahre.

Beweise das Gegenteil:
f95781a118e0c4bce1d8a3386d6454f5
10 stelliges PW, a-z 0-9

Es gibt tatsächlich ein Problem damit, MD5 ist als Eiweghash nicht mehr zu empfehlen. Es gibt eine großangelegte Aktion, die zu allen möglichen Hashes ein passendes Paßwort sucht, das kann dann nachgeschaut werden anstatt mühselig probiert.

Super, es gibt ja nur: 2^128 Möglichkeiten, um _nur_ die Hashwerte zu speichern braucht man also: 2^128*128 Bit = 4*10^40 Bits oder ca. 5 Quadrilliarde Terrabyte. Und dann muss man dazu noch das Passwort speichern...
Und um diese Tabelle zu berechnet, benötigt man 2^128*x Rechenschritte (x: Rechenschritte pro MD5 Hash).

Sofern das Passwort _gut_ gewählt ist, gibt es darüber bisher keine Möglichkeit an das Passwort zu gelangen.
Aber dieses Verfahren funktioniert bei allen Hashverfahren, egal ob MD5, SHA1 oder Hashverfahren auf diskreten Logarithmen.

Bei schlechten Passwörtern hilft das beste Hashverfahren nicht, dafür ist der User zuständig....

Grüße
Elderan

[Christoph Zurnieden]

Hi,

wollen wir uns nicht mehr weiter streiten, aber:

... Du möchtest es trotzdem.

Beweise das Gegenteil:
f95781a118e0c4bce1d8a3386d6454f5

Probiere selber: http://passcracking.com/
Der nimmt übrigens auch Deinen heißgeliebten Hexstring an ;-)

10 stelliges PW, a-z 0-9

Was für ein Paßwort das ist interessiert nicht, da lediglich ein String gesucht wird, der zum selbem Hash führt.

Super, es gibt ja nur: 2^128 Möglichkeiten, um _nur_ die Hashwerte zu speichern braucht man also: 2^128*128 Bit = 4*10^40 Bits oder ca. 5 Quadrilliarde Terrabyte. Und dann muss man dazu noch das Passwort speichern...

Nein, das ist nicht korrekt, das geht auch deutlich geschickter.

Und um diese Tabelle zu berechnet, benötigt man 2^128*x Rechenschritte (x: Rechenschritte pro MD5 Hash).

Ja, das ist korrekt.

Sofern das Passwort _gut_ gewählt ist, gibt es darüber bisher keine Möglichkeit an das Passwort zu gelangen.

Wie gesagt: es ist völlig uninteressant an das Paßwort zu kommen, es reicht einen String zu finden, der den gleichen Hash ergibt.

Aber dieses Verfahren funktioniert bei allen Hashverfahren, egal ob MD5, SHA1 oder Hashverfahren auf diskreten Logarithmen.

Brute Force funktioniert immer, ja. Aber ist ja kein Brute Force bei MD5 mehr nötig, das ist ja der Witz.

Bei schlechten Passwörtern hilft das beste Hashverfahren nicht, dafür ist der User zuständig....

Schlechte Paßwörter gibt es bei Brute Force nicht, da sind alle gleich. Schlechte Paßworte sind jedoch möglich, wenn man von Lexikaangriffen ausgeht inklusive der üblichen kleinen Variationen. Die so ausgesiebten schlechten Paßworte verkleinern aber natürlich im Gegenzug wieder den Bereich, den Brute Force abzuklappern hätte. Gut, das wäre dann strenggenommen schon kein Brute Force mehr, aber so beckmesserisch bin ich heut' mal nicht.

BTW: der User sollte nicht für die Wahl der Paßworte zuständig sein. Nur wenn sich das wirklich nicht vermeiden läßt und normalerweise läßt es sich immer vermeiden.

so short

Christoph Zurnieden

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

BTW: der User sollte nicht für die Wahl der Paßworte zuständig sein. Nur wenn sich das wirklich nicht vermeiden läßt und normalerweise läßt es sich immer vermeiden.

Für mein Forumspasswort bin ich AFAIK selbst verantwortlich.
Wie ließe sich das vermeiden?

Gruß
Alexander Brock

[Christoph Zurnieden]

Hi,

BTW: der User sollte nicht für die Wahl der Paßworte zuständig sein. Nur wenn sich das wirklich nicht vermeiden läßt und normalerweise läßt es sich immer vermeiden.

Für mein Forumspasswort bin ich AFAIK selbst verantwortlich.
Wie ließe sich das vermeiden?

Ich nehme mal an, das Du die _Wahl_ des Paßwortes meinst: das läßt sich vermeiden, indem Du eines zugewiesen bekommen hättest.
Warum das nicht der Fall ist (reine Annahme, ich bin hier kein "Mitglied")? Es wäre mit Mehrarbeit verbunden, deren Kosten hier nicht wieder reinzuholen sind.

so short

Christoph Zurnieden

[Christian Kruse]

你好 Christoph,

Warum das nicht der Fall ist (reine Annahme, ich bin hier kein "Mitglied")?
Es wäre mit Mehrarbeit verbunden, deren Kosten hier nicht wieder
reinzuholen sind.

Versuchs mal so: der Sicherheitsanspruch ist hier nicht gross genug.

再见,
 克里斯蒂安

[Elderan]

Hallo,

Versuchs mal so: der Sicherheitsanspruch ist hier nicht gross genug.

Mir ist es lieber wenn ich mein Passwort selber wählen kann. Wer sagt mir denn, dass das Forum ein gutes wählt?
Evt. sind dort Schwächen o.ä. enthalten, die den Passwortraum extrem einschränken.

Grüße
Elderan

[Christian Kruse]

你好 Elderan,

Mir ist es lieber wenn ich mein Passwort selber wählen kann. Wer sagt mir
denn, dass das Forum ein gutes wählt?

Der Algorithmus, der in diesem Fall benutzt würde.

再见,
 克里斯蒂安

[Elderan]

Hallo,

Der Algorithmus, der in diesem Fall benutzt würde.

Und woher kenn ich den?

Desweiteren beruhen diese auf Pseudo-Zufallsgeneratoren, die entweder ganz gute Ergebnisse liefern, aber auch oft extrem schlechte.
Vorallem bei der C-Funktion rand(); liegen Welten zwischen den einzelnen Implentierungen.

Und wie sich bei Netscape gezeigt hat, sind nicht alle Systemparameter zu extrem zufällig, bzw. werden so genau gemessen, dass man sie verwenden könnte.

Die Funktion rand(); unter PHP/Windows liefert ein sehr schönes Muster (wenn man es grafisch darstellt).
Unter Unix/Linux erkennt man kein grafisches Muster mehr.

Grüße
Elderan

[Christian Kruse]

你好 Elderan,

Der Algorithmus, der in diesem Fall benutzt würde.
Und woher kenn ich den?

Den müsstest du nicht kennen. Der Algorithmus, der das Passwort generieren
würde, würde dafür sorgen, dass es „gut“ im Sinne der Parameter ist.
Andernfalls wäre er fehlerhaft und müsste debuggt werden.

再见,
 克里斯蒂安

[Elderan]

Hallo,

Den müsstest du nicht kennen. Der Algorithmus, der das Passwort generieren
würde, würde dafür sorgen, dass es „gut“ im Sinne der Parameter ist.
Andernfalls wäre er fehlerhaft und müsste debuggt werden.

Ja das stimmt, leider haben viele Programmierer kaum eine Ahnung von Kryptographie. Selbst bei Personen bei denen das man erwarten würde, ist es nicht der Fall.

Beispiel:
WEP <= NIST, kryptographischer Müll
Netscape und SSL <= Der 40 Bit Key-Raum wurde ca. um den Faktor 100 Mrd. verkleinert
Clipper und Capstone-Chips <= NSA, es ist ein leichtes die Behörde auszutricksen. Desweiteren leichte Verfälschung der Identifikation.
A5 <= GSM-Chiffrieralgorithmus, meist genutzt Algorithmus der Welt. Nach ca. 3 Minuten Handygespräch kann man die Chiffre knacken.

Und ich denke der durchschnittliche PHP-Programmierer hat nicht die Erfahrungen wie jmd. vom NIST, NSA o.ä.
Aber von dem erwartest du, dass er sicher zufällige Passwörter erstellen kann?

Grüße
Elderan

[Christian Kruse]

你好 Elderan,

Den müsstest du nicht kennen. Der Algorithmus, der das Passwort
generieren würde, würde dafür sorgen, dass es „gut“ im Sinne der
Parameter ist. Andernfalls wäre er fehlerhaft und müsste debuggt werden.
Ja das stimmt, leider haben viele Programmierer kaum eine Ahnung von
Kryptographie. Selbst bei Personen bei denen das man erwarten würde, ist
es nicht der Fall.

Das ist aber nicht dein Problem. Das ist dann Problem desjenigen, der das
Produkt des Programmierers einsetzt.

Aber von dem erwartest du, dass er sicher zufällige Passwörter erstellen
kann?

Es ist ein kleiner Unterschied ob man ein sicheres Passwort erstellen will
oder ob man eine SSL-Implementation schreiben will. Ein sicheres Passwort
zu erstellen (wobei erstmal definiert werden müsste, was „sicher“ in dem
Zusammenhang heisst) ist beinahe schon trivial.

再见,
 克里斯蒂安

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

Ein sicheres Passwort zu erstellen (wobei erstmal definiert werden müsste, was „sicher“ in dem
Zusammenhang heisst) ist beinahe schon trivial.

Nur mal so am Rande:
ergibt folgender Algorithmus ein "sicheres" Passwort
(abgesehen davon, dass sich das niemand merken kann und es daher Schwachsinn ist)?

function make_pw() {
 srand ((double)microtime()*1000000);
 sha1(rand().$_SERVER['REMOTE_ADDR'].(double)microtime());
}

Gruß
Alexander Brock

[Christoph Zurnieden]

Hi,

Nur mal so am Rande:
ergibt folgender Algorithmus ein "sicheres" Passwort

Ja. Und dabei ist es fast schon egal was jetzt für ein Algorithmus kommt, denn es fehlt eine wichtige Kleinigkeit: wie lange muß das Paßwort halten?

(abgesehen davon, dass sich das niemand merken kann und es daher Schwachsinn ist)?

Diese Satz ist Schwachsinn, wenn mir der Ausfall einmal erlaubt sei. Wenn ein Paßwort gut ist, kann man es sich selten merken, vor allem, wenn man davon einige hat. Deshalb ist anzuraten es sich aufzuschreiben und diesen Zettel (muß nicht zwigend aus Papier sein) sorgfältig aufzubewahren. Die Brieftasche (muß nicht zwingend aus Leder sein) wäre z.B. ein passender Aufbewahrungsort.

so short

Christoph Zurnieden

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

Ja. Und dabei ist es fast schon egal was jetzt für ein Algorithmus kommt, denn es fehlt eine wichtige Kleinigkeit: wie lange muß das Paßwort halten?

2h :-) (kein Spaß, das ist wirklich so (das war auch nicht direkt ein Passwort)).

Diese Satz ist Schwachsinn, wenn mir der Ausfall einmal erlaubt sei. Wenn ein Paßwort gut ist, kann man es sich selten merken, vor allem, wenn man davon einige hat. Deshalb ist anzuraten es sich aufzuschreiben und diesen Zettel (muß nicht zwigend aus Papier sein) sorgfältig aufzubewahren. Die Brieftasche (muß nicht zwingend aus Leder sein) wäre z.B. ein passender Aufbewahrungsort.

Hast Recht.

Gruß
Alexander Brock

[Henryk Plötz]

Moin,

Diese Satz ist Schwachsinn, wenn mir der Ausfall einmal erlaubt sei. Wenn ein Paßwort gut ist, kann man es sich selten merken

Dagegen. Wenn man bei der Generierung ein wenig Rücksicht auf den Menschen dahinter nimmt (Silben gehen besser als reine Konsonantenwüsten, etwas das man aussprechen kann, kann besser gespeichert werden, etc.) kann man auch merkbare Passwörter generieren die nur wenig schwächer sind als völlig zufällige. Gut, dann hat man eben nicht mehr 6 sondern nur noch 5 oder so Bit pro Zeichen und muss das Passwort entsprechend verlängern. Who cares.

[Christoph Zurnieden]

Hi,

Diese Satz ist Schwachsinn, wenn mir der Ausfall einmal erlaubt sei. Wenn ein Paßwort gut ist, kann man es sich selten merken

Dagegen. Wenn man bei der Generierung ein wenig Rücksicht auf den Menschen dahinter nimmt (Silben gehen besser als reine Konsonantenwüsten, etwas das man aussprechen kann, kann besser gespeichert werden, etc.)

[...]
Who cares.

Der Benutzer, dem sind selbst die noch zu lang.
Glaub's mir, ich kenn' das Problem zur Genüge *sigh*

so short

Christoph Zurnieden

[Christoph Zurnieden]

Hi,

ergibt folgender Algorithmus ein "sicheres" Passwort

Da habe ich mich gerade einmal drangesetzt, da mir der Papierkram mal wieder bis Oberkante Unterlippe steht.

function make_pw() {
srand ((double)microtime()*1000000);
sha1(rand().$_SERVER['REMOTE_ADDR'].(double)microtime());
}

Dieser Algorithmus ist nicht sicher, da er unter bestimmten Vorausetzungen das gleiche Paßwort mehrfach ausgeben könnte.

Die Voraussetzung sind auch so ungewöhnlich nicht: es ist lediglich ein Multiprozessorsystem nötig und ein Router/Proxie o.ä. damit $_SERVER['REMOTE_ADDR'] gleich bleibt.
Dann kann diese Funktion zweimal zur gleichen Zeit ausgeführt werden, d.h. der Seed über microtime() ist gleich, damit ist auch die Ausgabe von rand() gleich; $_SERVER['REMOTE_ADDR'] ist gleich und die zweite Ausgabe von microtime() ist auch gleich (wenn auch mit etwas geringerer Wahrscheinlichkeit) somit ist die Ausgabe von sha1() ebenfalls gleich.
microtime() hat zudem auf heutigen GHz Boliden nicht unbedingt die erforderliche Auflösung um sowas auch bei Einprozessorsystemen zu verhindern.

Tja, auch mit dem besten kryptographischen Werkzeugen kann man sich mühelos selber in den Fuß schießen ;-)

Aber gräme Dich nicht, sowas passiert auch den Besten mal, deswegen ist für kryptographsche Methoden und vor allem Implementationen Peer-Review geradezu _zwingend_ und damit das klappt auch Quelloffenheit.

so short

Christoph Zurnieden

PS:
Lösung des Dilemmas ist im einfachstem Fall ein Lockfile, das den aktuellen Seed enthält. Der nächste, der das Lockfile erhält kann reinschauen und bei Seedgleicheit einen neuen erzeugen.
Ist zwar nicht sehr elegant, ist aber simpel und funktioniert.
CZ

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

Dieser Algorithmus ist nicht sicher, da er unter bestimmten Vorausetzungen das gleiche Paßwort mehrfach ausgeben könnte.

Das ist aber _sehr_ unwahrscheinlich. Ich habe mal 1Mio Passwörter hintereinander damit erzeugt
(auf einem Athlon XP 2500+, 1GB RAM) und bekam kein doppeltes Passwort (mit immer gleicher IP).

Die Voraussetzung sind auch so ungewöhnlich nicht: es ist lediglich ein Multiprozessorsystem nötig und ein Router/Proxie o.ä. damit $_SERVER['REMOTE_ADDR'] gleich bleibt.

Hm, wenn ich serialize(($_GET|$_POST|$_SERVER)) dazunehme, wird sowas auch unwahrscheinlicher.

Dann kann diese Funktion zweimal zur gleichen Zeit ausgeführt werden [...]

Kann man irgendwie $_HARDWARE['PROZESSOR_NUMBER'] dazunehmen ? ;-)

microtime() hat zudem auf heutigen GHz Boliden nicht unbedingt die erforderliche Auflösung um sowas auch bei Einprozessorsystemen zu verhindern.

Gibts was genaueres? Ich hab nix gefunden.

Tja, auch mit dem besten kryptographischen Werkzeugen kann man sich mühelos selber in den Fuß schießen ;-)

Kann man auch mit den einfachen Dingen des Lebens (ich darf an die goto-Zeiten erinnern ;-))

Lösung des Dilemmas ist im einfachstem Fall ein Lockfile, das den aktuellen Seed enthält. Der nächste, der das Lockfile erhält kann reinschauen und bei Seedgleicheit einen neuen erzeugen.
Ist zwar nicht sehr elegant, ist aber simpel und funktioniert.

Das ist natürlich eine Lösung. In meinem Fall kann ich aber meinen Algorithmus behalten,
der ist dazu da, bei einem Formmailer dem Formular eine ID mitzugeben,
nur wer eine gültige ID hat, darf dann eine Mail verschicken :-)

Gruß
Alexander Brock

[Christoph Zurnieden]

Hi,

Das ist aber _sehr_ unwahrscheinlich.

Aber größer Null.
Wie war das doch gleich mit den Pferden und der Apotheke? ;-)

Ich habe mal 1Mio Passwörter hintereinander damit erzeugt
(auf einem Athlon XP 2500+, 1GB RAM) und bekam kein doppeltes Passwort (mit immer gleicher IP).

Nein, das ist hier Kryptographie, da gibt es kein Ausprobieren.

Die Voraussetzung sind auch so ungewöhnlich nicht: es ist lediglich ein Multiprozessorsystem nötig und ein Router/Proxie o.ä. damit $_SERVER['REMOTE_ADDR'] gleich bleibt.

Hm, wenn ich serialize(($_GET|$_POST|$_SERVER)) dazunehme, wird sowas auch unwahrscheinlicher.

Nur wenn der Inhalt tatsächlich in beiden Fällen unterschiedlich ist. Ob das funktioniert wäre also noch zu untersuchen.

Dann kann diese Funktion zweimal zur gleichen Zeit ausgeführt werden [...]

Kann man irgendwie $_HARDWARE['PROZESSOR_NUMBER'] dazunehmen ? ;-)

Gibt es nicht in PHP, warum auch immer.
(Ja, ich habe Dein Smiley gesehen und es prompt ignoriert ;-)

microtime() hat zudem auf heutigen GHz Boliden nicht unbedingt die erforderliche Auflösung um sowas auch bei Einprozessorsystemen zu verhindern.

Gibts was genaueres? Ich hab nix gefunden.

"See the source, Luke!" könnte man hier bellen, aber so einfach ist es natürlich nicht. Dafür muß man sich schon durch die Übersetzungen bis runter zu den Opcodes quälen und durchzählen. Die Chance besteht aber, deshalb ist es hier nicht zu ignorieren.

Tja, auch mit dem besten kryptographischen Werkzeugen kann man sich mühelos selber in den Fuß schießen ;-)

Kann man auch mit den einfachen Dingen des Lebens (ich darf an die goto-Zeiten erinnern ;-))

Nun, wenn man zu eitel ist, Papier und Bleistift zu Hilfe zu nehmen ;-)

Das ist natürlich eine Lösung. In meinem Fall kann ich aber meinen Algorithmus behalten,
der ist dazu da, bei einem Formmailer dem Formular eine ID mitzugeben,
nur wer eine gültige ID hat, darf dann eine Mail verschicken :-)

Und das geht alles über SSL? Ansonsten ist die mühsame ID-Erstellung nämlich für die Katz. Mal ganz am Rande: wäre ein Session-ID dafür nicht genausogut gewesen? Die ist meines Wissens sogar garantiert einzigartig (innerhalb gewisser Zeit).

so short

Christoph Zurnieden

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

Das ist natürlich eine Lösung. In meinem Fall kann ich aber meinen Algorithmus behalten,
der ist dazu da, bei einem Formmailer dem Formular eine ID mitzugeben,
nur wer eine gültige ID hat, darf dann eine Mail verschicken :-)

Und das geht alles über SSL?

Nö. Kennst du jemanden, der in Mailformulare GPG-Verschlüsselte Texte eingibt?
Wenn er das nämlich nicht tut ist die SLL-Übertragung für die Katz.

Ansonsten ist die mühsame ID-Erstellung nämlich für die Katz.

Es geht um Spam, es soll niemand einfach das Formular 1.000.000 mal abschicken.

Mal ganz am Rande: wäre ein Session-ID dafür nicht genausogut gewesen?

Nein. Sie Session lebt nur zwanzig Minuten, User, die mehr als zwanzig Minuten brauchen,
um ihren Text zu tippen fallen auf die Schnauze. Die IDs, die ich erzeuge leben 2h.

Gruß
Alexander Brock

[Christoph Zurnieden]

Hi,

Und das geht alles über SSL?

Nö. Kennst du jemanden, der in Mailformulare GPG-Verschlüsselte Texte eingibt?
Wenn er das nämlich nicht tut ist die SLL-Übertragung für die Katz.

Das ist dann später als die Sache mit der ID, daher ist SSL hier noch nicht für den Kater.
Da Du aber nun endlich mit dem wahren Grund für Dein Tun rübergekommen bist ...

Es geht um Spam, es soll niemand einfach das Formular 1.000.000 mal abschicken.

... finde ich die Erzeugung der ID sogar viel zu aufwendig, Konkanetation von IP und Microtime als Strings sollten reichen. In der kurzen Zeit braucht es schon eine verdammt dicke Anbindung auf Deiner Seite um Spam lästig werden zu lassen.

Nein. Sie Session lebt nur zwanzig Minuten, User, die mehr als zwanzig Minuten brauchen,
um ihren Text zu tippen fallen auf die Schnauze.

Ja, und? Dann mußt Du auch nicht soviel lesen! >;->

Aber Scherz beiseite: Dein System ist DDoS anfällig wenn Du nur auf Zeit spielst. Du solltest auch die Gesamtanzahl begrenzen. Der String ist nicht sehr lang und es dürften daher je nach Speicherausstattung auch mehrere Millionen kein Problem darstellen. Da der Zählereinbau ebenfalls nix kostet würde ich es empfehlen.
Du kannst mich aber auch anankisch schimpfen und es lassen ;-)

so short

Christoph Zurnieden

[Christoph Zurnieden]

Hi,

Der Algorithmus, der in diesem Fall benutzt würde.
Und woher kenn ich den?

Meistens erkennt man den am Schritt sprich: an der Ausgabe.

Desweiteren beruhen diese auf Pseudo-Zufallsgeneratoren, die entweder ganz gute Ergebnisse liefern, aber auch oft extrem schlechte.

Nein, das kann nicht allgemein gesagt werden, einige Server nutzen auch echte Zufallsgeneratoren.

Vorallem bei der C-Funktion rand(); liegen Welten zwischen den einzelnen Implentierungen.

Niemand ist gezwungen sie zu nutzen, es gibt einige freie Implementationen guter teilweise sogar sehr guter PRGs.

Und wie sich bei Netscape gezeigt hat, sind nicht alle Systemparameter zu extrem zufällig, bzw. werden so genau gemessen, dass man sie verwenden könnte.

Was hat denn jetzt der alte Netscape-Murks damit zu tun? Außer als Beispiel dafür wieviel bei der Implementation von Kryptographie schiefgehen kann.

Die Funktion rand(); unter PHP/Windows liefert ein sehr schönes Muster (wenn man es grafisch darstellt).

Das sollte PHP bekannt sein, warum machen die nix dagegen?

Unter Unix/Linux erkennt man kein grafisches Muster mehr.

Auch wenn man keines mehr erkennt ist trotzdem eines vorhanden. Wenn nicht gerade echte Zufallsgeneratoren werkeln.

so short

Christoph Zurnieden

[Henryk Plötz]

Moin,

Mir ist es lieber wenn ich mein Passwort selber wählen kann. Wer sagt mir
denn, dass das Forum ein gutes wählt?

Der Algorithmus, der in diesem Fall benutzt würde.

Das macht nichts. Abgesehen davon dass mir niemand versichern kann, dass der Algorithmus wirklich benutzt wird ("Duhu, dieser doofe Passwortalgorithmus verschlingt so viel Rechenzeit, lass uns den mal durch was einfacheres ersetzen, merkt auch keiner." ;-) kann der dahinterliegende Zufallsgenerator immer noch scheiße sein oder grade Unfug liefern ("Entropie is grade aus, kriegen wir vielleicht morgen wieder rein", oder ein Gerät liefert im konstanten Intervall einen Interrupt was vom Entropiesammler auch schön gesammelt wird, etc.).

Nein nein, Passwörter und private Schlüssel generiert man selbst. Auf Maschinen die man unter Kontrolle hat. Das will man nicht delegieren.

[Christoph Zurnieden]

Hi,

Der Algorithmus, der in diesem Fall benutzt würde.

Das macht nichts. Abgesehen davon dass mir niemand versichern kann, dass der Algorithmus wirklich benutzt wird

Das ist korrekt, ein grundsätzliches Problem, aber auf beiden Seiten.

Nein nein, Passwörter und private Schlüssel generiert man selbst. Auf Maschinen die man unter Kontrolle hat. Das will man nicht delegieren.

Öffentliche Paßwörter und private Schlüssel haben rein gar nix gemein, schmeiße die bitte nicht in einen Topf.

Das Problem, wenn der Benutzer die Paßworte auswählt hatte ich ja schon beschrieben, einweiteres hast Du an anderer Stelle angefügt. Zudem hast Du Deine Maschine dank DRM und Konsorten nicht unbedingt unter Kontrolle. Da kannst Du höchstens noch auf das Produkt verzichten, das DRM von Dir verlangt. Gut, letzteres Argument ist zwar Zukunftsmusik da nur mit Hardwareunterstützung tatsächlich zwingend, ich befürchte aber nicht mehr lange.
Hat dann nichts mit Paßwortgenerierung zu tun? Na, die Hardware enthält dann auch einen echten Zufallsgenerator und dessen Echtheit zu kontrollieren ist technisch sehr aufwendig.
Otto Normalbenutzer hat zudem seine ganze Maschinen nicht im Griff und der hält eine mehr als satte Mehrheit. Er kann rein gar nichts kontrollieren, versteht im Mittel nix von Paßwörtern und ist dem Anbieter auf Treu und Glauben ausgeliefert, nur gesichert von einem hauchdünnem Faden namens Gesetzbuch. Dieser Faden fehlt bei der Software sogar ganz, der Vorteil liegt also auch hier wieder bei der Bereitstellung der Paßworte durch den Anbieter.

Das Du persönlich es besser könntest glaube ich Dir auf's Wort, aber ich kenne Dich ja auch schon etwas länger, wenn auch leider nicht persönlich Aug' in Aug'. Deshalb mußt Du auch in den sauren Apfel beißen und annehmen, was gegeben wird oder das Angebot ausschlagen. Aber es wird eh nur sehr selten das Paßwort vorgeschrieben, also setz' Dich wieder hin ;-)

so short

Christoph Zurnieden

[Christoph Zurnieden]

Hi,

Versuchs mal so: der Sicherheitsanspruch ist hier nicht gross genug.
Mir ist es lieber wenn ich mein Passwort selber wählen kann. Wer sagt mir denn, dass das Forum ein gutes wählt?

Du selber. Denn wenn Du in der Lage bist ein gutes Paßwort zu wählen kannst Du auch bestimmen ob das gelieferte Paßwort gut ist.
Zudem liegen die Quellen dieses Forums offen. Gut, ob die Quellen mit der aktuell laufenden Software in allen Punkten übereinstimmt kannst Du natürlich nur glauben, nicht wissen.

Evt. sind dort Schwächen o.ä. enthalten, die den Passwortraum extrem einschränken.

Dann läßt Du Dir ein neues geben, ganz einfach.

Nein, die Wahrscheinlichkeit, das sich jemand aus dem Stand gute Paßworte ausdenken kann geht gegen Null, der menschliche Geist als Zufallsgenerator funktioniert nunmal nicht. Zudem würde es auch den Paßwortraum einschränken, wenn man die Benutzer die Paßworte wählen lassen würde, da diese geprüft werden müßten, schlechte abgelehnt und so preisgegeben würde, welche Paßworte mit hoher Wahrscheinlichkeit nicht vorkommen werden.

Nein, sicherheitstechnisch ist es am Besten, wenn die Paßworte vom System generiert werden. Da dies jederzeit wiederholt werden kann, können die Laufzeiten der einzelnen Paßworte kurz gehalten werden und sind dadurch auch bei schlechter Wahl noch gut.

BTW:http://www.adel.nursat.kz/apg/ hat neben einem automatischem Paßwortgenerator auch einige passende Informationen dazu.

so short

Christoph Zurnieden

[Henryk Plötz]

Moin,

Du selber. Denn wenn Du in der Lage bist ein gutes Paßwort zu wählen kannst Du auch bestimmen ob das gelieferte Paßwort gut ist.

Nein. Es ist gradezu trivial schlechte Passwörter zu erzeugen die trotzdem jedem statistischen Test standhalten. Wenn man seine Passwörter zum Beispiel als SHA1 von 1, 2, 3, 4, usw. generiert kriegt man nahezu per definitionem gute statistische Eigenschaften. Dazu noch ein passendes Mapping um von Hexadezimalzahlen bzw. einem Bitstring in einen passwortüblichen Zeichenbereich zu kommen und voila. Wenn du dann noch ein festes Geheimnis mithashst kann jemand der das Geheimnis nicht kennt noch nichtmal dahinter kommen dass du da was im Schilde führst, selbst wenn er sich alle ausgegebenen Passwörter sorgfältig ansieht.. Trotzdem sind diese Passwörter über alle Maßen schlecht da sie nur wenige Bit Zufall enthalten und kinderleicht zu erraten sind.

Nein, die Wahrscheinlichkeit, das sich jemand aus dem Stand gute Paßworte ausdenken kann geht gegen Null, der menschliche Geist als Zufallsgenerator funktioniert nunmal nicht.

Deswegen tut man das auch nicht und benutzt apg.

[Christoph Zurnieden]

Hi,

Du selber. Denn wenn Du in der Lage bist ein gutes Paßwort zu wählen kannst Du auch bestimmen ob das gelieferte Paßwort gut ist.

Nein. Es ist gradezu trivial schlechte Passwörter zu erzeugen die trotzdem jedem statistischen Test standhalten. Wenn man seine Passwörter zum Beispiel als SHA1 von 1, 2, 3, 4, usw. generiert kriegt man nahezu per definitionem gute statistische Eigenschaften. Dazu noch ein passendes Mapping um von Hexadezimalzahlen bzw. einem Bitstring in einen passwortüblichen Zeichenbereich zu kommen und voila. Wenn du dann noch ein festes Geheimnis mithashst

Dann ist das Paßwort schon wieder in Ordnung.

kann jemand der das Geheimnis nicht kennt noch nichtmal dahinter kommen dass du da was im Schilde führst, selbst wenn er sich alle ausgegebenen Passwörter sorgfältig ansieht.. Trotzdem sind diese Passwörter über alle Maßen schlecht da sie nur wenige Bit Zufall enthalten und kinderleicht zu erraten sind.

Ja, dieser Aspekt ist natürlich bekannt. Allerdings geht es hier nicht um's Erraten, da der Beschiss schon weit vorher anfängt. Zudem wurde an einer Stelle beschissen, die auch auf anderem Wege an die Daten käme. Es geht hier nicht um die Sicherhit des Paßwortes sondern um das Konzept allgemein und die grundsätzlichen Schwierigkeiten bei der Erstellung und Übertragung der Schlüssel bei symmetrischer Verschlüsselung.
Auch ist es hier egal, wer bescheißt, denn obiges Szenario gilt natürlich für beide Seiten. Da es meist der Anbieter ist, der im Zweifelsfall haftet gilt wieder, das es sicherer ist wenn der Anbieter das Paßwort zuteilt.

so short

Christoph Zurnieden

[Elderan]

Hallo,

Probiere selber: http://passcracking.com/
Der nimmt übrigens auch Deinen heißgeliebten Hexstring an ;-)

Wer lesen kann:

This project is dedicated to crack md5 hashes online through web interface. At the moment we can crack md5 hashes in this character range: a-z;0-9 [8]

Dies entspricht: 32^8 bzw. ca. 2^40.
Natürlich weiß man, dass ein 40 Bit Passwort deutlich zu schlecht ist.
Benutzt man allerdings ein 12 Stellenpasswort a-z;A-Z;0-9 ergibt sich daraus:
62^12 bzw. ca. 2^72. Dieses Passwort ist gegen normale Personen ausreichen sicher, denn die durchschnittlich Laufzeit O(2^71) ist noch zu groß für den Personen ohne super Computer.

Was für ein Paßwort das ist interessiert nicht, da lediglich ein String gesucht wird, der zum selbem Hash führt.

Aber es macht Sinn, diesen String im kleineren Raum zu suchen.

Um eine Kollision zu finden, ist Brute Force die schnellste Möglichkeit bei MD5, sofern die Nachricht vorgegeben ist.
Allerdings braucht man dann für eine Kollision durchschnittlich 2^127 Berechnungen.
Da aber Passwörter i.d.R. schlecht gewählt sind, überprüfe ich erst die Strings mit einer Länge von 1,2,3,4,5,6,7,8.
Da braucht man nur ca. 2^40 Berechnungen.

Super, es gibt ja nur: 2^128 Möglichkeiten, um _nur_ die Hashwerte zu speichern braucht man also: 2^128*128 Bit = 4*10^40 Bits oder ca. 5 Quadrilliarde Terrabyte. Und dann muss man dazu noch das Passwort speichern...

Nein, das ist nicht korrekt, das geht auch deutlich geschickter.

Es gibt den Memory-Trade-Off-Angriff. Dort tauscht man Speicherplatz gegen Rechenzeit.
Das Verhältnis ist meistens:
Rechenzeit^(2/3)
Speicherplatz^(1/3)
(Kann man aber auch entsprechend anpassen).

Das bedeutet für die Rechenzeit: (2^128)^(1/3) = 4,8E+25
Dies liegt nicht im Bereich des möglichen, sofern man keine Supercomputer besitzt.

Passwörter bis zur länge 10 können so relativ schnell, mit entsprechend viel Vorberechnungen, geknackt werden. Aber ein 10 stellen Passwort ist kein _gutes_ Passwort.

Und um diese Tabelle zu berechnet, benötigt man 2^128*x Rechenschritte (x: Rechenschritte pro MD5 Hash).

Ja, das ist korrekt.

Also dauert es (fast) ewig diese Tabellen komplett zu berechnen. Auch wenn man die Leistung aller Computer bündelt.

Gehen wir davon aus, 10 Mrd. Computer schaffen es in 1 Sekunde 10 Mrd. Hashwerte zu genieren.
Man bräuchte für die vollständige Berechnung der Tabelle immernoch ca. 107 Mrd. Jahre.

Aber dieses Verfahren funktioniert bei allen Hashverfahren, egal ob MD5, SHA1 oder Hashverfahren auf diskreten Logarithmen.

Brute Force funktioniert immer, ja. Aber ist ja kein Brute Force bei MD5 mehr nötig, das ist ja der Witz.

Wie heißt dann der neue super Angriff? Kollisionen kann man nicht effektiv bei MD5 Berechnen, sofern die Nachricht/Passwort vorgegeben ist.
Was man sehr leicht finden kann, sind zwei verschiedene Nachrichten mit dem gleichen Hashwert, aber dies ist bei der Passwortabfrage nicht gegeben.

Sonst beweise mir das Gegenteil. Ich gab dir den Hashwert eines 10 Zeichenlangen Strings (a-z;0-9). Wenn es so trivial einfach für dich ist, dann liefern mir eine Kollision. Das Passwort hat _nur_ eine stärke von 50 Bit.

Bei schlechten Passwörtern hilft das beste Hashverfahren nicht, dafür ist der User zuständig....

Schlechte Paßwörter gibt es bei Brute Force nicht, da sind alle gleich.

Wenn ich weiß das der User ein 4 Zeichen langes Passwort wählt, dann kann ich das Passwort deutlich schneller knacken, als wenn der User ein 16 Zeichen langes Passwort wählt.

Denn: 32^4 = 1048576 Möglichkeiten (mit PHP Script lösbar)
32^16 = 1,20893E+24 Möglichkeiten

Grüße
Elderan

[Christoph Zurnieden]

Hi,

'tschuldigung, hatte den hier ganz übersehen, war keine Absicht.

Probiere selber: http://passcracking.com/
Der nimmt übrigens auch Deinen heißgeliebten Hexstring an ;-)
Wer lesen kann:

Der sollte das auch tun.
Das verlinkte Projekt war als Beispiel für die Tabellenmethode gedacht und die weiterführenden Links auf eben dieser Seite sind ebenfalls nützlich.

This project is dedicated to crack md5 hashes online through web interface. At the moment we can crack md5 hashes in this character range: a-z;0-9 [8]
Dies entspricht: 32^8 bzw. ca. 2^40.
Natürlich weiß man, dass ein 40 Bit Passwort deutlich zu schlecht ist.

Nö, wieso sollte es _prinzipiell_ zu schlecht sein?

Benutzt man allerdings ein 12 Stellenpasswort a-z;A-Z;0-9 ergibt sich daraus:
62^12 bzw. ca. 2^72. Dieses Passwort ist gegen normale Personen ausreichen sicher, denn die durchschnittlich Laufzeit O(2^71) ist noch zu groß für den Personen ohne super Computer.

Du solltest Dich unbedingt mal über das Geburtstagsproblem kundig machen (und über Komplexitätsberechnung und deren Darstellung, aber das nur am Rande).
Es wird ja nicht nach _dem_ Paßwort gesucht sondern nach _einem_ Paßwort, das zum selbem Hash führt, also einer Kollision. Zudem macht es keine Sinn größere Paßwörter zu nehmen, als der Hash lang ist. Die so mögliche maximale Länge ergibt sich demnach aus dem zur Verfügung stehendem Alphabet und der Tatsache, das die Eingabe Charweise (in den verbreiteten Architekturen entspricht ein Char einem achtbittigem Byte) erfolgt.
Wieviele Versuche jetzt noch benötigt werden, um ein 12-stelliges Paßwort aus [a-zA-Z0-9] zu finden bleibt Dir zur Fingerübung überlassen. Der Hardwareaufwand, sowas innerhalb von 24h zu finden dürfte mittlerweile bis auf rund 2.500 EUR herunter sein.

Was für ein Paßwort das ist interessiert nicht, da lediglich ein String gesucht wird, der zum selbem Hash führt.
Aber es macht Sinn, diesen String im kleineren Raum zu suchen.

Klar, wenn man es eingrenzen kann. Aber so speziell wollte ich gar nicht werden, deshalb habe ich dafür ja auch die Seite verlinkt.

Um eine Kollision zu finden, ist Brute Force die schnellste Möglichkeit bei MD5, sofern die Nachricht vorgegeben ist.

Was verstehst Du unter "sofern die Nachricht vorgegeben ist"?

Allerdings braucht man dann für eine Kollision durchschnittlich 2^127 Berechnungen.

Nein, das ist nicht korrekt.

Da aber Passwörter i.d.R. schlecht gewählt sind, überprüfe ich erst die Strings mit einer Länge von 1,2,3,4,5,6,7,8.
Da braucht man nur ca. 2^40 Berechnungen.

Nein, noch nicht einmal die.

Das bedeutet für die Rechenzeit: (2^128)^(1/3) = 4,8E+25

Das ist falsch.

Dies liegt nicht im Bereich des möglichen, sofern man keine Supercomputer besitzt.

Selbst dafür braucht man keine Supercomputer mehr. Zudem würde ich bei genügend Geld dafür dezidierte Hardware einsetzen, keine allgemeinen Rechenknechte.

Passwörter bis zur länge 10 können so relativ schnell, mit entsprechend viel Vorberechnungen, geknackt werden. Aber ein 10 stellen Passwort ist kein _gutes_ Passwort.

Wie kommst Du nur immer auf sowas? Selbstverständlich kann ein 10-stelliges Paßwort auch ein gutes Paßwort sein.

Und um diese Tabelle zu berechnet, benötigt man 2^128*x Rechenschritte (x: Rechenschritte pro MD5 Hash).

Ja, das ist korrekt.
Also dauert es (fast) ewig diese Tabellen komplett zu berechnen. Auch wenn man die Leistung aller Computer bündelt.

Ja, das ist korrekt. Jedoch benötigt man nicht alle 2^128. Bei weitem nicht.

Wie heißt dann der neue super Angriff? Kollisionen kann man nicht effektiv bei MD5 Berechnen, sofern die Nachricht/Passwort vorgegeben ist.

Das verstehe ich nicht, was meinst Du damit?

Was man sehr leicht finden kann, sind zwei verschiedene Nachrichten mit dem gleichen Hashwert, aber dies ist bei der Passwortabfrage nicht gegeben.

Doch, genau das ist ebenfalls gegeben. Es wird nicht das originale Paßwort gesucht (das eh nicht zu finden ist, wenn das Paßwort länger ist als der Hash) sondern ein Paßwort, das zu dem gleichem Hash führt.

Sonst beweise mir das Gegenteil. Ich gab dir den Hashwert eines 10 Zeichenlangen Strings (a-z;0-9). Wenn es so trivial einfach für dich ist, dann liefern mir eine Kollision. Das Passwort hat _nur_ eine stärke von 50 Bit.

Ich befürchte Du _willst_ einfach nicht verstehen, oder? Soll ich Dir das wirklich mathematisch beweisen? Denn eine anderen Beweis wirst Du nicht bekommen, da auch ich keine anderen Beweis als den mathematischen akzeptieren würde. Immerhin könnte gleich der erste zufällig gewählte String auf den Hash passen und das beweist höchstens das es keinen Gott gibt aber mehr auch nicht.

Bei schlechten Passwörtern hilft das beste Hashverfahren nicht, dafür ist der User zuständig....

Schlechte Paßwörter gibt es bei Brute Force nicht, da sind alle gleich.
Wenn ich weiß

Ich ging bis jetzt nicht von Vorwissen aus.

das der User ein 4 Zeichen langes Passwort wählt, dann kann ich das Passwort deutlich schneller knacken, als wenn der User ein 16 Zeichen langes Passwort wählt.

Das funktioniert, weil Du es _weißt_, nicht weil es einfacher ist.

Denn: 32^4 = 1048576 Möglichkeiten (mit PHP Script lösbar)
32^16 = 1,20893E+24 Möglichkeiten

Naja, das hätte ich sogar noch im Kopf gekonnt, dafür brauche ich keinen Taschenrechner oder gar ein PHP-Script ;-)

so short

Christoph Zurnieden

[Christian Kruse]

你好 Elderan,

Außerdem kann man den Hash dann auch sicher per Email übertragen, denn
dort wird i.d.R. nur 7 Bit pro Zeichen benutzt.

Du meinst die 7bit, die bei 9 von 10 Mails als Content-Transfer-Encoding:
8bit angegeben werden? ;)

Nene, die Zeiten, in denen man in Mails nur 7 Bit benutzt hat, sind schon
länger vorbei ;)

再见,
 克里斯蒂安

[Henryk Plötz]

Moin,

Existiert dazu ein gängiger Algorithmus?

Ja, MD5.

Key: abcdefghijklmnop (16 Byte = 128 Bit)

Mit Verlaub, was soll das? Wenn du den Benutzer ohnehin einen 16-Byte-Schlüssel eingeben lässt, ist es Jacke wie Hose ob du den erst kompliziert aussehend verwurschelst oder direkt als Schlüssel in den Algorithmus gibst. Bestenfalls gewinnst du beim verwurschteln nichts, schlimmstenfalls verlierst du Entropie. Zumal der OP explizit ein Passwort beliebiger Länge haben will.

Die übliche Vorgehensweise ist dann wirklich einen beliebigen Hash mit mindestens 128 Bit Länge zu nehmen, und dann das Nutzerpasswort (ggbf. mit Salt) da reinzustecken.
MD5 ist zwar gebrochen, aber das sollte in dieser Anwendung keinen Unterschied machen.

Wenn man will, kann man bei diesem Schritt auch gleich Wörterbuchangriffe auf das Passwort erschweren: Beim ersten Verschlüsseln einen zufälligen Saltwert erzeugen und dann das Passwort zusammen mit dem Salt ein paar (Hundert/Tausend/Millionen/whatever) mal hashen und das Ergebnis als Schlüssel benutzen (Salt und Iterationszahl müssten dann im Klartext zum verschlüsselten Text mitgegeben werden). Ein Angreifer der nicht direkt den Key (128 Bit) sondern das Passwort (gute Passwörter haben ~6 Bit pro Zeichen; die meisten Passwörter sind aber nicht gut) angreifen will müsste dann die mehrfachen Hashoperationen ebenfalls durchführen (naja, man kann auch eine Abkürzung für "n-mal Hash mit Salt x" suchen, aber das ist auch nicht wirklich einfach) was ihn hoffentlich deutlich ausbremst, während es den legitimen Benutzer nicht wirklich stört, wenn er nach Eingabe seines Passwortes 1s warten muss bis die Iterationen durch sind.