Regenbogen-Tabellen funktionieren doch nur bei Hashing ohne Salt. Zumindest wenn ich es richtig im Kopf habe, die Zeit, dass ich mich damit beschäftigt habe, ist schon etwas her.
Nein, sie funktionieren auch wunderbar bei Hashes mit Salt - wenn nun jedes Passwort gleich versalzen ist (und nicht durch ein anderes Merkmal), ist dies sogar problematisch. Die Tabelle muss natürlich entsprechend größer sein.
Angenommen die vorangestellte Salt-Komponente ist "12" und das Klartextpassword ist "3456", so wäre der Hash für 123456 vermutlich einfach in einer Rainbow-Table zu finden.
Das Klartextpasswort ist dann offensichtlich nicht 123456 und es ist ohne Brute Force oder Trial & Error nicht herrauszufinden, was die Salt-Komponente ist.
Hat man nun ein weiteres Password - z.B. 7890 lässt sich aus dieser Information die Salt Komponente ermitteln und noch wesentlich effizenter eine Rainbow-Table erstellen. - Aus dem Grund ist es praktikabel, einen Salt so zu erstellen, dass er bei jedem Datensatz verschieden ist, um diesen Angriffspunkt von vorne herrein auszuschließen - aber mit einer entsprechend großen Rainbow-Table wird man auch diese Passwörter irgendwann knacken.
Das hilft allerdings alles nix, wenn jemand die Datenbank klaut - es ist halt nur aufwändiger, weil für jeden Hash dann eine eigene Tabelle erstellt werden muss.
Das habe ich auch nicht behauptet :) MD5 war nur der einzige Hashing-Algorithmus, der mir auf die Schnelle eingefallen ist, der erst kürzlich als problematisch eingestuft wurde.
Das Problem ist aber auf dem Papier und praktisch nicht einsetzbar - problematisch wirds erst, wenn Kollisionsangriffe möglich sind (wie das etwa bei SHA-1 der Fall ist).