Moin Moin!
Moment, er dampft doch nicht die daten auf 32 Byte ein sondern produziert eine Checksumme der Daten um zu schauen ob sie verändert wurden oder nicht. Eine Checksumme kann durchaus viel kürzer sein als die daten selbst und trotzdem mit extrem hoher Wahrscheinlichkeit Aussagen über die Gleichheit machen,
Nö. Der Vergleich zweier Prüfsummen sagt nur aus, dass die Ursprungsdaten ungleich sind, wenn die Prüfsummen ungleich sind. Bei identischen Prüfsummen können die Ursprungsdaten immer noch ungleich sein (Hash-Kollision).
es kommt halt auf den Algorythmus drauf an der die Checksumme berechnet.
Nein, das Problem bleibt. Prüfsummen-Vergleiche sagen nichts über Gleichheit aus, nur über Ungleichheit.
Man sollte sich für Passwörter einen suchen der cryptographisch noch nicht geknackt wurde.
Salz nicht vergessen!
Der gängige Weg, salted Hashes, geht davon aus, dass Hash-Kollisionen innerhalb der relativ überschaubaren Menge aller zugelassenen Passworte sehr unwahrscheinlich sind, und nimmt das Risiko in Kauf, des es doch vielleicht einige Tupel von Passworten gibt, die den selben Hash-Wert haben. Benutzer, die so ein Passwort gewählt haben, können sich dann auch mit einem zweiten Passwort anmelden, dass den selben Hash-Wert liefert.
Das pro Benutzer zufällig vergebene Salt-Wert sorgt dafür, dass ein Angreifer erstens nicht aus Hash-Wert und bekanntem Passwort eines Accounts (z.B. des eigenen) auf das Passwort eines anderen Accounts schließen kann, und zweitens verhindert der Salt-Wert den sinnvollen Einsatz von Rainbow-Tables.
Alexander
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".