suit: Vorteile ein Passwort mit "Salt" zu speichern

Beitrag lesen

Ah ok, jetzt hab auch ich begriffen, was Du meinst. Grundsaetzlich Zustimmung - allerdings sollten(!) Kollisionen grundsaetzlich kein zu hoch zu bewertendes Sicherheitsproblem sein - wenn sie es doch sind, ist die benutzte Hash-Funktion schlecht gewaehlt.

Jein - wenn die Kollisionen absichtlich erzeugt werden können (Preimage) ist es ein Problem, wenn die Kollisionen zufällig entstehen lässt sich das aber nicht vermeiden.

Bei einer Kollision ist zwar das Passwort sicher, das Login selbst aber nicht - das kann auch ein Sicherheitsproblem sein, wenn z.B. das Ziel des Angriffs das geschütze System nicht aber das Passwort ist.

Wenn Du etwa einen 8-Byte-Salt anhaengst und die Rainbow-Tabelle "gleich gross" (im Sinne von Speicherbedarf) sein soll, dann muss jede Kette um den Faktor 2^16 verlaengert werden, um die gleiche Trefferwahrscheinlichkeit beim Abgleich mit einem einzelnen Passwort zu haben. Das macht schon einen kleinen Unterschied.

Natürlich :) darum schrieb ich "nicht notwendigerweise".

Unter der Groesse einer Rainbow-Tabelle verstand (und verstehe) ich die Anzahl der anhand ihr auffindbaren Passwoerter.

Verstanden.

Alles andere ist doch unsinnig als Mass. Wie gross der Speicherbedarf beim Angreifer fuer seine Rainbow-Tabellen ist, ist doch wirklich sein Problem :-)

Ja, genau das ist ja eines der Probleme von Wörterbüchern oder Vorberechneten Hash -> Klartexttabellen. Der Speicherplatz. Der einzige Sinn eine Rainbow-Table ist es, den Speicherplatz klein zu halten oder bei derselben Größe mehr potentielle Klartexte abzudecken.

Du bist irgendwie sehr viel weniger gelassen als ich in Bezug auf Kollisionen. Da musste ma lockerer werden ;-)

Schon klar, dass Kollisionen recht unwahrscheinlich sind, aber je länger die Zeichenketten werden, desto wahrscheinlicher ist, dass es Kollisionen mit ähnlicher länge gibt.

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.