Sicherer Hash und Salt für PHP-Passwörter

Question

Derzeit wird behauptet, dass MD5 teilweise unsicher ist. In Anbetracht dessen würde ich gerne wissen, welchen Mechanismus ich für den Passwortschutz verwenden soll.

Diese Frage, Ist das "doppelte Hashing" eines Passworts weniger sicher als das einmalige Hashing? legt nahe, dass mehrfaches Hashing eine gute Idee sein kann, während Wie kann man einen Passwortschutz für einzelne Dateien einrichten? empfiehlt die Verwendung von Salz.

Ich verwende PHP. Ich möchte ein sicheres und schnelles Passwort-Verschlüsselungssystem. Das millionenfache Hashing eines Passworts ist zwar sicherer, aber auch langsamer. Wie lässt sich ein gutes Gleichgewicht zwischen Geschwindigkeit und Sicherheit erreichen? Außerdem möchte ich, dass das Ergebnis eine konstante Anzahl von Zeichen hat.

1. Der Hashing-Mechanismus muss in PHP verfügbar sein
2. Es muss sicher sein
3. Es kann Salz verwendet werden (sind in diesem Fall alle Salze gleich gut? Gibt es eine Möglichkeit, gute Salze zu erzeugen?)

Sollte ich außerdem zwei Felder in der Datenbank speichern (z. B. eines mit MD5 und ein anderes mit SHA)? Wäre es dadurch sicherer oder unsicherer?

Falls ich mich nicht klar genug ausgedrückt habe, möchte ich wissen, welche Hashing-Funktion(en) zu verwenden sind und wie man einen guten Salt auswählt, um einen sicheren und schnellen Passwortschutzmechanismus zu haben.

Verwandte Fragen, die meine Frage nicht ganz abdecken:

Was ist der Unterschied zwischen SHA und MD5 in PHP?
Einfache Passwortverschlüsselung
Sichere Methoden zur Speicherung von Schlüsseln und Passwörtern für asp.net
Wie würden Sie gesalzene Passwörter in Tomcat 5.5 implementieren?

Answer 1

HAFTUNGSAUSSCHLUSS : Diese Antwort wurde im Jahr 2008 verfasst.

Seitdem hat PHP uns Folgendes beschert password_hash y password_verify und sind seit ihrer Einführung die empfohlene Methode zum Hashing und zur Überprüfung von Passwörtern.

Die Theorie der Antwort ist aber immer noch eine gute Lektüre.

TL;DR

Was man nicht tun sollte

• Schränken Sie nicht ein, welche Zeichen Benutzer für Passwörter eingeben können. Das machen nur Idioten.
• Schränken Sie die Länge eines Passworts nicht ein. Wenn Ihre Benutzer einen Satz mit "supercalifragilisticexpialidocious" wünschen, sollten Sie sie nicht daran hindern, ihn zu verwenden.
• HTML- und Sonderzeichen im Kennwort dürfen nicht entfernt oder umgangen werden.
• Speichern Sie das Passwort Ihres Benutzers niemals im Klartext.
• Senden Sie niemals ein Passwort per E-Mail an Ihren Benutzer Es sei denn, sie haben ihren verloren und Sie haben einen Ersatz geschickt.
• Loggen Sie niemals Passwörter in irgendeiner Form.
• Hosten Sie niemals Passwörter mit SHA1 oder MD5 oder sogar SHA256! Moderne Cracker kann 60 bzw. 180 Milliarden Hashes/Sekunde übersteigen.
• Nicht mischen bcrypt und mit dem roh Ausgabe von hash() verwenden Sie entweder die Hex-Ausgabe oder base64_encodieren Sie sie. (Dies gilt für alle Eingaben, die einen abtrünnigen \0 was die Sicherheit ernsthaft beeinträchtigen kann).

Dos

• Verwenden Sie scrypt, wenn Sie können; bcrypt, wenn Sie nicht können.
• Verwenden Sie PBKDF2, wenn Sie weder bcrypt noch scrypt mit SHA2-Hashes verwenden können.
• Setzen Sie die Passwörter aller Benutzer zurück, wenn die Datenbank kompromittiert wurde.
• Führen Sie eine vernünftige Mindestlänge von 8-10 Zeichen ein, und verlangen Sie mindestens einen Großbuchstaben, einen Kleinbuchstaben, eine Zahl und ein Symbol. Dadurch wird die Entropie des Kennworts erhöht, was es wiederum schwerer macht, es zu knacken. (Siehe den Abschnitt "Was macht ein gutes Passwort aus?" für eine Diskussion).

