Verständnisproblem bei salted hashs: Wo wird das Salt gespeichert?

Hallo,

ich beschäftige mich aktuell mit der Möglichkeit Passwörter einigermaßen sicher in einer Datenbank zu speichern. Ich bin dabei auf salted hashs gestoßen (BCrypt.net - Strong Password Hashing for .NET and Mono).

Ich kann bisher problemlos salts und mit diesen wiederum hashs erzeugen. Was ich jetzt aber nicht so ganz kapiere ist, das ich den verwendeten salt ja theoretisch zusammen mit dem gehashten Passwort in der Datenbank speichern müsste, um später mit dem gleichen salt die Benutzeingabe umwandeln und vergleichen zu können. Das macht aber doch gar keinen Sinn, weil ein potentieller Datenbankeindringling ja dann auch sämtliche salts zu den gehashten Passwörtern sehen würde, was doch wiederum eine BruteForce-Attacke möglich macht.

Verstehe ich da irgendwie komplett irgendwas falsch oder wo ist hier jetzt mein Denkfehler?

Hallo Maddinel,

der Salt wird zusammen mit dem Gehashten Passwort in der Tabelle gespeichert. Der Sinn eines Salzes ist es ja die Anwendung von Rainbow-Tables unmöglich zu machen. Der Datenbankeindringling würde immer noch nahezu ewig brauchen für jeden Salt (!) eine neue Rainbow-Table berechnen zu müssen - selbst wenn er die Salts kennt.

Gruß,
Markus 😃

PS: Und die Brute-Force-Attacke EDIT nach herbivores Beitrag: funktioniert nicht, weil du beim Login auf der Seite oder im System ja immer noch einen Salt anhängst... wird dadurch auch nicht weniger aufwändig als ohne Salt.

Hallo Maddinel,

ich bin da auch nicht der ganz große Experte, versuchs aber trotzdem mal:

Das Problem bei z.B. MD5 ohne Salt ist, dass es große (Regenbogen-)Tabellen gibt, in denen schon alles (vor)-berechnet ist und man einfach und quasi in Nullzeit nachschlagen kann. Mit Salt ist das schon mal ausgeschlossen, selbst wenn der Salt-Wert dem Angreifer bekannt ist. Der Aufwand steigt dann von Null auf "normales" BruteForce.

Das würde man schon erreichen, wenn man einen festen Salt-Wert hat, der dann nicht in der DB-stehen muss, sondern einfach direkt (wenn auch vielleicht verschleiert) in der EXE stecken kann.

Man kann den Salt-Wert aber auch für jeden Benutzernamen unterschiedlich machen, ohne dass man ihn sich merken muss, wenn man ihn einfach aus dem Benutzernamen berechnet. Dann steckt die Information wieder nur in der EXE, diesmal in Form eines passenden Algorithmus.

Natürlich kann sowohl ein fester Salt-Wert als auch ein Algorithmus von einem Angreifer aus der EXE extrahiert werden. Aber zum einen erhöht das Aufwand für den Angreifer und zum anderen bleibt der Eingangs geschilderte Vorteil auf jeden Fall erhalten.

herbivore

Um das vielleicht noch mal deutlicher zu formulieren. Der Sinn des Salts ist es, das Passwort länger zu machen. Es gibt Rainbowtables, wo Passwörter mit Längen bis zu 14 Zeichen vorberechnet sind. Wenn man an das Passwort noch einen zufälligen, langen String anhängt, muss sich der Benutzer dann zwar nicht merken, dem Angreifer nützen seine Rainbowtables aber auch nichts mehr, weil das Passwort effektiv deutlich länger ist und nicht mehr in der Rainbowtable enthalten.

JETZT hab ichs verstanden. 🙂 Dank an alle Erklärer!