Frage:
Ist PBKDF2-basiertes System.Cryptology.RFC2898DeriveBytes () für Unicode-Passwort-Hashing "besser" als herkömmliche Methoden?
goodguys_activate
2011-02-08 14:57:11 UTC
view on stackexchange narkive permalink

Wann ist es angemessen, RFC2898DeriveBytes gegenüber einem typischen Hash zu verwenden?

Update

Ich verstehe jetzt, dass ein KDF normalerweise verwendet wird, um einen symmetrischen Schlüssel für die mögliche Verwendung beim Verschlüsseln eines Streams zu erstellen. Ich verstehe jetzt auch, dass PBKDF2 PasswordDeriveBytes veraltet. Mit dieser Frage soll die Möglichkeit untersucht werden, das KDF als eine starke Möglichkeit zum Speichern eines Hash-Passworts zu verwenden. Der Inhalt, den ich verschlüsseln möchte, ist eine Unicode-Zeichenfolge, an die sich ein Mensch erinnern und die er in einen Computer eingeben kann.

Der Grund, warum ich mich für das KDF interessiere, ist, dass es

  1. Langsam und daher rechenintensiv zum Erstellen einer Regenbogentabelle.
  2. Die Basisbibliothek in .NET ist FIPS-genehmigt und es ist möglich, diese KDF mit NIST-Empfehlungen zu verwenden, wenn wir SHA- verwenden. 256
  3. ol>

    Frage

    Was sind die Argumente für / gegen die Verwendung eines KDF auf diese Weise im Gegensatz zur normalen Hashing-Methode? ? (Haftungsausschluss: Was ist die normale Hashing-Methode?)

