PBKDF2 und Salz

  • Ich möchte einige Fragen zur Funktion PBKDF2 und generell zur kennwortbasierten Funktion stellen Ableitungsfunktionen.

    Eigentlich verwenden wir die Ableitungsfunktion zusammen mit dem Salt, um Widerstand gegen die Wörterbuchangriffe zu bieten, oder? Ein Beispiel ist das UNIX-Verschlüsselungsschema.

    Meine erste Frage:
    Wenn Sie beispielsweise ein Datenstück auf einer Karte verschlüsseln möchten und ich das Kennwort verwenden, um es abzuleiten einen neuen Schlüssel, der die PBKDF2-Funktion verwendet, in der Regel wird das Salt unverschlüsselt gespeichert, oder?

    Wenn ein Angreifer jedoch Zugriff auf die Karte erhält und das Salt findet, haben wir nur die Sicherheit das Passwort wieder, nicht wahr? Warum lagern wir das Salz im Freien? Ich weiß, dass es für Wörterbuchangriffe schwieriger wird, aber wenn jemand Zugriff auf die Karte erhält, befinden wir uns im ersten Bereich. Die einzige Vorsichtsmaßnahme ist die Länge des Kennworts, oder?

    Auch wir haben das gleiche Szenario:
    Wir haben das Passwort und wir wollen einen neuen Schlüssel generieren und wir verwenden die PBKDF2 oder eine andere Funktion (ich weiß, dass es die HMAC als Generator hat). Ich habe bis jetzt nirgends gefunden, ob das Ergebnis der Funktion, die aktuelle Taste , gespeichert ist oder nicht?

    Auch das Kennwort angegeben , woher wissen wir, ob das Passwort das richtige ist, um den tatsächlichen Schlüssel abzuleiten?

    13 September 2012
    Barn Monkeythrylos_7