Warum überhaupt Hash-Passwörter?

Das Ziel hinter dem Hashing von Kennwörtern ist einfach: Verhinderung des böswilligen Zugriffs auf Benutzerkonten durch Kompromittierung der Datenbank. Ziel des Passwort-Hashings ist es also, Hacker oder Cracker abzuschrecken, indem es sie zu viel Zeit oder Geld kostet, die Klartextpasswörter zu berechnen. Und Zeit/Kosten sind die besten Abschreckungsmittel in Ihrem Arsenal.

Ein weiterer Grund, warum Sie einen guten, robusten Hash für ein Benutzerkonto benötigen, ist, dass Sie genug Zeit haben, um alle Kennwörter im System zu ändern. Wenn Ihre Datenbank kompromittiert wird, brauchen Sie genug Zeit, um am wenigsten das System sperren, wenn nicht sogar alle Passwörter in der Datenbank ändern.

Jeremiah Grossman, CTO von Whitehat Security, erklärt im White Hat Security Blog nach einer kürzlichen Passwortwiederherstellung, bei der sein Passwortschutz mit roher Gewalt geknackt werden musste:

Interessanterweise habe ich in diesem Alptraum eine Menge über das Knacken, Speichern und die Komplexität von Passwörtern gelernt, was ich nicht wusste. Ich habe begriffen, warum die Speicherung von Passwörtern viel wichtiger ist als die Komplexität der Passwörter. Wenn Sie nicht wissen, wie Ihr Passwort gespeichert wird, können Sie sich nur auf die Komplexität verlassen. Für Passwort- und Krypto-Profis mag dies allgemein bekannt sein, aber für den durchschnittlichen InfoSec- oder Web-Sicherheitsexperten bezweifle ich es stark.

(Hervorhebung von mir.)

Was macht eine gut Passwort überhaupt?

Entropie . (Nicht, dass ich Randalls Standpunkt uneingeschränkt teile).

Kurz gesagt, die Entropie gibt an, wie groß die Variation innerhalb eines Kennworts ist. Wenn ein Passwort nur aus lateinischen Kleinbuchstaben besteht, sind das nur 26 Zeichen. Das ist nicht sehr abwechslungsreich. Alphanumerische Kennwörter sind mit 36 Zeichen besser. Aber wenn man Groß- und Kleinbuchstaben und Symbole zulässt, sind es ungefähr 96 Zeichen. Das ist viel besser als nur Buchstaben. Ein Problem ist, dass wir, um unsere Kennwörter einprägsam zu machen, Muster einfügen, was die Entropie verringert. Huch!

Die Passwort-Entropie ist angenähert leicht. Bei Verwendung aller ASCII-Zeichen (etwa 96 tippbare Zeichen) ergibt sich eine Entropie von 6,6 pro Zeichen, was bei 8 Zeichen für ein Kennwort immer noch zu wenig ist (52,679 Bits Entropie) für die künftige Sicherheit. Aber die gute Nachricht ist: Längere Kennwörter und Kennwörter mit Unicode-Zeichen erhöhen die Entropie eines Kennworts und machen es schwieriger, es zu knacken.

Eine längere Diskussion über die Entropie von Passwörtern findet sich auf der Website Krypto StackExchange Standort. Eine gute Google-Suche wird ebenfalls viele Ergebnisse liefern.

In den Kommentaren habe ich mit @popnoodles gesprochen, der darauf hinwies, dass Durchsetzung von Eine Kennwortrichtlinie der Länge X mit X Buchstaben, Zahlen, Symbolen usw. kann die Entropie tatsächlich verringern, indem sie das Kennwortschema berechenbarer macht. Ich stimme zu. Zufälligkeit, und zwar so zufällig wie möglich, ist immer die sicherste, aber am wenigsten einprägsame Lösung.

Soweit ich das beurteilen kann, ist die Entwicklung des besten Passworts der Welt eine Zwickmühle. Entweder ist es nicht einprägsam, zu vorhersehbar, zu kurz, zu viele Unicode-Zeichen (schwer einzugeben auf einem Windows-/Mobilgerät), zu lang usw. Kein Kennwort ist wirklich gut genug für unsere Zwecke, also müssen wir es schützen, als wäre es in Fort Knox.

Bewährte Praktiken

