Sie sollten es in einem einzelnen Feld speichern. Versuchen Sie nicht, es in Teile zu unterteilen.

Ich weiß, dass dies für Personen mit Datenbankhintergrund, bei denen der Modus Operandi darin besteht, Daten zu normalisieren und serialisierte Zeichenfolgen zu verwenden, als hässlicher Hack angesehen werden kann. Aus Sicherheitsgründen ist dies jedoch durchaus sinnvoll.

Warum? Da die kleinste Einheit, an der der einzelne Entwickler arbeiten muss, diese vollständige Zeichenfolge ist. Das ist es, was die App an die Hash-Bibliothek übergeben muss, um zu überprüfen, ob ein angegebenes Passwort korrekt ist oder nicht. Aus Entwicklersicht kann die Hash-Bibliothek eine Black Box sein, und sie muss sich nicht darum kümmern, was diese lästigen Teile tatsächlich bedeuten.

Dies ist eine gute Sache, da die meisten Entwickler unvollkommene Menschen sind (ich weiß , weil ich selbst einer bin). Wenn Sie sie diese Saite auseinander nehmen lassen und dann versuchen, alles wieder zusammenzufügen, werden sie wahrscheinlich die Dinge durcheinander bringen, z. B. allen Benutzern das gleiche oder gar kein Salz geben.

Es ist auch eine schlechte Idee, nur die Parameter im Code zu speichern. Wenn Prozessoren schneller werden, möchten Sie möglicherweise in Zukunft den Kostenfaktor erhöhen. Während der Migrationsphase haben unterschiedliche Kennwörter unterschiedliche Kostenfaktoren. Sie benötigen also Informationen zur Passwortebene darüber, welcher Kostenfaktor zum Hashing verwendet wurde.

Was Sie vermissen, ist, dass Hashes mit den Originaldaten abzüglich der Originalzeichenfolge funktionieren. Wenn Sie eine Zeichenfolge anhand eines Hashs validieren möchten, nehmen Sie die angegebene Zeichenfolge sowie die ursprünglichen Hash-Daten (Kosten, Salz usw.) und generieren einen neuen Hash. Wenn der neue Hash mit dem alten übereinstimmt, wird die Zeichenfolge validiert (mit anderen Worten, die Zeichenfolge wird niemals entschlüsselt , sie wird erneut aufbereitet ).

Das Salz zu haben hilft dir nicht bei roher Gewalt. Das Salz ist ein wesentlicher Bestandteil eines Hashs, genauso wie Becher Teil eines Schlosses sind. Wenn Sie eines herausnehmen, kann es niemand verwenden.

Das Trennen des Speichers ist sinnlos. In den meisten Fällen müssen Sie den fertigen Hash wieder zusammensetzen, um ihn zu validieren. Aus diesem Grund werden alle Komponenten standardmäßig in einer praktischen Zeichenfolge gespeichert.

Ja, Sie können es in einem einzelnen Feld speichern, und viele Datenbanken / Anwendungen speichern den Salt + Hash in einem einzelnen Feld / einer einzelnen Datei usw.

Das bekannteste ist Linux (das ist kein DB), der den Hash in der Datei / etc / shadow im folgenden Format speichert:

