Die einzige Anforderung an ein Salz besteht darin, global eindeutig zu sein. Es muss nicht zufällig sein und es muss mit Sicherheit nicht unbekannt sein.

Beachten Sie das Schlüsselwort global . Ein Salt muss nicht nur im Kontext Ihrer Datenbank eindeutig sein, sondern auch im Kontext jeder einzelnen Datenbank da draußen. Es ist (sehr) unwahrscheinlich, dass eine E-Mail oder eine inkrementelle Benutzer-ID diese Anforderung erfüllt. Die Verwendung eines zufällig generierten Salt funktioniert.

BEARBEITEN

Ich werde das Ganze mit einer -Domäne + Benutzer-ID ansprechen als Salzidee, die in den Kommentaren auftauchte. Ich halte dieses Schema nicht für eine gute Idee, insbesondere im Vergleich zur Verwendung eines zufälligen Salzes.

Wenn Ihre Site ein hohes Ziel ist, kann es für einen Angreifer sinnvoll sein, eine Regenbogentabelle zu erstellen, die auf den Administrator abzielt Konto, bevor der Angriff auftritt. Dies kann ihm den Zugriff ermöglichen, bevor der Angriff entdeckt wird. Das Schema domain + userid funktioniert in dieser Situation nicht gut, da sich das Administratorkonto normalerweise innerhalb der ersten userid s im System befindet, insbesondere wenn userid wird mithilfe eines Zählers inkrementiert.

Abgesehen davon ist diese ganze Diskussion in der Praxis wirklich umstritten. Die Erzeugung von zufälligen Salzen ist einfach und schnell. Viele Passwort-Hashing-Bibliotheken, insbesondere die bcrypt , erledigen dies bereits für Sie. Es macht wirklich keinen Sinn, ein eigenes Schema zu erstellen, auch wenn es genauso sicher ist. Seien wir ehrlich, wir sind alle faule Leute, nicht wahr? : P Warum das Rad neu erfinden?

Das wichtige Merkmal eines Passwortsalzes ( wie Terry Chia richtig bemerkt) ist, dass es global eindeutig sein sollte: Keine zwei Passwort-Hashes (auch nicht auf verschiedenen Websites) sollten jemals dasselbe Salz haben.

Die Verwendung eindeutiger Salze schützt vor verschiedenen verwandten Angriffsmethoden, die möglicherweise von einem Angreifer angewendet werden, der die Benutzerdatenbank kompromittiert hat und die Kennwörter aus seinen Hashes wiederherstellen möchte:

• Erstens wird verhindert, dass ein Angreifer leicht erkennen kann, ob mehrere Benutzer dasselbe Kennwort haben (was diese Benutzer zu einem offensichtlichen Ziel machen würde, da ein solches gemeinsames Kennwort wahrscheinlich leicht zu erraten und eine hohe Auszahlung zu erzielen wäre).

• Umgekehrt wird auch verhindert, dass ein Angreifer, der mehrere Websites kompromittiert hat, leicht erkennen kann, welche Benutzer auf beiden Websites dasselbe Kennwort verwendet haben.

• Darüber hinaus verhindert die Verwendung eines eindeutigen Salt für jeden Benutzer, dass ein Angreifer einen Vorteil erhält, wenn er mehrere Konten gleichzeitig angreift. Ohne Salze (oder mit nicht eindeutigen Salzen) könnte ein Angreifer ein erratenes Passwort hashen und es dann mit jedem Passwort-Hash in der Datenbank vergleichen, wodurch es wahrscheinlicher wird, dass er mindestens eine Übereinstimmung erhält. Bei eindeutigen Salzen ist dies nicht möglich, da der Angreifer das Salz (und damit einen einzelnen Zielbenutzer) auswählen muss, bevor er jedes Passwort erraten kann.

• Schließlich werden auch eindeutige Salze verwendet Es ist unpraktisch, vorberechnete Hash-Nachschlagetabellen (wie die sogenannten "Regenbogentabellen") zu verwenden, um das Knacken von Passwörtern zu beschleunigen, da im Wesentlichen für jeden Benutzer eine separate Tabelle erforderlich wäre.

