Frage:
Warum sollte man Salt einen Benutzernamen hinzufügen, bevor man ein Passwort hasht?
JustinLovinger
2018-03-08 12:51:53 UTC
view on stackexchange narkive permalink

Ich habe Beispiele für Passwort-Hashing gesehen, die waren: H (Benutzername + Salt + Passwort). Was ist der Zweck des Hinzufügens eines Benutzernamens? Gibt es einen Zweck?

Verwandte Themen: [Ist es akzeptabel, Salze mit einem Hash des Benutzernamens zu generieren?] (Https://security.stackexchange.com/q/39492/165253)
Möglicherweise haben die Autoren "Salz" und "Pfeffer" verwechselt?Es ist wohl sinnvoll (obwohl es immer noch kein guter Ansatz ist), den Benutzernamen hinzuzufügen, wenn Sie versehentlich Pfeffer anstelle von (anstatt zusätzlich zu) Salz verwendet haben.Wenn Sie den Benutzernamen nur zu Pfeffer hinzufügen, wird es zumindest schwieriger, Benutzer mit demselben Kennwort auf demselben Computer zu finden (was sonst nur Pfeffer nicht verhindert).
um ein genaues eindeutiges Hashing-Ergebnis zu generieren.Angenommen, das Passwort wurde bereits zuvor von anderen Benutzern gespeichert. Daher muss der Benutzername für bestimmte Benutzer eindeutiger sein.
@mfathirirhas-Salze sind für jeden Benutzer einzigartig.
Vier antworten:
#1
+152
forest
2018-03-08 12:58:42 UTC
view on stackexchange narkive permalink

Nein, es gibt keinen Zweck. Das ist Sicherheitstheater *. Der Zweck eines Salzes besteht darin, parallele Angriffe auf alle gehashten Passwörter unmöglich zu machen und Regenbogentabellen zu brechen. Durch Hinzufügen des Benutzernamens wird dieses Verhalten nicht verbessert oder andere Sicherheitsaspekte erhöht. Es hat tatsächlich einen kleinen Nachteil, da Sie jetzt auf einige Probleme stoßen, wenn Sie den Benutzernamen ändern und ein komplexeres und nicht standardmäßiges System warten müssen. In einem rein kryptografischen Sinne gibt es keinen Nachteil. In der Praxis bedeutet mehr Komplexität jedoch mehr Fehler.

Die Eigenschaften von Salzen und Benutzernamen

Sie könnten denken, dass der Benutzername selbst möglicherweise nicht öffentlich ist, sodass die Verwendung nicht schaden kann Es ist ein zusätzliches Geheimnis, aber Tatsache ist, dass die Datenbank wahrscheinlich bereits den Benutzernamen im Klartext enthält, was diesen bereits fragwürdigen Vorteil ungültig macht. Die Benutzer sollten sich an bereits vorhandene Authentifizierungstechniken halten. Aber schauen wir uns die Eigenschaften jedes dieser Objekte an:

Ein Salz ist:

  • Nicht geheim - Salze werden im Klartext gespeichert.

  • Sicher - Sie werden zufällig generiert und sind lang.

  • Einzigartig - Das Salz jedes Benutzers ist absichtlich anders.

Ein Passwort lautet:

  • Geheimnis - Angenommen, sie werden nicht auf eine Haftnotiz gesetzt.

  • Sicher - Wenn es nicht hunter2 ist. Das Passwort sollte gut sein.

  • Eindeutig - Zumindest im Idealfall, aber nicht alle Passwörter sind ideal.

Vergleichen Sie dies nun mit einem Benutzernamen. Ein Benutzername lautet:

  • Nicht geheim - Sie sind öffentlich oder zumindest im Klartext gespeichert.

  • Nicht sicher - Niemand denkt daran, einen langen und komplexen Benutzernamen zu wählen.

  • Nicht eindeutig - Benutzernamen können sicher zwischen Websites geteilt werden.

Die Eigenschaften eines guten Salzes

Nun, was genau macht ein Salz? Im Allgemeinen bietet ein gutes Salz drei Vorteile:

  1. Es verhindert, dass ein Angreifer den Hash jedes Benutzers gleichzeitig angreift. Der Angreifer kann ein Kandidatenkennwort nicht mehr hashen und es für jeden einzelnen Eintrag gleichzeitig testen. Sie sind gezwungen, ein bestimmtes Kennwort neu zu berechnen, um es für den Hash jedes Benutzers zu testen. Dieser Vorteil, den ein Salz bietet, wächst linear, wenn die Anzahl der unterschiedlichen Ziel-Hash-Einträge zunimmt. Natürlich sind Salze immer noch wichtig, auch wenn nur ein einziger Hash geschützt werden muss, wie ich weiter unten erläutere.

  2. Dies macht Regenbogentabellen unmöglich . Eine Regenbogentabelle ist eine hochoptimierte vorberechnete Tabelle, die Kennwörter mit Hashes vergleicht. Sie benötigen weniger Platz als eine gigantische Nachschlagetabelle, benötigen jedoch viel Zeit zum Generieren (ein Raum-Zeit-Kompromiss ). Damit Regenbogentabellen funktionieren, muss ein bestimmtes Kennwort immer in denselben Hash aufgelöst werden. Salze brechen diese Annahme und machen Regenbogentabellen unpraktisch, da sie für jedes mögliche Salz einen neuen Eintrag benötigen würden.

  3. Es verhindert gezielte Vorberechnung durch Regenbogentabellen, zumindest wenn der Hash wirklich zufällig ist. Ein Angreifer kann den Angriff erst beginnen, nachdem er die Hashes (und mit ihnen die Salze) in die Hände bekommen hat. Wenn das Salz bereits öffentlich ist, der Hash jedoch nicht, kann der Angriff optimiert werden, indem eine Regenbogentabelle für dieses bestimmte Salz erstellt wird. Dies ist ein Grund, warum WPA2 ein so hässliches Protokoll ist. Das Salz ist die ESSID (Netzwerkname), sodass jemand den Angriff für den Router seines Ziels starten kann, bevor er überhaupt den 4-Wege-Handshake in die Hände bekommt.

  4. Welchen möglichen Vorteil hätte es also, einen Wert vor dem Hashing zu verketten, wenn dieser Wert öffentlich, unsicher und wiederverwendet ist? Der Angreifer muss nicht nach weiteren Informationen suchen. Es trägt nicht zur Sicherheit eines Salzes bei. Dies erhöht nicht die Komplexität des Passworts. Es gibt keinen Vorteil.

    Richtiges Passwort-Hashing

    Also was sollen sie tun, um die Sicherheit zu erhöhen? Sie können anstelle eines einzelnen Hashs ein KDF wie PBKDF2, bcrypt, scrypt oder argon2 verwenden. Sie können einen Pfeffer hinzufügen, bei dem es sich um einen zufälligen globalen Wert handelt, der außerhalb der Datenbank gespeichert und dem Kennwort und dem Salz hinzugefügt wird. Daher muss der Pfeffer gestohlen werden, um zu versuchen, die Hashes anzugreifen, anstatt ihn einfach zu entleeren Datenbank mit SQLi.

    BEARBEITEN: Wie einige Kommentare hervorheben, gibt es ein erfundenes Szenario, in dem der Benutzername hilfreich wäre, um ihn in die Mischung aufzunehmen. In diesem Szenario ist die Implementierung so stark fehlerhaft, dass das Salt eigentlich kein Salt ist und der Benutzername der einzige eindeutige oder halb eindeutige Wert pro Benutzer in der Datenbank ist. In diesem Fall wäre es besser, den Benutzernamen einzumischen als nichts. Aber wirklich, wenn Sie kein Salz haben, sollten Sie anfangen, einen zu verwenden, anstatt zu versuchen, Benutzernamen zu verwenden. Verwenden Sie echte Sicherheit und seien Sie nicht halbherzig, wenn die Sicherheit Ihrer Benutzer auf dem Spiel steht.

    * In diesem Zusammenhang definiere ich Sicherheitstheater als die Praxis, Sicherheitsmaßnahmen zu implementieren, die dies tun die Sicherheit in keiner sinnvollen Weise verbessern und nur vorhanden sein, um die Illusion einer besseren Sicherheit zu vermitteln. sub>

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/74220/discussion-on-answer-by-forest-why-add-username-to-salt-before-hashing-a-passwor).
"Niemand denkt daran, einen langen und komplexen Benutzernamen zu wählen."Ich bin damit nicht einverstanden.
Benutzername ist nicht unbedingt bekannt.Man kann ein System erstellen, in dem keine Benutzernamen auf der Serverseite gespeichert sind oder nur der Hash als ID verwendet wird.Durch Hinzufügen eines Benutzernamens zum Salt werden schwache Passwörter (etwas) stärker (/ länger).
@goteguru Das wird unter https://security.stackexchange.com/q/25374/165253 erklärt, auf das ich verlinkt habe.
"Benutzernamen werden häufig von Websites gemeinsam genutzt."Musste lachen, weil dies * nicht * im Gegensatz zu Passwörtern steht, die auch häufig zwischen Websites geteilt werden.Da Salze das einzig garantiert einzigartige Teil sind, sollten wir Entwickler das besser richtig machen!
Die Generierung von Zufallszahlen kann sehr heimtückisch sein, da alles zu funktionieren scheint, die Sicherheit jedoch erheblich verringert werden kann.Das Einfügen des Benutzernamens in den Hash bietet in einem solchen Szenario eine gewisse Verteidigung.
@PeterGreen Ich bin mir nicht sicher, warum das so wäre.Wenn das Salz ein schlechtes RNG verwendet, ist es immer noch nicht so schlecht.
Das Hinzufügen eines Salt, das Sie nicht erwähnen, hat noch einen weiteren Vorteil: Es verhindert, dass der Hash eines bekannten Passworts auf einen unbekannten kopiert wird, und ermöglicht den scheinbar legitimen Zugriff auf das Konto eines anderen Benutzers.Ich vergesse jedoch den Namen dieser Art von Angriff.
@Bobson Längenerweiterungsangriff?Es erfordert jedoch etwas mehr als nur das Kopieren des Hashs.
+1 für eine gute Antwort, wünschte ich könnte noch eine +1 für diese bash.org Referenz geben!: D.
`[Regenbogentabellen] nehmen mehr Platz ein als ein einfaches Wörterbuch mit Kennwörtern ...` Tatsächlich sind Regenbogentabellen so stark komprimiert, dass sogar ein einziges _bit_ für mehrere Kennwort- / Hash-Zuordnungen codiert.Der Wikipedia-Artikel, auf den Sie verwiesen haben, erklärt, wie dies möglich ist.
Wenn Sie zu http://project-rainbowcrack.com/table.htm gehen, werden Sie sehen, dass die dritte MD5-Regenbogentabelle (nur ein Beispiel) die Informationen zu 221.919.451.578.090 pw's / Hashes enthält. Das Speichern dieser unkomprimierten würde 8 Bytes für das pw + 16 Bytes für den Hash = 24 Bytes bedeuten.Das Speichern würde also 5,3 * 10 ^ 15 Bytes dauern.(In der Tat etwas mehr, wenn ich die <8 Zeichen Passwörter der Einfachheit halber nicht ignoriert hätte).Die von Ihnen heruntergeladene Regenbogentabelle ist jedoch nur 160 GB groß.Das ist ein Faktor von 31000 Unterschied!Sie werden diese Art der Komprimierung mit LZMA niemals für eine Datei erreichen, die dieselben [a-zA-Z0-9] -Strings enthält.
@mgr326639 Das ist ein guter Punkt, obwohl ich nicht über Wörterbücher gesprochen habe, die den Hash enthalten (da dies eine Nachschlagetabelle wäre).Ich dachte an Regenbogentabellen, die nur völlig unabhängige Passwörter enthielten, die durch "\ 0" oder "\ n" getrennt waren (insbesondere kleinere Wörterbücher).Ich habe meine Antwort aktualisiert.
Eigentlich bin ich mir sicher, dass ein Radix-Baum mit nur den Passwörtern selbst viel kleiner wäre als eine Regenbogentabelle (natürlich generiert LZMA keine Bäume), daher könnte ein Wörterbuch immer noch kleiner sein.Ich bin etwas zu faul, um zu rechnen, um herauszufinden, wie groß ein kompakter Radixbaum von allem in `[a-zA-Z0-9] {8}` sein würde.
#2
+11
Steffen Ullrich
2018-03-08 13:07:02 UTC
view on stackexchange narkive permalink

