BEARBEITEN:
Lassen Sie mich auf diese Antwort zu Security StackExchange verweisen, die erklärt viele Details über Passwort Hashing und Schlüsselableitung.
Bottom line: Verwenden Sie ein sicheres Hash-Schema für Kennwörter, das zum Schutz vor Brute-Force-Angriffen zwar ressourcenintensiv ist, aber die Anzahl zulässiger Aufrufe begrenzt, um Denial-of-Service (DoS) zu verhindern ) Angriffe.
Wenn Ihre Sprachbibliothek eine Funktion dafür hat, überprüfen Sie bei Upgrades, dass es das tut, was es tun soll, besonders wenn es PHP ist.
Die folgende Antwort wird aus historischen Gründen verlassen.
Sie könnten den Anmeldenamen des Benutzers als eine Spalte verwenden, die weniger wahrscheinlich ist als eine E-Mail-Adresse ( BEARBEITEN: 0xA3 richtig darauf hingewiesen, dies ist weniger sicher als die Verwendung der E-Mail-Adresse, da Login-Namen leichter zu erraten sind, und einige sind ziemlich häufig verwendet, so dass Rainbow-Tabellen möglicherweise bereits existieren sie oder könnten für andere Sites wiederverwendet werden).
Alternativ können Sie in einer Datenbankspalte das Salz für das Passwort speichern.
Aber Sie können auch ein zufälliges benutzerspezifisches Salz verwenden, das schwerer zu erraten ist.
Zur besseren Sicherheit könnten Sie zwei Salze verwenden: Einen benutzerspezifischen und einen systemweiten (fassen Sie sie zusammen, dann hacken Sie die Salze mit dem Passwort).
Übrigens ist die einfache Verkettung von Salz und Passwörtern möglicherweise weniger sicher als die Verwendung von HMAC . In PHP 5 gibt es die Funktion hash_hmac() , die Sie dafür verwenden können:
EDIT: Begründung für ein systemweites Salt: Es kann und sollte außerhalb der Datenbank gespeichert werden (aber back it up ). Sie können sich nicht authentifizieren Ihre Benutzer, wenn Sie es verlieren). Wenn ein Angreifer irgendwie Ihre Datenbankdatensätze lesen kann, kann er Ihre Kennwort-Hashes nicht effektiv knacken, bis er das systemweite Salz kennt.
BEARBEITEN (etwas außerhalb des Themas):
Ein weiterer Hinweis zur Sicherheit von Passwort-Hashes: Vielleicht möchten Sie auch Why machen Salze Wörterbuchangriffe "unmöglich"? beim Hashing mehrfach für zusätzlichen Schutz vor Brute-Forcing- und Rainbow-Table-Angriffen (obwohl ich denke, dass wiederholtes Hashing zusätzliche Möglichkeiten für Denial-of-Service-Attacken bieten kann, wenn man das nicht einschränkt Anzahl der Anmeldeversuche pro Zeit).
HINWEIS
Angesichts des Anstiegs von Mehrzweck-Multi-Core-Systemen (Grafikkarten, programmierbare Mikrocontroller usw.) kann es sich lohnen, Algorithmen mit hohem Rechenaufwand zusammen mit Salzen zu verwenden, um Brute-Force-Cracking, z. Verwenden mehrerer Hashes wie PBKDF2. Sie sollten jedoch die Anzahl der Authentifizierungsversuche pro Zeiteinheit begrenzen, um DDoS-Angriffe zu verhindern. Noch eine Sache: Ein anderes Hauptprinzip für die Verwendung eines "benutzerdefinierten" Hashings, das auf weit verbreiteten Standards und nicht auf einer weit verbreiteten vorgefertigten Funktion aufbaut, war PHP selbst, das sich nicht bewährt hat überhaupt vertrauenswürdig, wenn es darum geht, sicherheitsrelevante Dinge zu implementieren, sei es die nicht so zufällige Zufallsgeneratoren oder ein crypt() Funktion, die unter bestimmten Umständen überhaupt nicht funktioniert , wodurch alle Vorteile, die eine rechen- oder speicherintensive Passwort-Hashing-Funktion mit sich bringen sollte, vollständig umgangen werden.
Aufgrund ihrer deterministischen Ergebnisse werden einfache Hash-Funktionen wahrscheinlich besser getestet als die Ausgaben einer Schlüsselableitungsfunktion, aber Ihre Laufleistung kann variieren.
Ich bin kein Kryptographieexperte, aber es gibt vor allem drei Dinge, die mir mit diesem Vorschlag als mögliche Probleme erscheinen.
Ich weiß nicht, ob irgendetwas davon ein Problem ist oder nicht, aber die Sache mit Kryptographie ist, dass niemand so lange weiß, bis jemand einen Exploit entwickelt hat (und dann ist es zu spät) - Mein Rat wäre also, sich auf die Seite der Vorsicht zu begeben und E-Mail-Adressen nicht als Salz zu verwenden.
Wie bereits erwähnt, sollte Salz am besten zufällig sein. Der Zweck eines Salzes besteht darin, Rainbow-Table-Angriffe mit vorberechneten Hash-Wörterbüchern zu verhindern.
Angenommen, ein Angreifer kann die Hash Passwörter und Salze aus Ihrer Datenbank kennen, wenn das Salz "a74kd% $ QaU" ist und das Passwort "12345" ist, kann er es mit einer Rainbow-Tabelle knacken? Nein, selbst wenn das Passwort schwach ist, wird der Angreifer kein vorberechnetes Hash-Wörterbuch für Ihr zufälliges Salz zur Hand haben.
Wenn Sie jedoch ein nicht-zufälliges Salz wie die Benutzer-ID oder E-Mail verwenden, ist es wahrscheinlicher, dass jemand bereits eine Rainbow-Tabelle für dieses Salz erstellt hat, in der Hoffnung, einen Benutzer mit dem Benutzernamen "John" oder der E-Mail "John" zu finden. [email protected] " 1
1 WPA-Sicherheit für WLANs verwendet die SSID des Access Points als Salz. Schade, jemand hat bereits vorberechnete Hashes für die häufigsten SSID-Namen.
Ophcrack (welches die meisten Angreifer wahrscheinlich verwenden würden, abhängig von Ihrer Verschlüsselungsfunktion) enthält keine Tabellen mit Sonderzeichen wie '.' oder '@', wenn Sie nicht zu den größten ("erweiterten") Tabellen gelangen. Also wäre eine E-Mail wahrscheinlich besser als viele andere Salze.
Wie bei allen sicherheitsrelevanten Dingen hängt die Antwort von der Frage ab, die keine Informationen darüber enthält, wie sicher das System sein soll. Das sicherste Gebäude ist eines ohne Fenster oder Türen; es ist auch das nutzloseste Gebäude.
Von der höchsten Ebene: Nein, das ist keine schlechte Idee. Es ist auch keine gute Idee. Es kann jedoch gut genug - oder mehr als gut genug - für Ihre Anwendung sein.
Wenn jemand eine Rainbow-Tabelle für eine bestimmte E-Mail-Adresse hat, können Sie sie stoppen, indem Sie ein Passwort mit einem zufälligen Salton hashen? Gute Hacker gehen den Weg des geringsten Widerstands, der den Root-Zugriff auf Ihr System und das Herunterladen der Salz- und Benutzertabellen beinhalten kann. (Sind sie separat gesichert?) Wenn ja, haben sie solange, bis sich ein Passwort ändert, um einem Hash zu entsprechen, unabhängig von dem vom System erzwungenen fortlaufend fehlgeschlagenen Anmeldeversuch oder was Sie für salt gewählt haben.
Wie viel mehr Komplexität entsteht durch zufälliges Salz in Ihrer Anwendung? Wie entschlossen sind Sie, einen Hacker zu durchkreuzen? Welche anderen Maßnahmen - maximale konsekutive Fehlersperre, erzwungene Kennwortablaufzeiten, Ingress- und DoS-Warnungen, Firewalls usw. - haben Sie implementiert? Die Antwort liegt irgendwo in der Konvergenz zwischen den Antworten auf diese Fragen und vielleicht auch anderen.