Mathematik zum Montag

[1unitedpower]

In seinem Skript hat der Indianerversteher doch gezeigt wie er es macht. Er verwendet rand() pro Stelle des hashes, also mehrfach.

Damit vergrößert sich aber nicht der Zufallsraum. rand ist eine deterministische Funktion, die ausschließlich von dem Startwert abhängt, dem sogenannten Seed. Es gibt 2^32-1 mögliche Startwerte. Wenn rand 16 mal aufgerufen wird, wird die Sequenz nicht zufälliger. Die 16 Zufallswerte sind vollständig durch den Startwert vorherbestimmt. Egal wie oft man rand aufruft, am Ende bleiben maximal 2^32-1 mögliche Salts, die man für eine fixe Länge generieren kann. Er hätte rand auch nur ein einziges mal aufrufen können, das hätte das System nicht unsicherer, sondern nur schneller gemacht. Das wiederholte Aufrufen von rand hat defakto nicht den geringsten Einfluss auf die Anzahl der möglichen Salts, die man damit generieren kann.

Ein kryptografisch sicherer Zufallsgenerator, hat diese Einschränkung nicht. Damit lassen sich mehr Zufallszahlen als die angesprochenen 2^32 erzeugen. OWASP empfiehlt mindestens 8^32, besser 8^64 Möglichkeiten. Mit einem kryptografisch sicheren Zufallsgenerator lassen sich so viele Möglichkeiten erzeugen, mit Pseudozufall bleibt man weit darunter. Das ist ein enormer Unterschied, um das mal in ein Verhältnis zu setzen: (2^32 / 8^32) ~= 7.8886091e-31, (2^32 / 8^64) ~= 9.9568244e-60. Da liegt Indianerverstehers Schätzung mit "20% schlechter" völlig abseits der Realtiät.

Ein Angreifer, der über ausreichend Ressourcen verfügt, kann das nutzen, um eine Regenbogen-Tabelle oder eine Lookup-Tabelle für die 2^32 möglichen Salts vorzuberechnen. Wenn er dann in den Besitz eines Passwort-Hashes gelangt, kann er die Tabelle nutzen, um eine Passwort-Kollision zu finden. Das ist ein erheblicher Time/Space-Tradeoff zugunsten des Angreifers.

Eine andere Angriffsfläche bietet der initiale Seed, der muss ja schließlich auch aus einer Zufallsquelle gespeist werden. Das ist häufig eine Kombination aus Serverzeit, Prozess-ID und noch ein paar anderen Faktoren. Das sind scheinbar schwer von außen zu ermittelnde Faktoren, aber sie liefern trotzdem deutlich weniger Entropie als ein Hardware-Device, das bspw. akkustisches Rauschen aus der Umgebung aufnimmt, das bei kryptografischen Zufallsgeneratoren eingesetzt wird.