Bcrypt und scrypt sind die derzeit besten Praktiken. Scrypt wird mit der Zeit besser sein als bcrypt, aber es hat sich noch nicht als Standard unter Linux/Unix oder auf Webservern durchgesetzt, und es wurden noch keine detaillierten Bewertungen seines Algorithmus veröffentlicht. Dennoch sieht die Zukunft des Algorithmus vielversprechend aus. Wenn Sie mit Ruby arbeiten, gibt es ein Scrypt-Edelstein die Ihnen helfen werden, und Node.js hat jetzt seine eigene scrypt Paket. Sie können Scrypt in PHP entweder über das Scrypt Erweiterung oder die Libsodium Erweiterung (beide sind in PECL verfügbar).

Ich empfehle dringend, die Dokumentation für das Kryptofunktion wenn Sie verstehen wollen, wie man bcrypt benutzt, oder wenn Sie einen gut Umschlag oder verwenden Sie etwas wie PHPASS für eine eher ältere Implementierung. Ich empfehle mindestens 12 Runden bcrypt, wenn nicht sogar 15 bis 18.

Ich habe meine Meinung über die Verwendung von bcrypt geändert, als ich erfuhr, dass bcrypt nur den Blowfish-Schlüsselplan mit einem variablen Kostenmechanismus verwendet. Mit letzterem können Sie die Kosten für das Brute-Force-Verfahren eines Passworts erhöhen, indem Sie den ohnehin schon teuren Blowfish-Schlüsselplan erhöhen.

Durchschnittliche Praktiken

Ich kann mir diese Situation fast nicht mehr vorstellen. PHPASS unterstützt PHP 3.0.18 bis 5.3, so dass es auf fast jeder erdenklichen Installation verwendet werden kann - und verwendet werden sollte, wenn Sie nicht mit Sicherheit wissen dass Ihre Umgebung bcrypt unterstützt.

Aber nehmen wir an, dass Sie bcrypt oder PHPASS überhaupt nicht verwenden können. Was dann?

Versuchen Sie eine Implementierung von PDKBF2 mit dem maximale Anzahl von Runden die Ihre Umgebung/Anwendung/Benutzerwahrnehmung tolerieren kann. Die niedrigste Zahl, die ich empfehlen würde, ist 2500 Runden. Achten Sie außerdem auf die Verwendung von hash_hmac() wenn sie verfügbar ist, um die Reproduktion des Vorgangs zu erschweren.

Künftige Praktiken

Mit PHP 5.5 wird eine Bibliothek mit umfassendem Passwortschutz die alle Schwierigkeiten bei der Arbeit mit bcrypt beseitigt. Während die meisten von uns mit PHP 5.2 und 5.3 in den meisten üblichen Umgebungen feststecken, insbesondere bei gemeinsam genutzten Hosts, hat @ircmaxell eine Kompatibilitätsschicht für die kommende API, die rückwärtskompatibel zu PHP 5.3.7 ist.

Kryptographie - Zusammenfassung & Haftungsausschluss

Die erforderliche Rechenleistung für die tatsächliche Riss ein gehashtes Passwort nicht existiert. Die einzige Möglichkeit für Computer, ein Kennwort zu "knacken", besteht darin, es neu zu erstellen und den zur Sicherung verwendeten Hash-Algorithmus zu simulieren. Die Geschwindigkeit des Hash-Algorithmus steht in einem linearen Verhältnis zu seiner Brute-Force-Fähigkeit. Schlimmer noch: Die meisten Hash-Algorithmen können leicht parallelisiert werden, um noch schneller zu werden. Aus diesem Grund sind kostspielige Verfahren wie bcrypt und scrypt so wichtig.

Sie können unmöglich alle Bedrohungen oder Angriffsmöglichkeiten vorhersehen und müssen daher Ihr Bestes tun, um Ihre Benutzer zu schützen. im Vorfeld . Wenn Sie das nicht tun, könnten Sie sogar die Tatsache übersehen, dass Sie angegriffen wurden, bis es zu spät ist... und Sie sind haftbar . Um diese Situation zu vermeiden, sollten Sie von Anfang an paranoid sein. Greifen Sie Ihre eigene Software (intern) an und versuchen Sie, Benutzeranmeldeinformationen zu stehlen, die Konten anderer Benutzer zu ändern oder auf deren Daten zuzugreifen. Wenn Sie die Sicherheit Ihres Systems nicht testen, können Sie niemandem außer sich selbst die Schuld geben.