3 answers
  • Stellen Sie zunächst fest, dass PBKDF2 PKCS # 5 ist RFC 2898, dh http: //www.ietf. org / rfc / rfc2898.txt

    Im Grunde genommen handelt es sich um einen Algorithmus, um ein Passwort so oft Sie wollen mit dem Hash, den Sie möchten, sicher zu hacken. OWASP empfiehlt, das Passwort im Jahr 2012 mindestens 64.000-mal zu hashen und es alle zwei Jahre zu verdoppeln ( https: //www.owasp). org / index.php / Password_Storage_Cheat_Sheet

    Beachten Sie, dass das Speichern (auch im Klartext) einer variablen Anzahl von Iterationen pro Benutzer ebenfalls hilfreich ist. Statt PBKDF2 immer 64.000 Mal auszuführen, generieren Sie stattdessen einen zufälligen Salt, und eine Zufallszahl I zwischen 1 und 20.000. Führen Sie PBKDF2 64.000 + I-mal für diesen bestimmten Benutzernamen aus. Dies macht das Cracken etwas schwieriger und kann dazu führen, dass bestimmte Optimierungen beim Cracken von Code nicht sinnvoll sind.

    Tatsächlich verwenden wir die Ableitungsfunktion zusammen mit der Salz, um Widerstand gegen die Wörterbuchangriffe zu leisten, RECHTS?

    Im Wesentlichen setzen wir die Klartext-Passphrase vor dem Hashing ein.

    Meine erste Frage: ... das Salz wird normalerweise unverschlüsselt gespeichert, oder?

    Bei einfacheren Implementierungen wird ein langer (8 Byte oder mehr) kryptographisch zufälliger Salt-Code unverschlüsselt gespeichert und bei jeder Kennwortänderung neu generiert. OWASP (Link oben) empfiehlt zusätzliche Vorsichtsmaßnahmen, z. B. dass ein zusätzlicher Salt in einer Konfigurationsdatei (dh nicht in der Datenbank) gespeichert wird, ein anderer Teil im Quellcode fest codiert ist, und der Salt für jeden Benutzer an einem anderen Ort als das Kennwort gespeichert wird vielleicht eine flache Datei oder eine Datenbank (oder umgekehrt). Beachten Sie, dass im Idealfall auch Passwörter und Salze an verschiedenen Orten gesichert werden müssen. Das Ziel besteht darin, das Stehlen von Salzen und Passwörtern mit einem Diebstahl zu erschweren.

    Auch wir haben das gleiche Szenario: Wir haben das Passwort und wollen einen neuen Schlüssel generieren ... Bisher fand ich nirgendwo eine Erklärung, ob das Ergebnis der Funktion (der eigentliche Schlüssel ( es ist gespeichert oder nicht?

    Das hängt davon ab. Wenn Sie PBKDF2 verwenden, um nur während dieser Sitzung einen Schlüssel für die Echtzeitverschlüsselung zu generieren, es sollte nur im Speicher verbleiben und am Ende verworfen werden Wenn Sie PBKDF2 verwenden, um einen Hash (nach N Iterationen) zu generieren, um einen Benutzer später zu authentifizieren, müssen Sie diesen Hash speichern.

    Ich weiß, es ist schwieriger für Wörterbuchangriffe, aber wenn jemand Zugriff auf die Karte erhält, die ich speichere, dann befinden wir uns im ersten Bereich, in dem die einzige Vorsichtsmaßnahme die Länge des Kennworts ist.

    Nein, die einzige Vorsichtsmaßnahme ist die Stärke des Kennworts. "P @ ssw0rdP @ ssw0rdP @ ssw0rd" ist ein falsches Kennwort , auch wenn es 24 Zeichen lang und "komplex" ist. Wenn Sie Benutzer "registrieren" oder lett Wenn Sie Passwörter auswählen, müssen Sie jedes Passwort in den am häufigsten verwendeten Wörterbüchern ablehnen. Wenn Sie auf Ablehnung testen, müssen Sie die gleichen Regeln anwenden, die von auf Regeln basierenden Wörterbuch-Crackern wie Elcomsoft oder Hashcat verwendet werden. Übersetzen Sie in 1337 Sprechen, fügen Sie 1 bis 1000 hinzu, fügen Sie zufällige Zeichen vor und zurück hinzu , verdoppeln, usw. Dies ist dankenswerterweise einfacher im Frontend, da Sie einfach 1337 rückübersetzen und in Kleinbuchstaben umwandeln können, sodass sowohl P @ ssw0rd als auch Passw0rd als "Passwort" enden, was als schrecklich herausgefiltert werden sollte. Melinda2006 ist immer ein falsches Kennwort, ebenso wie 12345.

    Außerdem können wir anhand des Kennworts feststellen, ob das Kennwort das richtige Kennwort ist, um abgeleitet zu werden der eigentliche Schlüssel?

    Sie wissen es vorher nicht; du versuchst es einfach. Wenn es funktioniert, war es richtig. Wenn es nicht funktioniert, war es falsch. Nun, durch "Werke" hängt es wieder ab

    10 August 2012
    lacker
  • Kennwortbasierte Schlüsselableitungsfunktionen generieren einen Schlüssel, der für die Verschlüsselung eines bestimmten Kennworts geeignet ist. Es hängt nur davon ab, dass das ursprüngliche Passwort geheim gehalten wird.

    Der Zweck des Salzes besteht einfach darin, die Verwendung von Regenbogentischen zu verhindern. Für jedes Salz muss ein Regenbogentisch erstellt werden, und wenn (wie üblich) jeder Benutzer sein eigenes Salz hat, müsste ein Regenbogentisch für diesen bestimmten Benutzer erstellt werden. Im Allgemeinen wird nicht davon ausgegangen, dass es geheim ist.

    Salze werden in Verbindung mit einer höheren Anzahl von Iterationen in der PBKDF-Funktion verwendet, um jeden Versuch zu verhindern, eine Regenbogentabelle zu erstellen.

    Der vom PBKDF2 abgeleitete Schlüssel wird irgendwo gespeichert.

    Ich glaube, Sie vielleicht Ich habe einen kryptografischen Hash eines Kennworts verwechselt, das für die Authentifizierung gespeichert ist, und PBKDF (das einen zugrunde liegenden kryptographischen Hash verwenden kann), um ein Kennwort für die Verschlüsselung zu "strecken".

    Der generierte Schlüssel sollte nirgendwo gespeichert werden (es sei denn, er ist entsprechend verschlüsselt). Der generierte Schlüssel wird zur Verschlüsselung verwendet. Wenn die Daten entschlüsselt werden sollen, sollte der Benutzer zur Eingabe des Kennworts aufgefordert werden, und der Schlüssel wird erneut generiert. Dieser generierte Schlüssel wird dann zum Entschlüsseln der Daten verwendet.

    Woher wissen wir, dass das von uns eingegebene Passwort das richtige ist, um die PBKDF2-Funktion auszuführen ?

    Beim Verschlüsseln von Daten sollten Sie auch die Nachrichtenauthentifizierung (MAC) mit einschließen. Dies bedeutet im Allgemeinen das Verschlüsseln von message || MAC. Sie würden die Daten mit einem (möglicherweise falschen) Schlüssel entschlüsseln. Überprüfen Sie dann, ob MAC und Nachricht übereinstimmen. Wenn dies nicht der Fall ist, war entweder der Schlüssel falsch oder der Chiffriertext wurde ansonsten manipuliert.

    Alternativ können Sie auch das Passwort kennzeichnen. Obwohl hierfür eine PBKDF verwendet werden kann, sollte klar sein, dass ein anderes Salt verwendet werden muss (auch wenn Sie nicht denselben Algorithmus verwenden). Dieser Hash wird gespeichert. Wenn der Benutzer sein Passwort eingibt

    09 August 2012
    Stephen Harris
  • 1) Das Salt muss in einem klaren oder verschlüsselten Zustand gespeichert werden?

    Entweder ist das Salt nur Als Teil des Schutzes hilft es, wenn Hacker nicht wissen, was es ist, aber selbst wenn sie es tun, können sie keine Regenbogentische verwenden. Wenn Sie es verschlüsseln, müssen Sie es auch entschlüsseln. Dies bedeutet, dass Sie nur Abwehrmaßnahmen ergreifen müssen, wenn die Hacker Ihre [user] -Tabelle gefährden, aber Ihre Codebasis nicht beeinträchtigen.

    Bei den meisten PBKDF2-Implementierungen wird ein zufälliger Salt mit dem Kennwort-Hash gespeichert (damit Sie ein Format wie salt + salted hash erhalten). Dies reicht aus, um die Wiederherstellung aller Kennwörter zu erzwingen und die Verwendung von Regenbogentabellen zu stoppen.

    2) Der von PBKDF2 abgeleitete Schlüssel wird irgendwo gespeichert.

    Nein, PBKDF2 kann nicht entschlüsselt werden, das ist der Punkt. Meinen Sie das Ergebnis Hash? Speichern Sie es, wo Sie möchten, aber wenn es wahrscheinlich leicht kompromittierbar ist, verwenden Sie mehr Iterationen.

    3) Woher wissen wir, dass das von uns eingegebene Passwort das richtige ist eine, um die PBKDF2-Funktion auszuführen?

    Durch erneutes Hashing.

    Eine PBKDF2-Beispielimplementierung sieht etwa so aus:

    Der Benutzer legt das Kennwort fest:

    • Es wird ein zufälliges Salt mit fester Länge generiert (meistens 128 Bit)
    • Salz wurde dem Passwort hinzugefügt
    • Salt und Passwort werden mindestens 1.000 Mal durch den Hashing-Algorithmus (normalerweise eine SHA-Variante), aber oftmals mehr durchlaufen.
    • Unverschlüsselter Salt und Hash werden zusammengefügt und zur Speicherung in einen String codiert.

    Sie überprüfen ein Kennwort anhand eines Benutzers:

    • Holen Sie sich den gespeicherten Hash.
    • Lesen Sie die ersten 128 Bits (oder was auch immer) als gespeicherten Salt.
    • Fügen Sie dem neuen potenziellen Passwort den Salt hinzu und führen Sie ihn aus durch denselben Hash-Algorithmus.
    • Prüfen Sie, ob er mit dem gespeicherten Hash übereinstimmt, ob er mit den Passwörtern übereinstimmt.

    Beachten Sie, dass das Salt nicht verschlüsselt ist.

    09 August 2012
    Dónal