Statt md5(str) - Das, was heise vorschlug in einf. Code gegossen

[Sven Rautenberg]

Moin!

Wenn man mit srand() seedet, erzeugt rand() immer die gleiche Zufallszahlenreihenfolge.

Ich sehe ganz deutlich das Wort "wenn". Ich sah in meinem Beispiel kein srand(). Was also, wenn nicht? Was also wenn nicht einmal bekannt ist, wann und wie oft rand() aufgerufen wurde um wann den salt für welchen Hash zu bilden? Richtig. Dann mischt der echte, software- und maschinenunabhängige Zufall genügend mit.

Es gibt wohl den dokumentierten Fall, dass der Einsatz der Software A (nennen wir sie zum Beispiel Wordpress) und die damit verbundene Nutzung eines ungeseedeten rand()-Zufallszahlengenerators zur Passworterzeugung (also so, wie man es machen sollte) kompromittiert wurde durch den parallelen Einsatz der Software B (beispielsweise nehmen wir PHPBB an), die den Zufallszahlengenerator für unwesentliche Dinge wie zufällige Bild- und Farbdarstellung hernahm, und dummerweise einen schlechten, vorhersagbaren Seed anwendete.

Details müsste ich aufwendig googlen, das ist im Moment nicht die richtige Zeit - allein diese Konstruktion, auch nur theoretisch durchdacht, ist in meinen Augen nachvollziehbar, da der Seed der Zufallszahlen für alle PHP-Prozesse eine globale Ressource ist.

Mit bekanntem Seed und nur einer unbekannten Anzahl von rand()-Aufrufen ist die einzige "Sicherheit", dass der Angreifer zu doof ist, die diversen Möglichkeiten durchzuspielen.

selbst ETWAS wie ein simples

srand(microtime(true) - intval(str_replace(' ','', str_replace('.','', file_get_contents('/proc/uptime')))));

> dürfte einen Angreifer vor erhebliche Probleme stellen.  
  
Microtime ist grob bekannt. Wenn man's möchte, ist /proc/uptime ein Wert nahe Null (Maschine durch Überlast zum Neustart zwingen, oder Neustart durch Dauer-Ping beobachten). Oder er ist PHP\_INT\_MAX groß - das ist bei 32-Bit-Linux-Systemen, sowie derzeit auch bei 64-Bit-Windows-PHP 2147483647.  
  
Man zieht also eine bekannte Konstante von der aktuellen Zeit ab. FAIL!  
  

> > Aber wer sagt denn, dass man Rainbow-Tabellen erzeugen muss, wenn man durch unsicheren Zufall das Brute-Force einfacher haben kann?  
>   
> Weil ja immer noch das Passwort aus einem Hash erraten werden muss und Rainbow-Tabellem für "lange" Strings wenig praktikabel sind?  
  
Rainbow-Tabellen werden kaum noch genutzt. Sie bringen keinen wirklichen Gewinn mehr. Der Aufwand der Erzeugung und Speicherung steht in keinem Verhältnis zur schlichten Bearbeitung mit Brute Force und relativ günstiger Hardware.  
  
 - Sven Rautenberg