Okay. Ansonsten gilt aber: Wenn der Hash exakt X Zeichen (bspw. 32) lang ist, muss es zwangsläufig zu Kollisionen kommen — das ist aber auch eine Definition einer Hashfunktion. Die herbeigeführte Kollision (bei MD5) ist natürlich der GAU für eine Hashingfunktion, aber dabei kommt es bei Rainbow-Tabellen nicht nur an: Wenn der Hash drin ist, ist er drin. Wenn man Pech hat, dann ist hat das ultra sichere Passwort bestehend aus 30 Sonderzeichen leider den gleichen Hash wie „test12″. Würde man das im Vorfeld bereits wissen, wäre ja die Kollision herbeigeführt. Ich will damit nur sagen: Ein langes Passwort schützt nicht gegen Rainbow-Tabellen. Das ist ein Trugschluss.
Nochmals: Ich sage nicht, das lange Passwörter nicht sicher wären (im Gegenteil). Aber gegen Rainbow-Tabellen helfen sie nur bedingt. Viel einfacher und besser ist ein (mehrfaches) Salting.
Der Hersteller von 1Password (AgileBits) bietet auf seinem Blog immer wieder nette Artikel, die die Passwort-Thematik gut beschreibt.
http://blog.agilebits.com/2011/06/21/toward-better-master-passwords/
http://blog.agilebits.com/2012/06/06/a-salt-free-diet-is-bad-for-your-security/
http://blog.agilebits.com/2012/06/07/flames-and-collisions/
und der schöne Antwort auf den vllt bekannten XKCD-Comic: http://blog.agilebits.com/2011/08/10/better-master-passwords-the-geek-edition/