Grundsätzlich besteht das Hauptziel des Salting darin, sicherzustellen, dass das Knacken mehrerer kompromittierter Passwort-Hashes nicht einfacher ist, als jedes einzelne einzeln zu knacken - nicht mehr und nicht weniger. Durch die Verwendung global einzigartiger Salze wird dieses Ziel erreicht.

Eine einfache Möglichkeit, die globale Eindeutigkeit (mit hoher Wahrscheinlichkeit) sicherzustellen, besteht darin, eine ausreichend lange zufällige Zeichenfolge als Salz zu verwenden. Es gibt jedoch auch andere Möglichkeiten.

Sie können beispielsweise ein global eindeutiges Salt erhalten, indem Sie eine lokal eindeutige Benutzerkennung (z. B. eine E-Mail-Adresse oder eine Kontonummer) mit einer festen, global eindeutigen ID kombinieren Site-ID (z. B. der Domain-Name einer Website) und möglicherweise einige andere Elemente wie ein Zweckbezeichner (falls Sie mehr als ein eindeutiges Salt pro Benutzer benötigen) und ein Zeitstempel (sodass ein neues Passwort immer ein anderes Salt erhält) ). Die folgende Zeichenfolge wäre beispielsweise für ein weltweit eindeutiges Salt perfekt geeignet:

"Dies ist ein Kennwort Salt für Benutzer 5457 auf security.stackexchange.com, das am 1. September 2013 um 13: 35: 23.94730 UTC erstellt wurde "

und dies auch:

" password_salt: 5457: security.stackexchange.com: 20130901T133523.94730 "

Wenn Sie möchten, dass Ihre Salze kompakter sind, können Sie auch eine der oben genannten Zeichenfolgen über eine kryptografische Hash-Funktion wie SHA-256 und Verwenden Sie die Ausgabe als Salz. Wenn Ihr System einen integrierten GUID -Generator bereitstellt, können Sie diesen einfach verwenden (vorausgesetzt, er funktioniert natürlich wie er sollte).

All das Es gibt jedoch einen potenziellen Vorteil, wenn Kennwortsalze nicht nur eindeutig, sondern auch unvorhersehbar sind: Sie verhindern, dass der Angreifer einen Brute-Force-Angriff startet, bevor er Ihre Datenbank kompromittiert hat .

Wenn ich als Angreifer wüsste, dass das Salz Ihres Administratorkontos beispielsweise "12345678" ist, könnte ich meine Computer so einstellen, dass sie eine Nachschlagetabelle mit mehr oder weniger gebräuchlichen Passwörtern erstellen, die mit diesem Salz gehasht wurden noch bevor ich einen Weg gefunden hatte, Ihren tatsächlichen Passwort-Hash zu erhalten . Sobald ich einen Weg gefunden hatte, dies zu tun (vielleicht Wochen oder Monate später), konnte ich den Hash in meiner Tabelle nachschlagen, in der Hoffnung, dass er mit einem der Passwörter übereinstimmt, die mein Programm in der Zwischenzeit bereits ausprobiert hatte, in diesem Fall ich würde das Passwort sofort kennen.

Wenn ich jedoch nicht einmal wüsste, welches Salz Sie tatsächlich verwendet haben, könnte ich das Passwort nicht erraten, bevor ich das richtige Salz zum ersten Mal erhalten habe. Dies würde zusätzliche Zeit in Anspruch nehmen und es Ihnen möglicherweise ermöglichen, das Passwort zu ändern, bevor ich es knacken konnte.

Auch hier sind lange zufällige Salze (mit hoher Wahrscheinlichkeit) nicht nur eindeutig, sondern auch unvorhersehbar. Es gibt jedoch auch andere Möglichkeiten, um dieses Ziel zu erreichen. Sie können beispielsweise eines der oben gezeigten eindeutigen Beispielsalze verwenden und einfach einen geheimen Wert (z. B. eine zufällige Zeichenfolge, die in einer Konfigurationsdatei gespeichert ist und möglicherweise regelmäßig geändert wird) anhängen. Da dieses Geheimnis für alle Benutzer gleich wäre, würde es nicht bei der Einzigartigkeit helfen, aber es würde sicherstellen, dass ich keinen Brute-Force-Angriff starten könnte, ohne vorher irgendwie das Geheimnis zu lernen.