Wenn das Salz so zufällig ist, wie es sein soll, bietet das Hinzufügen des Benutzernamens keinen zusätzlichen Schutz. Es verursacht aber auch keinen Schaden, abgesehen davon, dass der Code komplexer wird, was die Wahrscheinlichkeit von Fehlern erhöht. Wenn Sie eine Codeüberprüfung durchführen, kann dies als Zeichen dafür verstanden werden, dass der Entwickler nicht vollständig versteht, was er tut.

Wenn das Salt stattdessen größtenteils statisch ist oder vom Kennwort abgeleitet wird, kann der Benutzername seitdem hilfreich sein In diesem Fall dient der Benutzername im Wesentlichen dem Zweck, den das Salz nicht erfüllt hat. Dies ist jedoch nicht der empfohlene Weg, da das Salz zufällig sein soll und ein Benutzername nicht.

Siehe Ist es eine gute Idee, den Benutzernamen des Benutzers als Salt zu verwenden, wenn ein Passwort wie Hash (Benutzername_str + Passwort_str) gehasht wird? und Was sollte als verwendet werden? Salz? für eine eingehendere Diskussion darüber, was ein gutes Salz sein sollte und warum der Benutzername kein gutes Salz ist. Siehe auch Warum sind gesalzene Hashes für die Kennwortspeicherung sicherer?, um den Zweck des Salt überhaupt zu verstehen.

