Was ist das Bedrohungsmodell? Es könnte von Vorteil sein, den Kennwortspeicher mit einem anwendungsseitigen Geheimnis zu schützen, aber nur, wenn Sie der Meinung sind, dass es ein realistisches Szenario ist, dass Ihre Datenbank kompromittiert wird - ohne Ihren Anwendungsserver, der das enthält geheim, auch kompromittiert.

Normalerweise wird die Anwendungsschicht als der anfälligere Teil und die Datenbankschicht als besser geschützt angesehen, und aus diesem Grund wird es nicht als nützlich angesehen, die Daten mit einer Anwendungsseite zu schützen Geheimnis. Dies ist jedoch möglicherweise nicht bei jeder App der Fall, und ich persönlich würde diese Annahme angesichts der Verbreitung der SQL-Injection etwas in Frage stellen.

Der Nachteil bei der Einführung eines App-seitigen Geheimnisses besteht darin, dass Sie sich jetzt Sorgen machen müssen Schlüsselverwaltungsprozesse. Was ist Ihr Mechanismus zum Ersetzen des Schlüssels, wenn er kompromittiert wird? Wirst du es selbstverständlich drehen? Wie wird Ihr Schlüssel gespeichert, damit Sie Server verschieben und nicht verlieren können (wodurch möglicherweise alle Ihre Daten unbrauchbar werden)? Für kurzlebige Schlüssel (die zum Beispiel zum Signieren von Sitzungstoken verwendet werden) ist dies möglicherweise nicht wichtig, aber für die langfristige Speicherung von Kennwörtern wird dies wichtig.

Der weitere Nachteil bei symmetrischen Chiffren (insbesondere Blockchiffren) besteht darin, dass sie korrekt implementiert werden . Da Sie Hashing durchführen und keine Wiederherstellbarkeit benötigen, können Sie stattdessen das Geheimnis in den Hash aufnehmen (als "Pfeffer") ... aber dann können Sie bei einer Schlüsseländerung nicht alle Kennwortdaten erneut hashen Sie müssten also eine Multi-Key-Methode für den Rollover haben.

ETA-Kommentar @Pacerier:

Hashing verhindert nicht einen Offline-Ratenangriff von jemandem, der die Kennwortdatenbank erhalten hat. Es erhöht nur die Zeit, die dieser Angriff benötigt, um Früchte zu tragen. Mit einem Hashing-Schema von angemessener Schwierigkeit (dh Runden der Schlüsselableitung anstelle der Rohsalzlänge an sich) wird diese Zeit hoffentlich zu lang, damit Sie bemerken, dass Sie gehackt wurden, und die Passwörter aller ändern, bevor zu viele Ihre Konten gehen verloren.

Der Schutz des Inhalts mit einem geheimen Schlüssel (entweder durch Verschlüsselung oder durch Einbeziehen des geheimen Schlüssels in das Hash-Material) verhindert den Offline-Ratenangriff, jedoch nur solange der geheime Schlüssel selbst vorhanden ist nicht durchgesickert. Wenn sich der geheime Schlüssel auf dem vom Datenbankserver getrennten App-Server befindet, können die Kennwörter nur angegriffen werden, wenn beide Computer kompromittiert sind.

Wie viel von einem Vorteil ist fraglich, da viele Arten von Angriffen enden können Beides wird gefährdet, insbesondere wenn der App-Server und der Datenbankserver auf demselben Computer installiert sind. Es gibt auch einen Preis für die Verwaltbarkeit, wie besprochen. Ob es also einen Nettonutzen gibt, muss von Fall zu Fall anhand des Bedrohungsmodells beurteilt werden.

Ich bin ein großer Fan davon, Schutzschichten über ein sicheres System als Teil einer Tiefenverteidigungsrichtlinie hinzuzufügen. In diesem speziellen Fall führt die Verwendung der symmetrischen Verschlüsselung für diese Aufgabe jedoch zu einem weiteren Problem im System. Sie müssen sich um die Schlüsselverwaltung kümmern. Der Schlüssel muss irgendwo gespeichert werden. Wenn Ihre Anwendung Zugriff darauf hat, hat ein Angreifer, der Ihr System kompromittiert hat, sehr wahrscheinlich Zugriff auf den Schlüssel.

Ein solches Verfahren fügt zusätzliche hinzu Komplexität des Systems. Komplexität ist einer der Feinde der Sicherheit. Ich rate dringend davon ab.

Das Verschlüsseln der Kennwort-Hashes kann die Kennwörter in einer ganz bestimmten Situation schützen.

Es gibt Szenarien, in denen ein Angreifer Lesezugriff auf Ihre Datenbank erhält. SQL-Injection ist eine Möglichkeit, eine undichte Sicherung oder eine entsorgte Server einen anderen. In diesem Fall kann er die Passwort-Hashes brutal erzwingen. Mit einem geeigneten Hash-Algorithmus (Schlüsselableitungsfunktion) sind starke Passwörter sicher, schwache Passwörter können jedoch mit einem Wörterbuchangriff mehr oder weniger schnell abgerufen werden (versuchen Sie es mit den 1000 am häufigsten verwendeten Passwörtern ...).