Ein Salz soll einzigartig sein, muss lang genug sein und sollte unvorhersehbar sein. Zufälligkeit ist nicht erforderlich, aber es ist der einfachste Weg für einen Computer, diese Anforderungen zu erfüllen. Und es ist nicht der Zweck eines Salzes, geheim zu sein, ein Salz erfüllt seinen Zweck auch dann, wenn es bekannt ist.

Einzigartigkeit bedeutet, dass es nicht nur in Ihrer Datenbank eindeutig sein sollte (andernfalls) Sie könnten eine Benutzer-ID verwenden), sie sollte weltweit einzigartig sein. Jemand könnte Regenbogentabellen für Salze wie z. 1-1000 und können Kennwörter für alle Konten mit diesen Benutzer-IDs abrufen (häufig haben Administratorkonten niedrige Benutzer-IDs).

Lang genug : Wenn das Salz zu kurz ist (auch) wenige mögliche Kombinationen), es wird wieder rentabel, Regenbogentabellen zu bauen. Salt und Passwort zusammen können dann nur als ein längeres Passwort angesehen werden. Wenn Sie eine Regenbogentabelle für diese längeren Passwörter erstellen können, erhalten Sie auch die kürzeren ursprünglichen Passwörter. Bei sehr starken und langen Passwörtern wäre das Salzen eigentlich überhaupt nicht erforderlich, aber die meisten von Menschen generierten Passwörter können brutal erzwungen werden, weil sie kurz sind (die Leute müssen sich an sie erinnern) Andere Parameter können in diese Kategorie fallen. Nur weil Sie einen Hash aus der Benutzer-ID berechnen, erhöht dies nicht die möglichen Kombinationen.

Unvorhersehbarkeit ist etwas weniger wichtig, aber stellen Sie sich noch einmal den Fall vor, in dem Sie die verwenden Benutzer-ID als Salz, ein Angreifer kann herausfinden, wie die nächsten Benutzer-IDs aussehen werden, und kann daher eine begrenzte Anzahl von Regenbogentabellen vorberechnen. Abhängig vom verwendeten Hash-Algorithmus kann dies zutreffen oder nicht. Er hat dann einen Zeitvorteil, kann das Passwort sofort abrufen. Ein größeres Problem wird sein, wenn die Administratorkonten ein vorhersehbares Salz verwendet haben.

Die Verwendung einer wirklich zufälligen Zahl, die aus der Zufallsquelle des Betriebssystems (dev / urandom) generiert wurde, ist das Beste, was Sie tun können. Selbst wenn Sie alle oben genannten Gründe ignorieren, warum sollten Sie ein abgeleitetes Salz verwenden, wenn es einen besseren Weg gibt, warum nicht den besten Weg verwenden, den Sie kennen?

UPDATE: , um die Frage zu beantworten Geänderte Frage:

Es ist sicherlich keine gute Idee, nur Domänenname + Benutzer-ID zum Generieren des Salt zu verwenden, da dies erraten werden kann und vorhersehbar ist. Ein Pfeffer hilft hier nicht weiter, da er so konstant ist wie der Domänenname. Sie sollten sich nicht darauf verlassen, dass er geheim ist. Mit der Benutzer-ID erhalten Sie Eindeutigkeit, mit dem Domänennamen erhalten Sie globale Eindeutigkeit, aber Sie vermissen den unvorhersehbaren Teil.