Und schließlich: Ich bin kein Kryptograph. Alles, was ich gesagt habe, ist meine Meinung, aber ich denke, sie basiert auf dem guten alten gesunden Menschenverstand ... und viel Lesen. Denken Sie daran: Seien Sie so paranoid wie möglich, machen Sie das Eindringen so schwer wie möglich, und wenn Sie dann immer noch besorgt sind, wenden Sie sich an einen White-Hat-Hacker oder Kryptographen, um zu sehen, was sie zu Ihrem Code/System sagen.

Answer 2

Eine viel kürzere und sicherere Antwort - schreiben Sie überhaupt keinen eigenen Passwortmechanismus verwenden Sie einen bewährten Mechanismus.

• PHP 5.5 oder höher: passwort_hash() ist von guter Qualität und Teil des PHP-Kerns.
• PHP 4.x (veraltet): OpenWall's phpass Bibliothek ist viel besser als der meiste benutzerdefinierte Code, der in WordPress, Drupal usw. verwendet wird.

Die meisten Programmierer haben einfach nicht das Fachwissen, um kryptobezogenen Code sicher zu schreiben, ohne Schwachstellen einzubauen.

Schneller Selbsttest: Was bedeutet Passwortverlängerung und wie viele Iterationen sollten Sie verwenden? Wenn Sie die Antwort nicht kennen, sollten Sie password_hash() da die Streckung von Kennwörtern aufgrund der viel schnelleren CPUs und der Verwendung von Kennwörtern ein wichtiges Merkmal von Kennwortmechanismen ist. GPUs und FPGAs Passwörter zu knacken mit Raten von Milliarden von Schätzungen pro Sekunde (mit GPUs).

Ab 2012 können Sie alle 8-stelligen Windows-Passwörter in 6 Stunden knacken mit 25 GPUs, die in 5 Desktop-PCs installiert sind. Dies ist Brute-Forcing, d.h. Aufzählung und Überprüfung jedes 8-stellige Windows-Kennwort einschließlich Sonderzeichen, und ist kein Angriff mit einem Wörterbuch. Mit modernen Grafikprozessoren können Sie natürlich mehr Passwörter knacken oder weniger Grafikprozessoren verwenden - oder die Grafikprozessoren in der Cloud für ein paar Stunden zu vernünftigen Kosten mieten.

Es gibt auch viele Rainbow-Table-Angriffe auf Windows-Kennwörter, die auf normalen CPUs laufen und sehr schnell sind.

All dies ist darauf zurückzuführen, dass Windows immer noch salzt und dehnt sich nicht seine Passwörter, auch unter Windows 10 . Das gilt auch noch im Jahr 2021. Machen Sie nicht denselben Fehler wie Microsoft!

Siehe auch:

• ausgezeichnete Antwort mit mehr darüber, warum password_hash() o phpass sind der beste Weg.
• guter Blogartikel mit empfohlenen "Arbeitsfaktoren" (Anzahl der Iterationen) für die wichtigsten Algorithmen einschließlich bcrypt, scrypt und PBKDF2.

Answer 3

Ich würde das Kennwort nicht in zwei verschiedenen Hash-Verfahren speichern, denn dann ist das System mindestens so schwach wie der schwächste der verwendeten Hash-Algorithmen.

Answer 4

Seit PHP 5.5 verfügt PHP über einfache, sichere Funktionen zum Hashing und zur Überprüfung von Passwörtern, passwort_hash() y passwort_bestätigen()

$password = 'anna';
$hash = password_hash($password, PASSWORD_DEFAULT);
$expensiveHash = password_hash($password, PASSWORD_DEFAULT, array('cost' => 20));

password_verify('anna', $hash); //Returns true
password_verify('anna', $expensiveHash); //Also returns true
password_verify('elsa', $hash); //Returns false

Wenn password_hash() verwendet wird, wird ein zufälliger Salt erzeugt und in den ausgegebenen Hash eingefügt (zusammen mit den Kosten und dem verwendeten Algorithmus). password_verify() liest dann diesen Hash und bestimmt das verwendete Salt und die Verschlüsselungsmethode und vergleicht es mit dem angegebenen Klartextpasswort.

Die Bereitstellung der PASSWORD_DEFAULT weist PHP an, den Standard-Hashing-Algorithmus der installierten PHP-Version zu verwenden. Welcher Algorithmus das genau ist, soll sich im Laufe der Zeit in zukünftigen Versionen ändern, so dass es immer einer der stärksten verfügbaren Algorithmen sein wird.

