Hi Alex.
Ergänzend zu dedlfix' Antwort:
Wäre es anstatt (oder neben) Salts nicht auch sinnvoll, das Passwort in der Datenbank mehrmals zu speichern und dabei jeweils unterschiedliche Verschlüsselungsalgorithmen zu verwenden?
Die Antwort ist eindeutig 'Nein'. Das Thema Kollisionen spielt (in diesem Szenario) eine viel kleinere Rolle, als man vielleicht denken mag. Bei einem guten Hash-Algorithmus findet ein Angreifer *überhaupt*kein* Urbild zu einem gegebenen Hash - falls doch, hat der Algorithmus bereits versagt.
Mal ne kurze Rechnung:
Nehmen wir mal an, wir bilden Hash-Werte von Strings von Länge 32 (Passwort + ggf. Salt). Bei einem Alphabet von, sagen wir, 80 Zeichen (Groß-/Kleinbuchstaben, Ziffern und ein paar andere), haben wir 32^80 mögliche Strings, die in Frage kommen, also (2^5)^80 = 2^400.
Ungefähr in der Größenordnung - ganz grob - ist auch die Anzahl der Hash-Werte (2^128 bei MD5, bis zu 2^512 bei SHA-2). Wenn wir also von SHA-2 ausgehen, dann ist erstmal genug "Platz" da, damit es bei unseren Wörtern nicht notwendigerweise viele Kollisionen gibt, und bei einem guten Hash-Algorithmus gibt es die auch nicht.
Selbst wenn, mal hypothetisch, im Schnitt jeweils eine Million (= ca. 2^20) unserer möglichen Passwörter kollidieren und denselbern Hash-Wert haben, dann müssen wir im Schnitt 2^400 / 2^20 = 2^380 mögliche Passwörter ausprobieren, um eines dieser 1 Millionen Urbilder zu finden. Das ist immer noch *viel* zu viel.
Soll heißen: Du kannst einen Hash-Algorithmus bereits als unbrauchbar ansehen, wenn ein Angreifer irgendein(!) Urbild eines Hash-Wertes finden kann - das bedeutet nämlich, dass er viel zu leichte Urbild-Attacken liefert. Du brauchst also für Deine Website-Nutzerverwaltung auf das Kollisionsproblem keinerlei Rücksicht zu nehmen.
Viele Grüße,
der Bademeister