Beachten Sie aus der Antwort von @Thomas_Pornin,, dass dies nicht für die Speicherung von Passwörtern geeignet ist. Im Allgemeinen möchten Sie keine Kennwörter speichern, sondern etwas, mit dem Sie nur überprüfen können, ob der Benutzer das richtige Kennwort angegeben hat - siehe [Kennwort-Hashing - IT-Sicherheit] (http://security.stackexchange.com/questions) / 211 / Passwort-Hashing). Für andere Fälle siehe z. [Authentifizierungsinformationen von Drittanbietern sicher speichern - IT-Sicherheit] (http://security.stackexchange.com/questions/1335/storing-third-party-auth-info-securely)
Es ist traurig, dass die Microsoft-Dokumentation, auf die Sie in PasswordDeriveBytes verweisen, auf "IETF RRC 2898" verweist. Sie bedeuten [RFC 2898] (http://tools.ietf.org/html/rfc2898), in dem weitere Überlegungen zu Verwendung und Sicherheit beschrieben werden.
Nur um die bisherigen Kommentare zu verdeutlichen: PBKDF1 ist veraltet. Es wird durch das .NET-Kryptoobjekt mit dem Namen [RFC2898DeriveBytes] (http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx) ersetzt.
Ich nehme die deutlich veränderte Frage zur Kenntnis. Der Link "FIPS genehmigt" zu meiner Antwort in einer anderen Frage scheint irreführend. Dort habe ich nur auf ein Argument hingewiesen, dass die Grundelemente in PBKDF2, wenn sie für die Verwendung von SHA-256 anstelle des Standard-SHA-1 angepasst würden, den aktuellen NIST-Empfehlungen entsprechen würden. Aber ich habe keine FIPS-Spezifikationen zum Passwort-Hashing gesehen. Mein Hauptpunkt war, dass Blowfish (bcrypt) eindeutig nicht auf der Liste von NIST steht, während SHA-1 war und SHA-256 jetzt ist.
@nealmcb - Sehen die Links genauer und klarer aus?
Heh - also habe ich eine vage Erinnerung daran, dass RFC2898DeriveBytes die Verwendung anderer Hashes erlaubt, aber ich mache kein .NET. Hast du das bestätigt? Können Sie uns einen Ausschnitt geben, wie HMAC-SHA-256 damit verwendet wird? Ist die Bibliothek tatsächlich irgendwie FIPS-zertifiziert oder implementiert sie nur einen genehmigten Algorithmus? Welche Parameter planen Sie schließlich für die Salzlänge (64?) Und Iterationen (1000? 4000?)?
verwandt: [Empfiehlt NIST PBKDF2 wirklich für das Passwort-Hashing?] (http://security.stackexchange.com/questions/15065/does-nist-really-recommend-pbkdf2-for-password-hashing)
Sechs antworten:
Thomas Pornin
2011-02-08 17:58:52 UTC
view on stackexchange narkive permalink

PasswordDeriveBytes implementiert die PBKDF1-Schlüsselableitungsfunktion. Ein KDF ist eine Funktion, die ein geheimes Datenelement (hier ein "Passwort", dh die Art von Daten, die in ein menschliches Gehirn passen und mit menschlichen Fingern eingegeben werden können) in eine Folge von Bits umwandelt, die für Algorithmen geeignet sind, die a benötigen symmetrischer Schlüssel (zB symmetrische Verschlüsselung). Ein KDF ist für nichts anderes gedacht, insbesondere für die Kennwortspeicherung.

Eine Hash-Funktion kann als KDF verwendet werden, vorausgesetzt, der von Ihnen benötigte symmetrische Schlüssel ist nicht länger als die Ausgabegröße der Hash-Funktion. Ein solches KDF wäre jedoch sehr grob. Ein Merkmal, das eine gute KDF bieten sollte, ist, ausreichend langsam zu sein. Dies liegt daran, dass "Passwörter" von Natur aus für eine umfassende Suche anfällig sind (auch als "Wörterbuchangriff" bezeichnet): Benutzer wählen als Passwörter eher einfache Wörter oder Kombinationen, die mit nur wenigen Millionen oder Milliarden Versuchen erraten werden können. In einem gegebenen System kann man normalerweise eine relativ langsame KDF tolerieren: Ein Benutzer, der versucht, sich zu authentifizieren, sieht keinen Unterschied zwischen einer Verzögerung von 1 us und einer Verzögerung von 1 ms für die Schlüsselableitungsfunktion; Eine 1000-fache Verlangsamung ist für den Angreifer jedoch tödlich: Sie wandelt einen eintägigen Bruchaufwand in einen dreijährigen Bruchaufwand um.

PBKDF1 enthält eine "Iterationszahl", die a ist Parameter genau dafür gedacht: um die Schlüsselableitung auf konfigurierbare Weise ausreichend langsam zu machen. Eine einfache Hash-Funktion ist dafür einfach zu schnell. Die Verwendung als KDF ist genau dort, wo Sie PBKDF1 einer Hash-Funktion vorziehen würden. Eigentlich wird PBKDF1 nicht empfohlen; PBKDF2 aus dem gleichen Standard soll robuster sein.

Hash-Funktionen sind viel allgemeinere Objekte als KDF und haben viele andere Verwendungen, die KDF nicht erfüllt.

Was Sie tun möchten, ist unklar: Sie verwenden den Begriff "Signatur", was normalerweise "asymmetrische digitale Signatur" bedeutet, wie bei RSA oder ECDSA. Es gibt einige Leute, die dazu neigen, den Begriff "Signatur" zu verwenden, um eine symmetrische Integritätsprüfung zu bezeichnen, wie z. B. einen MAC (die Bezeichnung "Signatur" ist unangemessen, aber weit verbreitet). Dies bringt jedoch irgendwann ein Geheimnis mit sich, einen Schlüssel und eine Hash-Funktion ohne Schlüssel.

+1 für die Erklärung der Details * viel * besser als ich.
Danke für die tolle Antwort. Außerdem habe ich diesen Link auf MSDN gefunden, der noch mehr Details bietet
.. Link zu MSDN: http://blogs.msdn.com/b/shawnfa/archive/2004/04/14/113514.aspx
@Thomas Wie kann ein Passwort korrekt gespeichert werden, wenn nicht PBKDF2?
Link: Wie * sollte * man ein Passwort verschlüsseln, wenn nicht von einem KDF: http://security.stackexchange.com/questions/2131/reference-implementation-of-a-c-hash-for-secure-password-storage
Laut @Thomas RFC2898 kann PBKDF1 zur Kennwortprüfung verwendet werden, [`wobei die Ausgabe der Schlüsselableitungsfunktion (zusammen mit der Salz- und Iterationszahl) zum Zwecke der anschließenden Überprüfung eines Kennworts gespeichert wird`] (http: // www. ietf.org/rfc/rfc2898.txt) Können Sie bitte Ihre Antwort klarstellen?
Für die Kennwortspeicherung benötigen Sie eine Einwegfunktion mit einer festen, ausreichend großen Ausgabe. Für die Schlüsselableitung benötigen Sie eine kollisionsfreie Funktion mit einer konfigurierbaren Ausgabegröße. Es ist denkbar, ein KDF zu erstellen, dessen Sicherheitsmerkmale auch für die Kennwortspeicherung gut genug sind (vorausgesetzt, Sie verwenden eine geeignete feste Ausgabegröße), dies ist jedoch nicht automatisch. PBKDF2 wurde als KDF veröffentlicht und als solches analysiert. Ob es in einen Passwortspeichermechanismus umgewandelt werden kann, muss noch bewiesen werden.
@makerofthings, Ihr Zitat ist aus dem Zusammenhang geraten. Tatsächlich hat RFC2898 vor 10 Jahren ausdrücklich gesagt, dass PBKDF1 für keine neuen Anwendungen empfohlen wird. Basierend auf dem Kommentar von @Thomas' würde ich sagen, dass Sie zumindest PBKDF2 verwenden möchten, das eine längere Ausgabe erzeugen kann.
Vielen Dank. Bedeutet das, dass PBKDF2 eine Ausgabe erstellt, die besser ist als jede andere, wie z. B. ein SHA 256-Hash? (zum Zwecke der Passwortspeicherung und des späteren Vergleichs)?
@makerofthings, Wie @Thomas erklärt, ist PBKDF2 eher für die Schlüsselableitung als für die Kennwortspeicherung konzipiert und vorgesehen. Vielleicht würde es helfen, die ursprüngliche Frage zu klären oder eine neue Frage so zu stellen, dass erklärt wird, zu welchem ​​Zweck Sie dieses kryptografische Grundelement möchten?
@D.W. - Frage geklärt. Danke für den Hinweis.
@D.W. @Thomas Beachten Sie jedoch den von @makerofthings zitierten Abschnitt, in dem der RFC die Verwendung der Funktionen zum Speichern von Kennwortprüfern vorwegnimmt. Ich verstehe auch nicht, warum die Länge von PBKDF1 möglicherweise unzureichend ist. Längere Hashes sorgen für etwas längere Regenbogentabellen, aber das spielt angesichts der Standardeinstellung des 64-Bit-Salzschutzes keine Rolle, oder?
@D.W. @Thomas @nealmcb fyi - Einen anderen Guru gefunden, der die Verwendung von PBKDF2 zum Hashing eines Passworts empfiehlt: http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html
goodguys_activate
2011-09-06 00:07:25 UTC
view on stackexchange narkive permalink

Das NIST genehmigt PBKDF2 beim Hashing und Speichern von Passwörtern, dies ist jedoch nicht der ursprünglich vorgesehene Zweck. Insbesondere verwendet StackExchange für denselben Zweck auch PBKDF2. Der Quellcode ist hier verfügbar.

Siehe diese Antwort für einen Vergleich zwischen BCrypt und PBKDF2. BCrypt ist die konventionellere Methode zum Speichern von Passwörtern.

Ich erwäge PBKDF2, da es in .NET integriert ist und bereits FIPS-kompatibel ist.

Ich bin nicht einverstanden, dass "nist-sp800-132" PBKDF2 für "Hashing und Speichern von Passwörtern" genehmigt. Es geht tatsächlich um die Verwendung von PBKDF2 als KDF zum Ableiten von Datenschutzschlüsseln, die zum Verschlüsseln gespeicherter Daten verwendet werden.
AviD
2011-02-08 16:22:36 UTC
view on stackexchange narkive permalink

Sofern ich nichts verpasst habe, sind PasswordDeriveBytes - und andere PBKDF-Implementierungen - weder zum Speichern von Passwörtern gedacht noch sollen sie anstelle eines "typischen" Hashs verwendet werden.

Es ist beabsichtigt, einen Verschlüsselungsschlüssel für die symmetrische Verschlüsselung basierend auf einem vom Benutzer angegebenen Kennwort zu erstellen.

Betrachten Sie zur Verdeutlichung die folgende Situation:
Sie haben eine Anwendung, für die eine Datei verschlüsselt werden muss. Dies liegt im Ermessen des Benutzers und kann nach seiner Wahl entschlüsselt werden.
Angenommen, MS Word verfügt über eine Funktion zum Verschlüsseln des Inhalts. Oder eine verschlüsselte ZIP-Datei.
Sie möchten dem Benutzer die Kontrolle über den Zugriff geben, möchten sich jedoch nicht darauf verlassen, dass der Benutzer einen starken, zufälligen Schlüssel mit genau 256 Bit generiert, der ihn erstellen würde schwer zu merken usw.
Sie erlauben dem Benutzer also, ein beliebiges Passwort festzulegen - und daraus den Verschlüsselungsschlüssel abzuleiten.

Sie speichern das Passwort zu keinem Zeitpunkt oder verwenden einen einfachen Hash, um es zu speichern. Es ist nur zum Erstellen von Schlüsselmaterial vorgesehen.

nealmcb
2011-02-15 23:57:21 UTC
view on stackexchange narkive permalink

PBKDF2 ist besser als PBKDF1, das vor 10 Jahren in RFC 2898 veraltet war. Es ist für .NET in der Klasse Rfc2898DeriveBytes (System.Security.Cryptography) implementiert.

Ich bin froh zu sehen, dass ab Java 6 PBKDF2 implementiert ist: PBKDF2WithHmacSHA1 in SunJCE.

Für frühere Versionen von Java, wie unter BlackBerry App Security - Stapelüberlauf beschrieben, befindet sich eine Implementierung von PBKDF2 unter einer kostenlosen Java-Implementierung von RFC 2898 / PKCS # 5 PBKDF2

Ich frage mich jedoch, ob die Verwendung von SHA-256 besser wäre als SHA-1, das jetzt veraltet ist.

Ich frage mich, ob die Verwendung von SHA-256 auch besser wäre.
jbtule
2011-03-02 04:12:43 UTC
view on stackexchange narkive permalink

Die Verwendung von RFC2898DeriveBytes mit einer nicht trivialen Iterationszahl sollte besser sein als die Verwendung einer Straight-Hash-Funktion für Authentifizierungszwecke.

Zuerst müssen Sie ein Salz einfüllen, und obwohl es dem Entwickler immer noch möglich ist, etwas Dummes wie harten Code für das Salz zu tun, ist es mindestens einen Schritt näher als dort, wo Entwickler normalerweise Fehler machen, die kein Salz sind und alles. Nur ein Salz zu haben, macht es weniger wahrscheinlich, dass eine Regenbogentabelle, die es bereits gibt, an einem trivialen Passwort funktioniert. Wenn Sie für jeden Benutzer zufällig salzen, wird der Informationsverlust gestoppt, wenn mehrere Benutzer dasselbe Passwort haben, und es ist sehr schwierig, diese einfachen Passwörter zu verwenden get, weil Sie für jedes Salz eine Tabelle generieren müssten.

2. Während RFC2898DeriveBytes Sie leider nicht die Hash-Funktion auswählen lässt und HMAC-SHA1 verwendet, ist dies kein wirkliches Problem Wenn es sich um PBKDF1 handelt, kann die Größe Ihres Schlüssels so groß sein, wie Sie es praktisch möchten. Dies hilft dabei, das Speichern und Verbreiten von Regenbogentabellen im Vergleich zu Standard-Hash-Algorithmen zu erschweren.

Schließlich sind die Iterationszahlen entscheidend! Haben Sie eine wirklich hohe Anzahl, die die Hash-Berechnung verlangsamt, Standard-Hash-Algorithmen sind so konzipiert, dass sie schnell sind, die Datenspeicherung wächst exponentiell. Sie können nicht nur auf die Größe Ihres Schlüssels zählen.

mrnap
2011-03-02 08:48:19 UTC
view on stackexchange narkive permalink

Die Frage des OP und das Ziel dieser Frage sind etwas widersprüchlich. Wie alle betonen, wird PBKDF2 nicht primär für die Kennwortverschlüsselung / -speicherung verwendet, sondern für die Schlüsselgenerierung. Am häufigsten wird es in WPA2-PMK- und anderen WPA-Schlüsselgenerierungsschemata verwendet, wobei Beispielkomponenten wie das Kennwort + ein Salt des SSID-Namens und der SSID-Namenslänge verwendet werden, die dann durch ein SHA1-Hashing mit 4096 Iterationen ausgeführt werden.

Bei der Verschlüsselung von Durchläufen sind aus Sicherheitsgründen die Länge und ein Salz, das dynamisch und für den Benutzer nicht transparent ist, am wichtigsten (dh der Exploiter kann nicht feststellen, um welches Salz es sich handelt). Wenn Sie einen AES-verschlüsselten Speicher mit einem Kennwort mit mindestens 20 Zeichen, einem zufälligen Salt und 4K + -Iterationen von SHA-256 verwenden (PBKDF2 empfiehlt für seine Zwecke mindestens 1K-Iterationen von SHA1), wird es für einen Hacker sehr schwierig sein, zu brechen dieses Passwort (siehe: Größenordnung in Jahren oder Jahrzehnten, wenn nicht länger).

Die Kennwortverschlüsselung hängt auch stark von der Endverwendung ab (Geschwindigkeit, Notwendigkeit der Sicherheitsstufe usw.). Ohne zu wissen, welche potenzielle Endverwendung vorliegt, ist es daher schwieriger, eine ideale Lösung zu empfehlen.

Bei den meisten gesalzenen Verschlüsselungsschemata, die in freier Wildbahn verwendet werden, ist das Salz nicht verborgen. Das ist keine hilfreiche Einschränkung. Sie können das Hashing nicht legitim wieder herstellen, wenn Sie das Salz nicht kennen.


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 2.0-Lizenz, unter der er vertrieben wird.
Loading...