Mit der Verschlüsselung Ihrer Passwort-Hashes fügen Sie Ihren Hashes ein serverseitiges Geheimnis hinzu. Das bedeutet, dass ein Angreifer zusätzlich zur Datenbank jetzt Berechtigungen auf dem Server benötigt (um den Schlüssel zu erhalten). Dies ist der gleiche Vorteil, den ein Pfeffer Ihnen bieten kann, aber er hat den Vorteil, dass Sie den Schlüssel jederzeit austauschen können.

Ob der Schlüssel sicher aufbewahrt wird, ist nicht so wichtig, wichtig sind die zusätzlichen Berechtigungen, die der Angreifer benötigt. Im schlimmsten Fall erhält der Angreifer die Passwort-Hashes und Sie haben die gleiche Situation wie ohne Verschlüsselung.

Ich denke, es gibt einen Grund, einen sicheren Digest zu verschlüsseln.

Es scheint allgemein anerkannt zu sein, dass die beste Vorgehensweise heutzutage darin besteht, bcrypt, PBKDF2 oder ähnliche Algorithmen zum Salzen zu verwenden und einen Arbeitsfaktor auf die Generierung des Passwort-Digests anzuwenden. Die Verwendung eines Pfeffers ist auch eine hervorragende Möglichkeit, um zu verhindern, dass schlechte oder bekannte Passwörter ungeachtet des verwendeten Algorithmus / Arbeitsfaktors leicht brutal erzwungen werden.

Die Verwendung langsamer Algorithmen erfordert jedoch den Arbeitsfaktor Wird aktualisiert, wenn sich die Hardwareleistung verbessert, und muss ausgewählt werden, um Brute-Force-Angriffe zu verringern, aber nicht um die Überprüfung des Kennworts für Benutzer, die sich an Ihrem System anmelden, zu verringern. Durch die symmetrische Verschlüsselung eines Passwort-Hashs werden sowohl die Arbeitslast- als auch die Pfefferanforderungen nicht mehr benötigt. Vorausgesetzt, der symmetrische Schlüssel ist gut geschützt (z. B. mithilfe eines HSM) und es wurden gute Schlüsselverwaltungsprozesse eingerichtet. Ich sehe keinen Nachteil für diesen Ansatz. Die Schwierigkeit eines Brute-Force-Angriffs ist die gleiche wie das Brute-Forcen des Schlüssels, unabhängig davon, ob das Kennwort von guter Qualität ist oder nicht.

Ich würde mit Sicherheit nicht die Infrastruktur dafür erstellen, wie alle vorherigen Kommentare zur Schlüsselverwaltung und das Trennen des Schlüssels vom Anwendungsserver würde zutreffen. Wenn die Infrastruktur jedoch bereits vorhanden und gut etabliert ist, gibt es sicherlich einige Vorteile bei der Verschlüsselung eines gesalzenen Passwort-Hash.

Ich würde nein sagen. Aus den Gründen, die Adnan gesagt hat, muss der Schlüssel zugänglich sein, und dieser Schritt erhöht daher wahrscheinlich nur die Komplexität des Systems, was unnötig ist.

Ein besserer Ansatz IMO wäre, die Verschlüsselung als rechnergestützt anzusehen leisten, aber nicht verwendet, und überlegen, ob Sie dieses Computing für einen anderen Hashing-Ansatz verwenden könnten.

Es gibt ein Missverständnis, dass das Überlagern verschiedener Kryptopraktiken zu etwas führt, das sicherer ist als jede einzelne Praxis für sich. Dies ist jedoch selten der Fall.

Richtig implementiertes Passwort-Hashing mit einem langen Salz ist kryptografisch sicher. Das Hashing und Salting von Passwörtern dient zum Schutz der Daten in Ruhe. Das bedeutet, dass niemand, der Ihre Kennwortdatenbank in den Griff bekommt, wissen sollte, um welche Kennwörter es sich handelt, und selbst wenn es ihm gelingt, ein oder mehrere Kennwörter zu knacken, die dem Knacken eines anderen keinen Vorteil bringen sollten.

Wie Adobe uns in den letzten Wochen gezeigt hat, sind symmetrische Blockchiffren bei dieser Aufgabe nicht besonders gut. Durch das Hashing mit Salt wird dieses Problem vollständig vermieden.

Andere haben darauf hingewiesen, dass die weitere Verschlüsselung Ihrer Hash-Passwörter das Problem der Schlüsselverwaltung mit sich bringt und keine zusätzliche Sicherheit / Robustheit für die gespeicherten Daten bietet. Die Verschlüsselung ist gut, um sicherzustellen, dass nur diejenigen mit den richtigen Anmeldeinformationen auf Daten zugreifen können. Die Verschlüsselung ist aus diesem Grund reversibel. Dies ist kein Authentifizierungsparadigma.

Wenn wir uns authentifizieren, möchten wir, dass der Server etwas verwendet, das er kennt (das Salz) und ein Geheimnis, das nur Ihr Benutzer kennt (das Passwort), um konsistent denselben eindeutigen Datenblock zu generieren. Wir wissen, dass der Benutzer der ist, von dem er sagt, dass er er ist, weil wir diesen riesigen Blob immer wieder reproduzieren können. Das Salt stellt sicher, dass auch zwei identische Passwörter nicht denselben Hash in der Datenbank haben. Zusätzliche Verschlüsselung bietet auch in dieser Hinsicht keine Hilfe.