Wenn das Salz aus dem Passwort abgeleitet wird, hat der Implementierer mehr Probleme.Wenn sie den Benutzernamen hinzufügen können, sollten sie in der Lage sein, das Salz zu reparieren.
@forest: Wie gesagt: Wenn der Entwickler kein zufälliges Salz verwendet, versteht er nicht ganz, was er tut.In diesem Fall könnte der Entwickler die wildesten Ideen für die Verwendung eines nicht eindeutigen Salzes entwickeln, z. B. die Verwendung eines Benutzernamens oder die Ableitung des Salzes aus dem Kennwort oder beides "nur um sicherzugehen".Siehe für [Müssen Salze zufällig oder nur einzigartig und unbekannt sein?] (Https://security.stackexchange.com/questions/41617/) oder [Ist es in Ordnung, ein Salz aus einem Passwort abzuleiten ...] (https://stackoverflow.com/questions/10051716/), um zu sehen, wie das Konzept des Salzes oft nicht verstanden wird.
Warten Sie eine Sekunde ... Wenn das Salz vom Passwort abgeleitet ist, haben Sie überhaupt kein Salz, nur einen etwas anderen Algorithmus zur Hash-Generierung, der wiederum für Regenbogentabellen anfällig ist.Nur etwas andere Regenbogentische.
#3
+10
zacronos
2018-03-08 20:21:16 UTC
view on stackexchange narkive permalink

Wie @Damien_The_Unbeliever in einem Kommentar hervorhob, kann dies den Identitätswechsel des Benutzers in einem Szenario verhindern, in dem das System teilweise kompromittiert wurde.

Stellen Sie sich das folgende Szenario vor. Irgendwie hat ein Angreifer Lese- / Schreibzugriff auf die für die Anmeldung verwendete DB-Tabelle erhalten, die Benutzernamen, Kennwort-Hashes und Salze enthält - möglicherweise über einen SQL-Injection-Angriff. Dieser Angreifer hat keinen anderen erhöhten Zugriff auf das System, möchte sich jedoch als Benutzer im System auf nicht nachvollziehbare (oder schwer nachvollziehbare) Weise ausgeben.

  • Zunächst zeichnet der Angreifer den ursprünglichen Kennwort-Hash auf und Salz für das Konto des Opfers.
  • Als nächstes registriert der Angreifer sein eigenes Konto und kopiert den Passwort-Hash und das Salz von seinem Konto in das Konto des Opfers.
  • Nun kann der Angreifer Melden Sie sich mit dem eigenen Passwort des Angreifers beim Konto des Opfers an.
  • Wenn der Angreifer fertig ist, stellt er den Passwort-Hash und das Salt des Opfers wieder her, wodurch es für das Opfer schwierig wird, zu erkennen, was passiert ist.

In einigen Systemen kann ein Angreifer mit dieser Zugriffsebene einfach einen Kennwort-Hash mit dem Benutzernamen, dem Salt und einem beliebigen Kennwort des Opfers generieren (anstatt sein eigenes zu kopieren). Dies ist jedoch nicht möglich, wenn der Das System verwendet zusätzlich zum Salz einen Pfeffer (eine global definierte Konstante, die der Eingabe für alle Passwort-Hashes hinzugefügt wird an einem anderen Ort als dem Passwort gespeichert (Hashes und Salze). Ohne den Pfeffer zu gefährden, kann der Angreifer in diesem Szenario einen Kennwort-Hash mit einem bekannten Kennwort für das Opfer nur festlegen, indem er einen vom System generierten Kennwort kopiert, wie oben beschrieben.

Beachten Sie diesen Zwei-Faktor Die Authentifizierung kann dies wahrscheinlich nicht einmal verhindern. Wenn der Angreifer auch Zugriff auf die 2FA-Initialisierungscodes für Benutzer hat (möglicherweise in derselben Datenbank-Tabelle gespeichert), kann der Code des Angreifers auch vorübergehend in das Konto des Opfers geschrieben werden.

Wenn im Gegensatz dazu der Benutzername für die Berechnung des Kennwort-Hash verwendet wird, funktioniert dieser bestimmte Identitätswechselangriff nicht. Selbst wenn der Angreifer seinen Passwort-Hash, Salt und 2FA-Code in das Konto des Opfers kopiert, führt die Verwendung des Passworts des Angreifers auf dem Konto des Opfers nicht zum gleichen Passwort-Hash wie für das Konto des Angreifers, sodass die Anmeldung fehlschlägt.

Es ist fraglich, ob die Vorteile die zusätzliche Komplexität und die Möglichkeit von Fehlern wert sind, da dieses Szenario erfordert, dass der Angreifer das System bereits ernsthaft kompromittiert hat, und in diesem Szenario stellt der Angreifer das tatsächliche des Benutzers nicht wieder her Passwort. Es kann jedoch argumentiert werden, dass dies ein zusätzlicher Schutz ist.

Es macht ehrlich gesagt keinen Sinn.Sie können keine Hashes kopieren und einfügen, und wenn Sie ein kompromittiertes System haben, können Sie sich ohnehin trivial als Benutzer ausgeben.Ich kann mir kein Szenario vorstellen, in dem es den Identitätswechsel des Benutzers verhindern oder sogar aus der Ferne erschweren würde.
@forest Sie können Hashes wie alle anderen Daten kopieren und einfügen, wenn Sie den Zugriff haben, den dieses Szenario postuliert, sodass ich nicht verstehe, was Sie damit meinen.Das Szenario ist hier ziemlich gut beschrieben: Es ist ein Mechanismus des Benutzeridentitätswechsels in einem teilweise gefährdeten System.Es kann durchaus andere Routen geben - das Ausarbeiten des verwendeten Hash-Algorithmus und das Generieren Ihres eigenen Hashs oder das Umgehen der Authentifizierung insgesamt -, aber wahrscheinlich müssen mehr als die Datenbank kompromittiert werden.
@IMSoP Ein System, bei dem die Datenbank bereits durch Lese- / Schreibzugriff gefährdet ist, ist so stark gefährdet, dass Sie sich bereits als Benutzer ausgeben können.Stellen Sie Ihren Benutzer einfach als Administrator ein.Ändern Sie einfach die Benutzer-ID Ihres Benutzers.Du könntest alles machen.
@forest Wenn ein Angreifer in der Lage ist, SQL-Injection-Angriffe auszuführen, das System aber ansonsten nicht gefährdet hat, ist es nicht trivial, sich als Benutzer auszugeben.Ich habe einige Erläuterungen und einen Link zu einem SO-Beitrag hinzugefügt, in dem erklärt wird, warum "Pfeffer" zusätzlich zu nur Salz nützlich ist.(Es ist genau das gleiche Szenario, in dem eine kompromittierte Datenbank nicht bedeutet, dass das gesamte System kompromittiert ist.) Wenn dies kein Szenario wäre, das die Leute interessiert, würde niemand Paprika in ihren Hashes verwenden.
@zacronos Ich stimme zu, dass ein Pfeffer wichtig sein kann.Ich verstehe nicht, warum das Einmischen des Benutzernamens in irgendeiner Weise nützlich wäre (da ein Pfeffer bereits das Problem eines Angreifers lösen würde, der umfangreiches SQLi ausführen kann, aber keinen unformatierten Dateisystemzugriff hat).Ein Pfeffer ist eine bekannte Standardtechnik, um dies zu verhindern.Hashing in einem Benutzernamen ist nicht.
@forest Es hilft genau so, wie diese Antwort sagt: Es verhindert eine Methode, bei der ein Benutzer mit * Schreib * -Zugriff sich als Benutzer ausgeben könnte.Wie Sie sagen, gibt es * möglicherweise * andere Möglichkeiten, dies zu tun, indem Sie mit anderen Datensätzen in der Datenbank herumspielen. Diese Antwort macht deutlich, dass der Vorteil umstritten ist, schränkt jedoch diesen spezifischen Angriff ein und zwingt den Angreifer, einen zu findenandere Route.
Und was ist, wenn der Angreifer vorübergehend Benutzernamen mit dem Opfer austauscht?Ich weiß nicht, ob ich so weit gehen würde zu sagen, dass es keinen Nutzen gibt, aber es ist so begrenzt und erfunden, dass ich nicht sehe, dass es die Mühe jemals wirklich wert ist.
@AndrolGenhald stimmte zu, und ich bestätigte in meiner Antwort, dass es die Mühe möglicherweise nicht wert ist.Das Austauschen von Benutzernamen kann eine Option sein. Wenn jedoch eine Denormalisierung in den Daten stattfindet oder überhaupt protokolliert wird, bietet das einfache Austauschen von Benutzernamen möglicherweise keinen perfekten Identitätswechsel.Die von OP gestellte Frage war nicht, ob es sich lohnt, dies zu tun, sondern einfach, ob es irgendeinen Zweck hat und wenn ja, was es sein könnte.
Es ist erwähnenswert, dass das, was diese Antwort beschreibt, dasselbe ist wie [Verschlüsselung mit zugehörigen Daten] (https://security.stackexchange.com/questions/179273/what-is-the-purpose-of-associated-authenticated-data-in-aead) wird häufig für verwendet.Tatsächlich verwenden einige spezielle Kennwort-Hashing-Funktionen zugehörige Daten als optionales Argument zusätzlich zum Salt.
Ich denke, der Punkt hier (und warum diese Antwort nicht sehr nützlich ist) ist, dass wenn jemand Lese- / Schreibzugriff auf die Datenbank hat, ** Sie bereits verloren haben! ** Machen Sie in solchen Fällen keine seltsamen Sicherheitspraktiken.Verwenden Sie stattdessen parametrisierte Abfragen (oder vermeiden Sie SQL insgesamt) und verhindern Sie, dass diese die Datenbank überhaupt gefährden!
Der in dieser Antwort beschriebene Angriff erscheint mir plausibler, wenn wir ihn als Insider-Bedrohung neu interpretieren.Stellen Sie sich ein Unternehmen vor, das über ein Single-Sign-On-System verfügt, das von einer Datenbankinstanz unterstützt wird, die von einem nicht autorisierten Administrator verwaltet wird, der Lese- / Schreibzugriff auf die Kennwortdatenbank hat, jedoch nicht auf andere Assets, auf die er zugreifen möchte (einschließlich der Zuordnung, kritisch)zwischen SSO-Identitäten und Berechtigungen).Solch ein betrügerischer Administrator könnte Zugriff auf andere, privilegiertere Konten erhalten, indem er den Kennworteintrag eines Benutzers überschreibt, um ihn in seinem eigenen Kennwort-Hash zu ersetzen.
@NH.Ich verstehe zwar den Punkt, den Sie ansprechen (und habe dies in der Antwort anerkannt), aber viele gängige Sicherheitspraktiken basieren auf der Idee, dass eine Minderung lohnenswert ist (oder zumindest sein kann).In ähnlicher Weise (und zu Unrecht) könnte man argumentieren, dass das Hinzufügen eines Salt zur Berechnung eines Passwort-Hashs nicht notwendig sein sollte - sichern Sie einfach Ihre Passwort-Hashes, damit sie niemals kompromittiert werden und das Salt unnötig ist! Das Hinzufügen eines Pfeffers zur Kennwort-Hash-Berechnung ist auch nur zur Minderung nützlich, wenn die Datenbank gefährdet ist. Dies ist jedoch eine akzeptierte Vorgehensweise.
Das liegt daran, dass diese allgegenwärtigen Sicherheitsprobleme mindern, nicht erfundene.Ja, ein Systemadministrator muss Benutzer vor ihren eigenen Fehlern schützen, aber der Systemadministrator sollte keine Lösung für ein Problem finden müssen, das sie erstellt haben.Sie sollten stattdessen dieses Problem beheben.
Könnte dies in die Kategorie "[Verteidigung in der Tiefe] (https://en.wikipedia.org/wiki/Defense_in_depth_ (Computing))" fallen?
@JonathanCross Ja, das würde es.Es ist keine Sicherheit durch Dunkelheit, weil es nicht darauf ankommt, dass der Angreifer nicht weiß, wie die Dinge gemacht werden.Es * macht * einem Angreifer, der das System bereits teilweise kompromittiert hat, (einige) Dinge schwerer, anstatt an diesem Punkt aufzugeben.
@zacronos Ah, ich dachte, Jonathans Kommentar war eine andere Antwort.Mein schlechtes, wird meinen vorherigen Kommentar löschen.Mein Problem mit der Antwort ist so ziemlich das, was NH sagt.Dies scheint eine seltsame Sicherheitspraxis zu sein, die mit Code auf Anwendungsebene besser erreicht werden kann.
#4
+6
Luis Casillas
2018-03-09 01:13:22 UTC
view on stackexchange narkive permalink

Für den Anfang sollte das Passwort-Hashing mit einer dedizierten Passwort-Hashing-Funktion wie bcrypt, Argon2, scrypt oder PBKDF2 durchgeführt werden. In diesem Fall müssen Sie das Salt und das Passwort nicht wie ein Grundelement verketten. Die Funktion verwendet diese als separate Argumente. Siehe "Wie man Passwörter sicher hasht?", eine der Top-Q&As auf dieser Site für dieses Thema.

Der Zweck des Salt beim Passwort-Hashing ist die Randomisierung die Hash-Funktion, die auf jeden Passworteintrag angewendet wird. Drei Regeln, die im Allgemeinen für moderne spezialisierte Passwort-Hashes gelten, sind folgende:

  1. Jedes Mal, wenn Sie ein neues Passwort registrieren, sollten Sie ein neues Salz generieren. (Beachten Sie, dass dies bedeutet, dass Sie, wenn ein Benutzer sein Kennwort ändert, ein neues Salt für dieses Kennwort generieren und das Salt für das alte Kennwort nicht wiederverwenden sollten. Salze sind an Zustände eines Kennwortdatenbankeintrags gebunden, nicht an Benutzer.)
  2. Der Wert des Salzes sollte unabhängig vom Passwort selbst sein. Die Kenntnis des Passworts sollte beim Erraten des Salzes keine Hilfe sein, da ein Angreifer dieses Wissen sonst zur Vorberechnung einer Angriffstabelle verwenden könnte. Ein offensichtliches Beispiel hierfür ist, dass Sie das Passwort selbst nicht als Salz verwenden sollten. (Das ist weniger dumm, als es sich anhört - in diesem Fall würden Sie das Salz nicht zusammen mit dem Kennwort speichern -, aber es ist dumm , da zwei Benutzer mit demselben Kennwort denselben Hash haben würden.)
  3. Die Wahrscheinlichkeit, dass zwei Salze gleich sind, sollte sehr gering sein. Am besten nicht nur in Ihrer Anwendung, sondern weltweit auf der ganzen Welt.
  4. ol>

    Jetzt können wir Ihre Frage beantworten, indem wir folgende Beobachtungen machen:

  • Ein Salz, das hergestellt wird Eine ausreichende Anzahl zufälliger Bytes erfüllt diese Kriterien bereits. 16 zufällige Bytes (von einem kryptografisch starken Zufallszahlengenerator) klingen sinnvoll.
  • Das Verketten des Benutzernamens mit einem solchen zufälligen Salt hilft nicht.
  • Wenn die Salze auf eine vorhersehbare, aber nicht wiederholte Weise generiert werden, z. B. als Zähler, der bei jeder Registrierung eines neuen Kennworts erhöht wird, oder als Zeitstempel, werden zusätzliche Werte wie der Benutzername oder der Domainname Ihrer Site verkettet kann helfen, es einzigartiger zu machen. Die Verwendung von zufälligen Salzen wäre jedoch einfacher (es ist nicht erforderlich, einen anhaltenden Gegenzustand im Auge zu behalten).


  • Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
    Loading...