nicht angemeldet
Dass ein 8-stelliges Passwort mit einem anderen 8-stelligen String kollidiert ist sehr unwahrscheinlich, dass eine 64-Byte-Zeichenwurst mit einer anderen 64-Byte-Zeichenwurst kolidiert ist bei einem 32-bit-Hash schon sehr wahrscheinlich.
Nein. Die Wahrscheinlichkeit einer Kollision von zwei (festen) 64-Byte-Zeichenwuersten[TM] ist genau so hoch wie die zweier 8-Byte Strings. Die Gefahr von Kollisionen wird nur dann gross, wenn die Menge(!) der infrage kommenden (bzw. vom Angreifer geprueften) Passwoerter gross im Vergleich zur Laenge der Hashs ist.
Erwischt - Erklärungsfehler :) Ich wollte eigentlich sagen, dass die Menge der 8-stelligen Passwörter mit einem definierten Zeichenvorrat kleiner ist als die Menge der 64-stelligen Passwörter mit einem definierten Zeichenvorrat und die Wahrscheinlichkeit einer Kollision über die gesamte Menge der jeweiligen Passwörter beim Erstellen einer vollständigen Tabelle aller Klartexte -> Hashes größert ist.
Wenn man jeweils nur zwei Passwörter hat, ist die Wahrscheinlichkeit einer Kollision gleich groß (wenn man Faktoren wie die Maximallänge der Eingabezeichenkette nicht beachtet).
weil eine vernuenftige Invertierungsfunktion (zum Berechnen der Ketten), die auf den Raum der Woerter mit einem Praefix aus dem Woertbuch beschraenkt ist, wohl kaum zu konstruieren ist (schaetze ich mal (?)).
Das halte ich für ein Gerücht :) Es ist keine Hexerei die Reduktionsfunkion so zu schreiben, dass sie an das neue Passwort in der Kette einfach wieder den Salt in definierter Form anhängt.
klartext+salt -> hash(0) -> reduktion(0)+salt -> hash(1) ...
Wenn der Salt hingegen geheim ist, ist man ohnehin "aufgeschmissen" und benötigt etwas mehr Zeit.
Auf der anderen Seite - wenn man es doch hinbekommen wuerde, dafuer ne vernuenftige Rainbow-Tabelle zu berechnen: Die Menge der Klartexte ist dann ca. 100.000 * 2^128, also ca. 2^142 oder so. Nehme ich einen SHA-2-Hash mit 256 bit, dann gibt es also ca. 2^114 mal so viele Hashs wie potentielle Passwoerter. Kollisionen gibt es also eventuell keine einzige, jedenfalls nur sehr wenige (obwohl man die Wahrscheinlichkeit von Kollisionen auch nicht unterschaetzen darf).
Wenn der Salt unbekannt ist, der Algorithmus aber schon hilft bei möglichen gefundenen Klartexten ansich nur Brute-Force - ausser man hat den Fall "Dämliches Passwort".
Annahme hash(salt+password), der mögliche Klartext ist "R(c)Y)(A}kmk3o5s|F)7sYz1)!" - so ist unmöglich zu unterscheiden ob der Salt nun "R(c)Y)(A}" und das Passwort "kmk3o5s|F)7sYz1)!" ist oder doch "R(c)Y)(A}kmk3o" und "5s|F)7sYz1)!". Bei einem dämlichen Passwort hingegen wirds schon einfacher "R(c)Y)(A}kmk3o5s|F123456890" - was wird da wohl das Passwort sein? :)
Es ist halt immer eine Ermessenssache wie man die Passwörter seiner Mitglieder absichert - bei einem dämlichen Passwort kann ein Salt gefährlich sein, wenn es darum geht das dämliche Passwort zu schützen :)
Meine Meinung ist also: Der Gefahr von Kollisionen sollte mit der richtigen Hash-Funktion entgegengewirkt werden (auch wenn man sie natuerlich damit nicht ausschliessen kann).
Ohne Salt wäre ein Kollision ein Problem - allerdings nur, wenn die Möglichkeit einer Preimage-Attacke besteht und ein Account gezielt angegriffen wird, das eigentliche Passwort aber irrelevant ist - eine zufällige Kollision (Geburtstagsproblem) ist, wie du sagst, extrem unwahrscheinlich.
Meines wissens gibts aber auch für MD5 immer noch keine Möglichkeit zu einem Preimage-Angriff.