In Ihrem vorherigen Beispiel haben Sie das Kennwort selbst als zufälligen Parameter wie salt = hash ( Domänenname + Benutzer-ID + Kennwort) . Dies könnte funktionieren, solange das Salz überhaupt nicht gespeichert wird. Um das Passwort zu überprüfen, verfügen Sie über alle erforderlichen Parameter. Ich kann keinen Fehler in diesem Konzept erkennen, aber das bedeutet nicht, dass ich es empfehle. Wie bereits erwähnt, können Sie nichts Besseres tun, als ein zufälliges unabhängiges Salz zu erzeugen. Das Hinzufügen dieses Salzes zum Hash und das Extrahieren zur Überprüfung ist keine schwierige Aufgabe. Die am besten geeigneten Hash-Funktionen erledigen dies bereits für Sie, da sie den Kostenfaktor auf die gleiche Weise speichern müssen.

Zunächst einmal möchte ich vermeiden, das Salz in der Datenbank als einfachen Text zu speichern.

Warum? Es gibt keinen guten Grund, das Speichern des Salzes in der Datenbank im Klartext zu vermeiden. So wird ein Salz normalerweise gespeichert.

Mit den verschiedenen Iterationen Ihrer Frage haben Sie verschiedene Möglichkeiten vorgeschlagen, um Dinge anders zu machen, aber alle haben entweder die gleichen Sicherheitseigenschaften oder (normalerweise) ) machen die Sache noch schlimmer.

Der Sinn eines Salzes besteht darin, zu verhindern, dass Angreifer die Arbeit teilen, wenn sie viele Konten gleichzeitig knacken. Oft sind Angreifer nicht hinter einem bestimmten Benutzer auf einer bestimmten Site her. Sie möchten Fuß fassen oder so viele Konten wie möglich knacken. Der springende Punkt ist, dass das Knacken von Joes Konto auf der ACME-Site völlig andere Berechnungen erfordert als das Knacken von Janes Konto oder Joes Konto auf der Yoyodyne-Site. Daher muss ein Salt global eindeutig sein: über Konten und Datenbanken (und sogar über die Zeit hinweg).

Wenn Sie das Kennwort als Teil der Salt-Berechnung verwenden, ist es kein Salt at alles. Das Salz muss unabhängig vom Passwort sein. Wenn Sie das Salz aus dem Passwort berechnen, wird es Teil der Hash-Funktion: H (S (P), P) ist eine Funktion von P, Sie haben nur eine neue Hash-Funktion erstellt H '(P) = H ( S (P), P).

Die Verwendung des Benutzernamens ist nicht gut, da er in allen Datenbanken gleich sein kann. Ein Angreifer mit der ACME-Datenbank und der Yoyodyne-Datenbank kann beide Datenbanken knacken, ohne den Aufwand zu verdoppeln, wenn er Salz verwendet, das vom Benutzernamen abgeleitet ist.

Wenn Sie den Domänennamen und die Benutzer-ID verwenden, kann dies möglich sein Arbeit. Stellen Sie sicher, dass niemand auf der Welt denselben Domainnamen verwendet. Verwenden Sie insbesondere nicht denselben Domainnamen, wenn Sie mehr als eine Unterwebsite haben: Geben Sie den Dienstnamen oder was auch immer erforderlich ist, um den Namen eindeutig zu machen. Verwenden Sie Benutzer-IDs auch nicht wieder. Solange Ihr Salz weltweit einzigartig ist, ist es ein richtiges Salz.

Beachten Sie jedoch, dass Sie keine Sicherheit erhalten , wenn Sie den Domainnamen und die Benutzer-ID als Salt verwenden, anstatt wie üblich ein zufälliges Salt. Das Salz wird immer noch effektiv in der Datenbank gespeichert, nur auf seltsame Weise. Sie speichern einige Bytes pro Datenbankeintrag, was nicht von Bedeutung sein sollte.

Ein Pfeffer verbessert auch die Sicherheit nicht wesentlich. Sie können nicht davon ausgehen, dass Ihr Pfeffer geheim bleibt. Wenn der Angreifer eine Kopie Ihrer Kennwortdatenbank erhalten konnte (normalerweise durch Gefährdung Ihrer Anwendung oder durch Zugriff auf ein Backup), hat er wahrscheinlich auch Zugriff auf den Pfeffer (er muss für die Anwendung zugänglich und gesichert sein) immerhin auf). Der einzige Fall, in dem ein Pfeffer nützlich ist, ist ein Kompromiss wie SQL Injection, der dem Angreifer nur Zugriff auf die Datenbank gewährt und sich nicht auf einen Anwendungskompromiss erstreckt, auch nicht über ein Administratorkonto. Rechnen Sie nicht damit. Auch wenn Sie einen Pfeffer verwenden, muss Ihr Salz global eindeutig sein .