"$ id $ salt $ hashed", die druckbare Form eines Passwort-Hash, wie er von crypt (C) erstellt wurde. , wobei "$ id" der verwendete Algorithmus ist. (Unter GNU / Linux steht "$ 1 $" für MD5, "$ 2a $" für Blowfish, "$ 2y $" für Blowfish (korrekte Behandlung von 8-Bit-Zeichen), "$ 5 $" für SHA-256 und "$ 6 $" "ist SHA-512, [4] andere Unix-Versionen haben möglicherweise andere Werte wie NetBSD.

(Quelle: https://en.wikipedia.org/wiki/Passwd)

Das Salz soll nicht geheim sein (oder zumindest nicht geheimer als der Hash). Sein Hauptzweck ist es, Brute-Forcing-Angriffe viel schwieriger zu machen, da der Angreifer a verwenden muss Unterschiedliches Salz für jeden einzelnen Benutzer.

Ihre Frage ist jedoch differenzierter - weil Sie nicht nur nach Salzen, sondern auch nach Parametern fragen. Dinge wie der Hashing-Algorithmus, die Iterationszahl und das Salz Speichern Sie dies nicht im Code, sie gehören immer noch in die Datenbank.

Stellen Sie sich vor, Sie haben eine Reihe von Benutzern und Sie haben SHA1 als Hashing-Algorithmus verwendet. Ihr Datenbankfeld würde dies also tun Seien Sie so etwas wie SHA1: SALZ: HASH .

Wenn Sie Ihre Datenbank auf BCRYPT aktualisieren möchten, wie würden Sie dies tun?

Typi Normalerweise würden Sie Code bereitstellen, damit Sie bei der Anmeldung eines Benutzers das Kennwort überprüfen und, falls gültig, das Kennwort mit einem neueren Algorithmus erneut hashen. Jetzt sieht das Feld für den Benutzer folgendermaßen aus: BCRYPT:SALT:HASH .

Aber dann wären einige Benutzer auf SHA1 und andere auf BCRYPT, und da dies bei a ist Auf Benutzerebene benötigen Sie die Parameter, die Ihrem Code mitteilen, welche Benutzer sich in der Datenbank befinden sollen.

Kurz gesagt, das Speichern der Parameter und des Hashs in einem einzelnen Feld ist in Ordnung, aber das Aufteilen aus irgendeinem Grund (Effizienz, einfacher Code usw.) ist ebenfalls in Ordnung. Was nicht in Ordnung ist, ist dies in Ihrem Code zu speichern :)

TL: DR

Troy Hunt hat kürzlich einen Podcast veröffentlicht, in dem vorgeschlagen wird, dass es effektiver ist, einfach alle derzeit vorhandenen SHA1-Hashes zu verwenden, anstatt wie oben beschrieben zu BCRYPT zu migrieren die Datenbank und hashen Sie sie mit BCRYPT.

Effektiv BCRYPT(SHA1(clear_password))

Wenn sich ein Benutzer anmeldet, würden Sie

  BCRYPT (SHA1 (clear_password)) == <db_field>  

Auf diese Weise wird jeder auf der Plattform gleichzeitig aktualisiert, und Sie haben keine Datenbank mit mehreren Hashs Formate für Passwörter. Sehr sauber und sehr nett.

Ich denke, diese Idee ist absolut sinnvoll, aber obwohl jeder auf einmal migriert, ist sie nicht sofort. Sofern Sie nicht bereit sind, Ausfallzeiten in der App zu akzeptieren (während Sie alle Kennwörter erneut hashen), wird es immer noch eine kleine Zeitspanne geben, in der sich einige Benutzer auf BCRYPT und andere auf SHA1 befinden. Daher sollte Ihre Datenbank die weiterhin speichern Parameter des Hashing-Algorithmus, und Ihr Code würde basierend darauf ausgeführt.

Aus Sicherheitsgründen spielt es keine Rolle, ob das Salt- und das Hash-Passwort in einem einzelnen Feld oder in separaten Feldern gespeichert sind, obwohl ich mich der Einfachheit halber zu einem einzelnen Feld neigen würde. Der einzige Grund, sie zu trennen, besteht darin, dass Ihr Anwendungscode das Salt und das Kennwort separat an die Validierungsfunktion übergeben muss. Wenn für Ihren Anwendungscode nur eine einzige kombinierte Zeichenfolge erforderlich ist, können Sie diese auch so speichern.

Beispielsweise hat die ältere ASP.NET-Mitgliedschaft den Kennwort-Hash und das Salt in zwei DB-Felder aufgeteilt Die neuere ASP.NET-Identität enthält Hash und Salt in einem einzelnen DB-Feld. Die neueren Funktionen wurden geändert, um die einzelne Zeichenfolge als Ein- und Ausgabe zu behandeln.

Ist es akzeptabel, dies in einem Feld in einer SQL-Datenbank zu speichern (in diesem Fall varchar (99))

Nein. Die Größe der Daten kann sich irgendwann ändern. Ein Varchar (MAX) -Feld sollte verwendet werden, es sei denn, die Spezifikationen geben an, dass die Größe immer genau 99 beträgt und es keine Abweichungen von diesem jemals geben darf. Lassen Sie die Datenbank sich um die Speicheranforderungen kümmern.

Um zu wissen, ob es mehr oder weniger sicher ist, müssen wir den Zweck eines Salzes verstehen.

Ein Salz dient einigen Zwecken (an die ich denken kann)

1. Wörterbuchangriffe verhindern
ol>

Bei einem Wörterbuchangriff wird ein logisches Wort als Teil eines Kennworts verwendet. Der Archetyp ist das Wort Passwort oder sogar P @ ssW0rd . Menschen sind unvollkommen und es fällt ihnen leichter, sich an Wörter zu erinnern, als an zufällige Buchstaben- und Zahlenfolgen. Ein Wörterbuchangriff beruht darauf, um den Weg eines Brute-Force-Angriffs zu verkürzen. Wenn wir einen zufälligen Teil hinzufügen, macht dies diese Art von Angriff offensichtlich unmöglich oder sinnlos und bringt sie wieder dazu, das Ganze brutal zu erzwingen.

Wenn ein Angreifer das verwendete Salt kennt, muss er alle seine Wörterbuchdateien für jedes Kennwort bearbeiten. Dies setzt voraus, dass er weiß, wie das Salt zum ursprünglichen Kennwort hinzugefügt wird. Ein großer Vorteil einer Wörterbuchliste besteht darin, dass Sie 1000 Passwörter und 1 Million Wörterbuchwörter verwenden. Dann durchlaufen Sie sie und versuchen, ein paar Übereinstimmungen mit schwächeren Passwörtern zu erhalten. Es ist also nicht wirklich praktisch, 1 Million Wörter 1000 Mal bearbeiten zu müssen.

2. Verhindern Sie Hash- oder Rainbow-Tabellenangriffe.
ol>

A. In der Rainbow-Tabelle werden Hashes vorberechnet und in einer Datenbank gespeichert. Zum Beispiel könnten Sie MD5 nehmen und einfach anfangen, zufällige Dinge zu hashen und zu speichern. Wenn Sie dann ein Passwort knacken möchten, schauen Sie einfach in der Regenbogentabelle nach.

Wenn ein Angreifer das Salz hat, muss er die Regenbogentabelle für jedes verwendete Salz neu kompilieren. Der Vorteil dieses Angriffs besteht darin, dass diese Daten im Voraus zusammengestellt und immer wieder verwendet werden. Dies versetzt sie wieder in die Lage, das Passwort brutal zu erzwingen. Wenn Sie alle Passwörter unterschiedlich salzen und salzen, bedeutet dies im Grunde, dass Sie die Regenbogentabelle für jedes Salz neu berechnen müssen. Aus diesem Grund ist es wichtig, für jedes Passwort unterschiedliche Salze zu verwenden.

Summery

Keiner dieser Gründe hängt wirklich davon ab, dass das Salz geheim ist. Offensichtlich sind sie alle weniger stark, wenn ein Angreifer das Salz kennt. Aber zusätzliche Informationen, die sie erhalten, helfen ihnen immer. Ich würde also nicht sagen, dass ich Werbung machen soll, aber es gibt ein Sprichwort über Sicherheit, die auf Dunkelheit basiert ...

Haftungsausschluss Ich bin keineswegs ein kryptologischer Experte, aber Dies sind einige der wichtigsten Gründe, die mir einfallen, wenn ich an Salze denke.

Ich hoffe, das hilft.

Das Salt wird nur verwendet, um die Angriffe der Regenbogentabellen zu blockieren. Daher wird Ihr Salt möglicherweise mit dem Hash-Passwort gespeichert, wie dies auf dem neuesten GNU / Linux-System der Fall ist, auf dem das Salt in / etc / shadow gespeichert ist.