Eine Erhöhung der Kosten (Standardwert 10) macht es schwieriger, den Hash zu erzwingen, bedeutet aber auch, dass die Generierung von Hashes und die Überprüfung von Passwörtern anhand dieser Hashes mehr Arbeit für die CPU Ihres Servers bedeutet.

Beachten Sie, dass, auch wenn sich der Standard-Hash-Algorithmus ändert, alte Hashes weiterhin überprüft werden können, da der verwendete Algorithmus im Hash gespeichert ist und password_verify() nimmt es auf.

Answer 5

Obwohl die Frage bereits beantwortet wurde, möchte ich noch einmal darauf hinweisen, dass die für das Hashing verwendeten Salts zufällig sein sollten und nicht wie die E-Mail-Adresse, wie in der ersten Antwort vorgeschlagen.

Weitere Erklärungen finden Sie unter http://www.pivotalsecurity.com/blog/password-hashing-salt-should-it-be-random/

Kürzlich hatte ich eine Diskussion darüber, ob mit Zufallszahlen gesalzene Passwort-Hashes Bits sicherer sind als solche, die mit erratbaren oder bekannten Salze. Schauen wir mal: Wenn das System, das das Passwort speichert, kompromittiert wird als auch das System, das das zufällige Salt speichert, hat der Angreifer Angreifer sowohl auf den Hash als auch auf das Salt zugreifen, so dass es egal ist nicht, spielt keine Rolle. Der Angreifer kann vorberechnete Regenbogentabellen generieren, um den Hash zu knacken. Jetzt kommt der interessante Teil - es es ist nicht so trivial, vorberechnete Tabellen zu erzeugen. Nehmen wir ein Beispiel des WPA-Sicherheitsmodells. Ihr WPA-Passwort wird eigentlich nie an Wireless Access Point gesendet. Stattdessen wird es mit Ihrer SSID verschlüsselt (die Netzwerkname - wie Linksys, Dlink usw.). Eine sehr gute Erklärung, wie dies funktioniert, finden Sie hier. Um das Passwort aus dem Hash abzurufen, müssen Sie müssen Sie sowohl das Kennwort als auch das Salz (Netzwerkname) kennen. Kirche von Wifi hat bereits vorberechnete Hash-Tabellen mit den 1000 besten SSIDs und etwa 1 Million Passwörter. Die Größe aller Tabellen beträgt etwa 40 GB. Wie man auf ihrer Website lesen kann, hat jemand 3 Tage lang 15 FGPA-Arrays verwendet um diese Tabellen zu erstellen. Angenommen, das Opfer verwendet die SSID als "a387csf3" und das Passwort "123456" verwendet, kann es dann von diesen Tabellen geknackt werden? Tabellen geknackt? Nein! kann es nicht. Selbst wenn das Passwort schwach ist, haben die Tabellen haben die Tabellen keine Hashes für die SSID a387csf3. Das ist das Schöne an der Verwendung von zufälligen Salzes. Es schreckt Cracker ab, die sich an vorberechneten Tabellen gedeihen. Kann es einen entschlossenen Hacker aufhalten? Wahrscheinlich nicht. Aber die Verwendung zufälliger Salze bietet eine zusätzliche Verteidigungsschicht. Wenn wir schon dabei sind diesem Thema sind, lassen Sie uns einen weiteren Vorteil der Speicherung von Salts auf einem separaten System. Szenario 1: Passwort-Hashes werden auf System X gespeichert auf System X und die für das Hashing verwendeten Salt-Werte auf System Y gespeichert. Diese Salt-Werte können erraten werden oder sind bekannt (z. B. der Benutzername) Szenario#2 : Passwort-Hashes werden auf System X gespeichert und Salt-Werte, die für das Hashing verwendet werden, sind auf System Y gespeichert. Diese Salt-Werte sind zufällig. Für den Fall, dass System X kompromittiert wurde, gibt es, wie Sie sich denken können, einen großen Vorteil der Verwendung von Zufallssalzen auf einem separaten System (Szenario #2). Der Angreifer muss die zusätzlichen Werte erraten, um Hashes zu knacken. Hashes zu knacken. Wenn ein 32-Bit-Salz verwendet wird, sind 2^32= 4.294.967.296 (etwa 4,2 Milliarden) Iterationen für jedes erratene Passwort erforderlich sein.