Ich empfehle dringend, ein zufälliges Salz zu generieren und neben dem Passwort zu speichern. Codieren Sie es vorzugsweise nicht selbst: Verwenden Sie eine vorhandene Bibliothek, die es richtig macht . Je mehr Sie von der empfohlenen Vorgehensweise abweichen, desto mehr riskieren Sie, es falsch zu machen - möglicherweise völlig, gefährlich falsch, wie das Ableiten des Salzes aus dem Passwort.

Denken Sie daran, dass Passwort-Hashes nicht nur gesalzen, sondern auch langsam sein müssen. Das bedeutet PBKDF2 oder bcrypt oder scrypt, wobei die Iterationszahl an die aktuellen Computergeschwindigkeiten angepasst ist.

Weitere Hintergrundinformationen finden Sie in unseren zahlreichen Threads zu diesem Thema:

• Wie werden Passwörter sicher gehasht?
• Wie speichere ich Salz?
• Passwort-Hashing Salz + Pfeffer hinzufügen oder ist Salz genug?
• Wenn Hashing-Passwörter verwendet werden, ist es in Ordnung, das Hash-Passwort als Salt zu verwenden?
• Warum ist die Verwendung von Salt sicherer? ?
• Sei kein Dave: Ist die Passwortsicherheit meines Entwicklers selbst richtig oder falsch und warum? (Hinweis: Nein.)

Da keine der anderen Antworten dies zu berühren scheint:

Verwenden Sie KEINEN Teil des Passworts als Salz. Zusätzlich zur Verringerung der Unvorhersehbarkeit hilft es einem Angreifer, die Passwörter zu knacken, wenn ein Angreifer es herausfindet. Warum? Weil sie genau dort einen Teil davon neben dem Kennwort in der Datenbank haben.

Update: Wenn Sie einen Teil des Kennworts im Salt verwenden und dies vermeiden möchten Das Salz speichern zu müssen und dann einen Teil des Passworts zu ziehen, nachdem es eingegeben wurde, um das Salz zu berechnen, funktioniert gut. Es erschwert das brutale Forcen weiter und ist bei der Erhöhung der Entropie genauso wirksam wie ein normales Salz. Es macht es etwas schwieriger, Regenbogentabellen zu erstellen, da Sie das Salz pro Passwort berechnen müssen, aber es verhindert sie nicht wirklich besser als ein normales Salz.

Neben der hervorragenden Antwort von @ terry-chia gibt es noch einen weiteren Grund, zufällige Salze zu wählen. Das Hashing- und Authentifizierungsschema, das Sie heute verwenden, stellt möglicherweise relativ schwache Anforderungen an das Salzen, aber eines Tages (oder eines Nachfolgers) können Sie das verwendete Schema möglicherweise so ändern, dass eine Zufallsanforderung besteht.

Obwohl Zufälligkeit keine Voraussetzung ist, sind Sie weitaus sicherer, wenn Sie zufällige Salze auswählen, da dies garantiert, dass Sie alle für Ihr Schema heute erforderlichen Dinge erhalten, aber es bietet Ihnen auch was Sie morgen vielleicht brauchen.

Wieder ein zusätzlicher Grund zu dem, was andere bereits erklärt haben. Leiten Sie das Salz nicht aus Benutzerdaten ab! Wenn Sie ein zufälliges Salz verwenden, erhalten Sie möglicherweise mehr als Sie benötigen, aber es stellt sicher, dass Sie keine anderen Fehler machen. Sie haben nichts zu gewinnen, wenn Sie kein zufälliges Salz verwenden (es sei denn, es gibt etwas, das Sie noch nicht erklärt haben), während Sie Ihr System weitaus weniger robust machen, indem Sie sich nur für die Mindestanforderungen eines Salzes entscheiden.