Es hängt von der Hash-Funktion ab.

Bei einem zufälligen Orakel (das die "ideale Hash-Funktion" ist) gibt es keinen Unterschied, wie Sie Salt und Passwort zusammensetzen, solange beide gehen hinein.

Bei echten Live-Hash-Funktionen kann es zu Unterschieden in der Position der Eingabe kommen (z. B. gibt es Erweiterungsangriffe).

Aber dann möchten Sie normalerweise verwenden Einige spezielle Passwort-Hashing-Schemata wie PBKDF-2, bcrypt oder scrypt, die bereits mit drei Eingaben erstellt wurden, von denen eine das Passwort und die andere das Salz ist (die dritte der Arbeitsfaktor). Verwenden Sie sie einfach so, wie sie verwendet werden sollen.

Was dieser Artikel bedeuten könnte, ist, dass das Platzieren des Salzes irgendwo in der Mitte des Passworts angeblich die Wahrscheinlichkeit erhöht, durch einen Wörterbuchangriff oder durch brutale Gewalt geknackt zu werden, da die Regeln zum tatsächlichen Erstellen desselben Hashs nicht implementiert werden konnten in Ihrem Passwort-Cracker Ihrer Wahl. In Wirklichkeit ist dies wahrscheinlich völliger Unsinn.

Wie funktioniert das?

Wenn Sie ein Programm wie John the Ripper a nehmen >, Sie füttern es mit Ihrer Passwortdatei wie folgt (nicht mit der genauen Syntax):

  Benutzername: Passwort: salt  

Dann übergeben Sie das Format als Ein Parameter, mit dem der Hash Ihrer Meinung nach generiert wird. Dies kann sein:

  md5 (Durchgang + Salz) md5 (Salz + Durchgang) md5 (md5 (Durchgang) + md5 (Salz)) md5 (Durchgang + md5 (Salz)) md5 (md5 (... (Salz + Pass + Salz) ...)) ... und so weiter.  

John the Ripper wird mit einem vorgefertigten Satz von etwa 16 Unterformaten geliefert, aus denen Sie auswählen können

Das Salt irgendwo in das Passwort einzufügen würde wahrscheinlich so aussehen:

  md5 (password.substring (0,4) + salt + password.substring (4, end))  

Um eine solche Technik zu verwenden, müssen Sie zunächst ein kleines Plugin für John schreiben, bevor Sie mit dem Knacken beginnen können (was überhaupt kein Problem sein sollte).

Außerdem verfügen Sie als Angreifer möglicherweise über eine Liste von Hashes + Salzen unbekannter Herkunft und wissen nicht, wie ein Hash zusammengesetzt ist. Dies ist selten der Fall. Wenn es Ihnen als Angreifer gelingt, Hashes und Salze aus einer Datenbank zu extrahieren, finden Sie wahrscheinlich entweder eine Möglichkeit, den Passwort-Hashing-Algorithmus der Website zu extrahieren, oder Sie erstellen einfach ein neues Konto mit einem bekannten Passwort, extrahieren den Hash und das Salt für it und brute erzwingen den Algorithmus, der zum Erstellen des endgültigen Hashs verwendet wurde (was mehr oder weniger herausfordernd sein kann).

Alles in allem ist es fast völlig willkürlich, wo Sie das Salz einfüllen und ob Sie den Hashing-Algorithmus zehntausend Mal wiederholen oder nicht. Dies bietet KEINE signifikante Sicherheit.

Wenn Sie Sicherheit wünschen, können Sie dies viel besser tun, indem Sie einen besseren Hashing-Algorithmus oder bcrypt oder etwas anderes verwenden, das rechenintensiv ist.

Es ist besser, am Anfang der Eingabezeichenfolge Zufälligkeit zu haben als am Ende.

Wenn das Salt ein konstanter Wert für alle Passwörter ist, ist es einfacher, mehrere Passwörter zu erzwingen, wenn das Salt wird angewendet als:

  Hash (Salt. Passwort)  

anstelle von

  Hash (Passwort. Salt)  

Der Grund ist einfach, dass einige (und ich denke, sowohl md5 als auch sha-1 passen zu dieser Beschreibung) Hashing-Algorithmen iterativ sind - und wenn die Zeichenfolge, die Sie hashen, mit einem bekannten konstanten Wert beginnt, ist dies der Fall Es ist möglich, einen Cracking-Versuch mit dem Ergebnis des Haschens des Salzes zu starten, wodurch die Vorteile des Versalzens Ihrer Passwörter beseitigt werden.

Wenn die Salzwerte passwortspezifisch sind (was sie sein sollten), gilt das oben Gesagte nicht und Das Salz ist wahrscheinlich zufälliger als das Passwort selbst. Aus diesem Grund ist es besser, das Salz voranzustellen - obwohl der Unterschied / Nutzen vernachlässigbar ist.

Der Vorschlag, das Salz in die Mitte der Eingabezeichenfolge einzufügen, ist wahrscheinlich eine weitere Möglichkeit, die Eingabezeichenfolge nicht mit zu beginnen ein konstanter Wert - solange Sie dies vermeiden, ist das Kennwort so sicher wie der Hashing-Algorithmus und die Anwendung, die es verwendet.

Es wäre möglicherweise etwas sicherer, aber vernachlässigbar. Ich würde mir darüber keine Sorgen machen und es der Einfachheit halber nur voranstellen. Fast jedes Unternehmen, für das ich gearbeitet habe, hat nicht einmal ein Salz verwendet, sodass Sie bereits sicherer sind als die meisten anderen.

Die Chancen eines Hackers mit einem aus Ihrer Datenbank gestohlenen Hash oder eines Man-in Es ist sehr unwahrscheinlich, dass ein mittlerer Angriff mit einem Salz angewendet wird, im Gegensatz zu nicht gesalzenen Hashes, die mit Regenbogentabellen möglicherweise leicht geknackt werden können.

In anderen Anwendungen sind bei Verwendung eines HMAC sowohl das Voranstellen als auch das Anhängen des geheimen Schlüssels für verschiedene Arten von Angriffen anfällig. Beides gilt jedoch nicht für das Versalzen eines Passwort-Hashs, sodass beide zufriedenstellend sein sollten.

Es ist (wenn auch nur geringfügig) sicherer, da jemand aufgrund der Häufigkeit, mit der dies auftritt (und je nachdem, wie viel er wollte), definitiv ein vorangestelltes Salz annehmen würde, wenn er davon ausgehen und gegen Salzbildung testen würde Zugriff können sie dann versuchen, ein angehängtes Salt)

Obwohl es weniger Zeit / Speicher-Kompromiss wird, können Sie auf jeden Fall Regenbogentabellen mit gesalzenen Passwörtern generieren und sie sind immer noch nützlich. Natürlich dauert das Generieren und Einnehmen von viel mehr Speicherplatz viel länger, aber selbst ich habe sie für einige Projekte verwendet.

Würde ich meinen eigenen Passwort-Hashing-Algorithmus implementieren, einschließlich Salting, würde ich einen Ort auswählen, der nicht der richtige ist ganz vorne oder ganz am Ende sicher. Ich würde natürlich auch kein hartcodiertes Salz verwenden, da sich daraus ein Minimum an Problemen ergeben würde.

Ich kann mir keinen Grund vorstellen, warum ich die Sicherheit nicht erhöhen möchte (unabhängig davon, wie vernachlässigbar sie ist einer Erhöhung kann es tatsächlich sein) auf Kosten einer geringen bis keiner Overhead-Erhöhung.