Das halte ich für eine dumme Frage, aber ich bin ziemlich verwirrt darüber, was ich hier zum Besten tun soll.Sollte das Salz für ein Passwort Hash auch "gehashed" werden?
Beim Salzen eines Passwort-Hash, sollte das Salz auch gehashed oder als Klartext übrig sein?
HINWEIS: Ich hasse ein Passwort in SHA-256 und das Salt ist eine vordefinierte Zeichenfolge, da immer nur ein Passwort gespeichert wird.
TIA
Chris (Shamballa).
Es spielt keine Rolle.
Der Zweck eines Salzes ist es, Angriffe vor der Berechnung zu verhindern.
Wie auch immer, das Hashing des Salzes oder die Verwendung selbst führen dazu, dass die gleichen Daten jedes Mal als Salz hinzugefügt werden. Wenn Sie das Salz hacken, ändern Sie effektiv nur das Salz. Wenn Sie es zuerst hashen, konvertieren Sie es in eine andere Zeichenfolge, die dann als Salz verwendet wird. Es gibt keinen Grund, dies zu tun, aber es wird nichts falsch machen, wenn Sie es tun.
Sie müssen nur konsistent sein und die gleiche Methode jedes Mal verwenden oder Sie werden mit einem anderen Passwort-Hash enden.
Das Salz sollte nicht gehashed werden, da Sie den ursprünglichen Wert mit dem Kennwort kombinieren müssen, bevor Sie es hashen.
Sie dürfen das Salz nicht hacken, da Hashes in einer Richtung sind. Sie benötigen das Salz, damit Sie es vor dem Hashing zum Passwort hinzufügen können. Sie könnten es verschlüsseln, aber es ist nicht notwendig.
Die entscheidende Sache über Salze ist, dass jedes Passwort sein eigenes Salz haben sollte. Im Idealfall sollte jedes Salz einzigartig sein, aber zufällig ist auch gut. Das Salz sollte daher lang genug sein, damit es für jedes Passwort eindeutig ist.
Wenn alle Salze gleich sind, ist es für den Cracker (der Ihre Hashwerte sehen kann) offensichtlich, welche Konten dasselbe Passwort haben. Die Hash-Werte sind gleich. Das heißt, wenn sie ein Passwort knacken, erhalten sie mehr als ein Konto ohne zusätzliche Arbeit. Der Cracker könnte sogar auf diese Konten zielen.
Sie sollten davon ausgehen, dass der Cracker sowohl den Salz- als auch den Hash-Wert erhält, also muss der Hash-Algorithmus sicher sein.
Die Verwendung von Salz verhindert die Verwendung bereits vorberechneter Rainbow-Tabellen, um Ihren Hash-Wert zu knacken. Wenn Sie ein einzigartiges Salz für jedes Konto verwenden, wird Ihr Cracker Ihre eigenen Rainbow-Tabellen mit Ihrem Salz vorberechnen.
@aaaa bbbb, wenn Sie das Salz vor dem Speichern hacken, können Sie das Passwort nicht abrufen. Wenn Sie in Ihrer Generation des Salzes einen Hash-Algorithmus verwenden, ist das in Ordnung. Das Salz ist der Teil, der unmittelbar vor dem Hashing des Werts zum Klartext hinzugefügt wird. Es ist kein Salz davor. –
Nein, Sie dürfen das Salz nicht hacken. Das Salz befindet sich im Klartext und Sie müssen das Kennwort erneut berechnen und mit dem in der Hash-Kennwortdatei gespeicherten Kennwort überprüfen.
Aber wenn Sie eine starke Versalzung Prozedur benötigen, können Sie Ihr gesalzenes Passwort auf diese Weise berechnen:
SaltedHashedPwd = H (H (H (H (..... H (PWD-k + SALT-k) + SALT-k) + SALT-k) .....) + SALT-k + N
H die Hash-Funktion SALT-k ein k-zufälligen wird Zeichenfolge PWD-k als Salz verwenden, wird der k-Passwort (jedes Passwort hat ein anderes Salz) N ist die Iterationszahl, aus der die H-Funktion besteht
Im PKCS # 5-Standard wird N = 1000 verwendet!
In dieser Manne ist ein Dictionary-Angriff nicht möglich, weil für jedes Wort in das Wörterbuch und für jeden SALT in die Passwortdatei der Angreifer den Hash berechnen muss. Zu expansiv in der Zeit!
Ich denke, dass N = 100 sollte für Ihre Anwendungen :-)
Falsch. "Es ist egal" ist die richtige Antwort. Sie können das Salz hacken, was Ihnen ein neues Salz gibt, das funktioniert. Alles, was Sie tun müssen, ist konsequent. –
Sieh besser, was ich geschrieben habe. Sie können die Verkettung von PWD und SALT haben, aber am Ende müssen Sie die klare Form von SALT verketten. Andernfalls können Sie den Hash in der Überprüfungsphase nicht erneut berechnen. – robob
genug sein, als das Salz zusammen mit dem Hash gespeichert werden muss (oder zumindest muss zusammen mit dem Hash abrufbar sein), könnte ein Angreifer möglicherweise erhalten Sie sowohl das Salz als auch das Hash-Passwort. In einigen meiner Anwendungen habe ich das Salz verschlüsselt in der Datenbank gespeichert (mit einem Schlüssel, der nur der Anwendung bekannt ist). Meine Schlussfolgerung war, dass das unverschlüsselte Speichern des Salzes zusammen mit dem Hash-Passwort das Aufspüren der Passwörter erleichtern würde, da ein Hacker, der die Passworttabelle abrufen könnte (und den Hash-Algorithmus kennen oder annehmen könnte) in der Lage wäre Um Übereinstimmungen zwischen Hashes bekannter Wörter (Wörterbuchangriff) zu finden, indem man jedes Wort im Wörterbuch hasht und dann mit dem Salz salzt, zu dem er auch Zugang hat. Wenn das Salz verschlüsselt wäre, wäre ein solcher Angriff nicht möglich, es sei denn, er hätte auch Zugriff auf den Verschlüsselungsschlüssel, der der Anwendung bekannt ist.
(Wenn jemand einen Fehler in dieser Logik sieht, bitte Kommentar.)
Ich würde immer noch stark gegen die Verwendung einer statischen Salz empfehlen. Es ist wahrscheinlich der Zweck, ein Salz zu haben, selbst wenn Sie nur ein Passwort auf einmal speichern. – Slartibartfast
Ich würde zustimmen, ein anderes Salz sollte wahrscheinlich für jedes Passwort verwendet werden, Sie müssen nur das gleiche Salz jedes Mal für das Passwort eines bestimmten Benutzers verwenden. Aber der Punkt hier war, dass ein Salz nur etwas extra hinzugefügt wird. Hashing das Salz, bevor Sie es verwenden, ändert sich das nicht, es macht es nur ein anderes etwas Besonderes. –
Es ist Semantik, aber Sie dürfen kein Salz hacken. Ein Salz muss im Klartext abrufbar sein, damit es verwendet werden kann. Da ein Hash eine Möglichkeit ist, dürfen Sie Ihr Salz nicht hacken. Wenn Sie einen Hash-Algorithmus zum Generieren Ihres Salt verwenden möchten, ist das in Ordnung, aber der resultierende Hash-Wert wird zum neuen Salt und Sie müssen ihn immer noch im Klartext abrufen können. Wenn Sie Ihr Salz wirklich hacken, haben Sie Ihr Konto verloren. –