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

Derzeit wird gesagt, dass MD5 teilweise unsicher ist. In Anbetracht dessen möchte ich wissen, welcher Mechanismus für den Passwortschutz verwendet werden soll.

Diese Frage: Ist "doppeltes Hashing" ein Passwort weniger sicher als nur einmaliges Hashing? schlägt vor, dass das mehrfache Hashing eine gute Idee sein kann, während Wie man den Passwortschutz für einzelne Dateien implementiert? schlägt vor, Salz zu verwenden.

Ich benutze PHP. Ich möchte ein sicheres und schnelles Passwortverschlüsselungssystem. Das millionenfache Hashing eines Passworts ist zwar sicherer, aber auch langsamer. Wie erreicht man ein ausgewogenes Verhältnis zwischen Geschwindigkeit und Sicherheit? Außerdem würde ich es vorziehen, wenn das Ergebnis eine konstante Anzahl von Zeichen hätte.

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

Soll ich auch zwei Felder in der Datenbank speichern (eines mit MD5 und eines mit SHA)? Würde es sicherer oder unsicherer machen?

Falls ich nicht klar genug war, möchte ich wissen, welche Hashing-Funktion (en) ich verwenden soll (n) und wie ich ein gutes Salz auswähle, 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 Kennwortverschlüsselung
Sichere Methoden zum Speichern von Schlüsseln und Kennwörtern für asp.net Wie würden Sie gesalzene Kennwörter in Tomcat 5.5 implementieren ?

HAFTUNGSAUSSCHLUSS : Diese Antwort wurde 2008 geschrieben.

Seitdem hat uns PHP gegeben password_hashund password_verifyseit ihrer Einführung sind sie die empfohlene Methode zum Hashing und Überprüfen von Passwörtern.

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

TL; DR

Nicht

• Beschränken Sie nicht, welche Zeichen Benutzer für Kennwörter eingeben können. Das machen nur Idioten.
• Begrenzen Sie nicht die Länge eines Passworts. Wenn Ihre Benutzer einen Satz mit supercalifragilisticexpialidocious möchten, hindern Sie sie nicht daran, ihn zu verwenden.
• Entfernen oder entkommen Sie HTML und Sonderzeichen im Passwort nicht.
• Speichern Sie das Passwort Ihres Benutzers niemals im Klartext.
• Senden Sie Ihrem Benutzer niemals ein Passwort per E-Mail, es sei denn, er hat sein Passwort verloren und Sie haben ein temporäres Passwort gesendet.
• Protokollieren Sie niemals Passwörter auf irgendeine Weise.
• Hash-Passwörter niemals mit SHA1 oder MD5 oder sogar SHA256! Moderne Cracker können 60 bzw. 180 Milliarden Hashes / Sekunde überschreiten.
• Mischen Sie nicht bcrypt und mit dem rohen Ausgang von Hash () , entweder Verwendung hex Ausgang oder base64_encode es. (Dies gilt für alle Eingaben, die möglicherweise einen Schurken enthalten \0, der die Sicherheit ernsthaft schwächen kann.)

DOS

• Verwenden Sie scrypt, wenn Sie können. bcrypt wenn du nicht kannst.
• Verwenden Sie PBKDF2, wenn Sie weder bcrypt noch scrypt mit SHA2-Hashes verwenden können.
• Setzen Sie alle Passwörter zurück, wenn die Datenbank gefährdet ist.
• Implementieren Sie eine angemessene Mindestlänge von 8 bis 10 Zeichen und benötigen Sie mindestens 1 Großbuchstaben, 1 Kleinbuchstaben, eine Zahl und ein Symbol. Dies verbessert die Entropie des Passworts und erschwert das Knacken. (Weitere Informationen finden Sie im Abschnitt "Was macht ein gutes Passwort aus?".)

Warum überhaupt Hash-Passwörter?

Das Ziel von Hashing-Passwörtern ist einfach: Verhindern Sie böswilligen Zugriff auf Benutzerkonten, indem Sie die Datenbank gefährden. Das Ziel des Passwort-Hashing ist es also, einen Hacker oder Cracker davon abzuhalten, indem er ihnen zu viel Zeit oder Geld kostet, um die Klartext-Passwörter zu berechnen. Und Zeit / Kosten sind die besten Abschreckungsmittel in Ihrem Arsenal.

Ein weiterer Grund, warum Sie einen guten, robusten Hash für Benutzerkonten wünschen, besteht darin, Ihnen genügend Zeit zu geben, um alle Kennwörter im System zu ändern. Wenn Ihre Datenbank kompromittiert ist, benötigen Sie genügend Zeit, um das System zumindest zu sperren, wenn nicht jedes Kennwort in der Datenbank geändert wird.

Jeremiah Grossman, CTO von Whitehat Security, erklärte auf dem White Hat Security-Blog nach einer kürzlich erfolgten Passwortwiederherstellung, bei der sein Passwortschutz mit Gewalt gebrochen werden musste:

Interessanterweise habe ich beim Ausleben dieses Alptraums VIEL gelernt, was ich nicht über das Knacken, Speichern und die Komplexität von Passwörtern wusste. Ich habe verstanden, warum das Speichern von Passwörtern so viel wichtiger ist als die Komplexität von Passwörtern. Wenn Sie nicht wissen, wie Ihr Passwort gespeichert ist, können Sie sich nur auf die Komplexität verlassen. Dies mag Kennwort- und Krypto-Profis allgemein bekannt sein, aber für den durchschnittlichen InfoSec- oder Web Security-Experten bezweifle ich dies sehr.

(Hervorhebung von mir.)

Was macht ein gutes Passwort überhaupt aus?

Entropie . (Nicht, dass ich Randalls Standpunkt voll und ganz unterschreibe.)

Kurz gesagt, Entropie gibt an, wie stark das Passwort variiert. Wenn ein Passwort nur aus römischen Kleinbuchstaben besteht, sind das nur 26 Zeichen. Das ist nicht viel Abwechslung. Alphanumerische Passwörter sind mit 36 ​​Zeichen besser. Das Zulassen von Groß- und Kleinbuchstaben mit Symbolen beträgt jedoch ungefähr 96 Zeichen. Das ist viel besser als nur Briefe. Ein Problem ist, dass wir Muster einfügen, um unsere Passwörter einprägsam zu machen - was die Entropie verringert. Hoppla!

Die Passwortentropie lässt sich leicht approximieren . Die Verwendung des gesamten Bereichs von ASCII-Zeichen (ungefähr 96 typisierbare Zeichen) ergibt eine Entropie von 6,6 pro Zeichen, was mit 8 Zeichen für ein Kennwort für zukünftige Sicherheit immer noch zu niedrig ist (52,679 Bit Entropie). Die gute Nachricht ist jedoch: Längere Passwörter und Passwörter mit Unicode-Zeichen erhöhen die Entropie eines Passworts erheblich und erschweren das Knacken.

Auf der Crypto StackExchange- Site wird die Kennwortentropie länger diskutiert . Eine gute Google-Suche liefert auch viele Ergebnisse.

In den Kommentaren sprach ich mit @popnoodles, der darauf hinwies, dass das Durchsetzen einer Kennwortrichtlinie mit einer Länge von X mit X vielen Buchstaben, Zahlen, Symbolen usw. die Entropie tatsächlich reduzieren kann, indem das Kennwortschema vorhersehbarer gemacht wird. Ich stimme zu. Zufälligkeit, so wirklich zufällig wie möglich, ist immer die sicherste, aber am wenigsten einprägsame Lösung.

Soweit ich das beurteilen konnte, ist das Erstellen des weltweit besten Passworts ein Catch-22. Entweder ist es nicht einprägsam, zu vorhersehbar, zu kurz, zu viele Unicode-Zeichen (auf einem Windows / Mobile-Gerät schwer einzugeben), zu lang usw. Kein Passwort ist für unsere Zwecke wirklich gut genug, daher müssen wir sie so schützen, als ob sie es wären waren in Fort Knox.

Empfohlene Vorgehensweise

Bcrypt und Scrypt sind die aktuellen Best Practices. Scrypt wird mit der Zeit besser sein als bcrypt, aber es wurde weder von Linux / Unix noch von Webservern als Standard übernommen, und es wurden noch keine eingehenden Überprüfungen des Algorithmus veröffentlicht. Dennoch sieht die Zukunft des Algorithmus vielversprechend aus. Wenn Sie mit Ruby arbeiten, gibt es ein Verschlüsselungsjuwel , das Ihnen helfen wird, und Node.js hat jetzt ein eigenes Verschlüsselungspaket . Sie können Scrypt in PHP entweder über die Scrypt- Erweiterung oder die Libsodium- Erweiterung verwenden (beide sind in PECL verfügbar).

Ich schlage vor , hoch in der Dokumentation zum Lesen Krypta Funktion , wenn Sie verstehen wollen , wie bcrypt zu verwenden oder sich selbst eine Suche nach guten Wrapper oder die Verwendung so etwas wie PHPASS für eine Legacy - Implementierung. Ich empfehle mindestens 12 Runden bcrypt, wenn nicht 15 bis 18.

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

Durchschnittliche Praktiken

Ich kann mir diese Situation fast nicht mehr vorstellen. PHPASS unterstützt PHP 3.0.18 bis 5.3, sodass es für fast jede denkbare Installation verwendet werden kann - und sollte verwendet werden, wenn Sie nicht sicher sind, dass Ihre Umgebung bcrypt unterstützt.

Angenommen, Sie können bcrypt oder PHPASS überhaupt nicht verwenden. Was dann?

Versuchen Sie eine Implementierung von PDKBF2 mit der maximalen Anzahl von Runden , die Ihre Umgebung / Anwendung / Benutzerwahrnehmung tolerieren kann. Die niedrigste Zahl, die ich empfehlen würde, ist 2500 Runden. Stellen Sie außerdem sicher, dass Sie hash_hmac () verwenden, wenn es verfügbar ist, um die Wiedergabe des Vorgangs zu erschweren.

Zukünftige Praktiken

PHP 5.5 ist eine vollständige Passwortschutzbibliothek, die alle Probleme bei der Arbeit mit bcrypt beseitigt. Während die meisten von uns in den meisten gängigen Umgebungen, insbesondere bei gemeinsam genutzten Hosts, mit PHP 5.2 und 5.3 nicht weiterkommen, hat @ircmaxell eine Kompatibilitätsschicht für die kommende API erstellt, die abwärtskompatibel zu PHP 5.3.7 ist.

Zusammenfassung und Haftungsausschluss für Kryptografie

Die Rechenleistung, die erforderlich ist, um ein Hash-Passwort tatsächlich zu knacken, ist nicht vorhanden. Die einzige Möglichkeit für Computer, ein Kennwort zu "knacken", besteht darin, es neu zu erstellen und den zum Sichern verwendeten Hashing-Algorithmus zu simulieren. Die Geschwindigkeit des Hashs hängt linear von seiner Fähigkeit ab, brutal gezwungen zu werden. Schlimmer noch, die meisten Hash-Algorithmen können einfach parallelisiert werden, um eine noch schnellere Leistung zu erzielen. Aus diesem Grund sind kostspielige Schemata 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 im Voraus zu schützen . Wenn Sie dies nicht tun, verpassen Sie möglicherweise sogar die Tatsache, dass Sie angegriffen wurden, bis es zu spät ist ... und Sie haften . Um diese Situation zu vermeiden, handeln Sie zunächst paranoid. 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 nur sich selbst die Schuld geben.

Schließlich: Ich bin kein Kryptograf. Was auch immer ich gesagt habe, ist meine Meinung, aber ich denke, es basiert auf gesundem Menschenverstand ... und viel Lesen. Denken Sie daran, seien Sie so paranoid wie möglich, machen Sie es so schwer wie möglich, sich einzumischen, und wenden Sie sich dann, wenn Sie immer noch besorgt sind, an einen White-Hat-Hacker oder Kryptographen, um zu erfahren, was er über Ihren Code / Ihr System sagt.

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

• PHP 5.5 oder höher: password_hash () ist von guter Qualität und Teil des PHP-Kerns.
• Ältere PHP-Versionen: Die Phpass- Bibliothek von OpenWall ist viel besser als die meisten benutzerdefinierten Codes - sie werden in WordPress, Drupal usw. verwendet.

Die meisten Programmierer verfügen einfach nicht über das Fachwissen, um kryptobezogenen Code sicher zu schreiben, ohne Schwachstellen einzuführen.

Schneller Selbsttest: Was ist Passwort-Stretching und wie viele Iterationen sollten Sie verwenden? Wenn Sie die Antwort nicht kennen, sollten Sie sie verwenden password_hash(), da die Kennwortverlängerung aufgrund der viel schnelleren CPUs und der Verwendung von GPUs und FPGAs zum Knacken von Kennwörtern mit einer Rate von Milliarden von Vermutungen pro Sekunde (mit GPUs) jetzt ein wichtiges Merkmal von Kennwortmechanismen ist ).

Sie können beispielsweise alle 8-stelligen Windows-Kennwörter in 6 Stunden mit 25 GPUs knacken, die auf 5 Desktop-PCs installiert sind. Dies ist Brute-Forcing, dh das Auflisten und Überprüfen jedes 8-stelligen Windows-Kennworts , einschließlich Sonderzeichen, und kein Wörterbuchangriff. Das war im Jahr 2012, ab 2018 konnte man weniger GPUs verwenden oder mit 25 GPUs schneller knacken.

Es gibt auch viele Regenbogentabellenangriffe auf Windows-Kennwörter, die auf normalen CPUs ausgeführt werden und sehr schnell sind. All dies liegt daran, dass Windows seine Kennwörter auch unter Windows 10 immer noch nicht salzt oder erweitert - machen Sie nicht den gleichen Fehler wie Microsoft!

Siehe auch:

• ausgezeichnete Antwort mit mehr darüber, warum password_hash()oder phpasssind der beste Weg zu gehen.
• Guter Blog-Artikel mit empfohlenen 'Arbeitsfaktoren' (Anzahl der Iterationen) für Hauptalgorithmen wie bcrypt, scrypt und PBKDF2.

Ich würde das Passwort-Hash nicht auf zwei verschiedene Arten speichern, da das System dann mindestens so schwach ist wie der schwächste der verwendeten Hash-Algorithmen.

Ab PHP 5.5 verfügt PHP über einfache, sichere Funktionen zum Hashing und Überprüfen von Passwörtern, password_hash () und password_verify ().

$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

Bei password_hash()Verwendung wird ein zufälliges Salt generiert und in den ausgegebenen Hash (zusammen mit den verwendeten Kosten und dem verwendeten Algorithmus) aufgenommen. password_verify()Anschließend wird dieser Hash gelesen, die verwendete Salt- und Verschlüsselungsmethode ermittelt und anhand des angegebenen Klartextkennworts überprüft.

Durch die Bereitstellung der PASSWORD_DEFAULTAnweisungen wird PHP angewiesen, den Standard-Hashing-Algorithmus der installierten Version von PHP zu verwenden. Welcher Algorithmus genau bedeutet, soll sich in zukünftigen Versionen im Laufe der Zeit ändern, so dass er immer einer der stärksten verfügbaren Algorithmen sein wird.

Das Erhöhen der Kosten (standardmäßig 10) erschwert das Brute-Force-Testen des Hashs, bedeutet aber auch, dass das Generieren von Hashes und das Überprüfen von Kennwörtern für die CPU Ihres Servers mehr Arbeit bedeutet.

Beachten Sie, dass alte Hashes, obwohl sich der Standard-Hashing-Algorithmus möglicherweise ändert, weiterhin einwandfrei überprüft werden, da der verwendete Algorithmus im Hash gespeichert ist und diesen password_verify()aufgreift.

Obwohl die Frage beantwortet wurde, möchte ich nur wiederholen, dass die zum Hashing verwendeten Salze zufällig sein sollten und nicht der in der ersten Antwort vorgeschlagenen E-Mail-Adresse entsprechen sollten.

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 zufälligen Bits gesalzene Passwort-Hashes sicherer sind als mit erratenen oder bekannten Salzen gesalzene. Mal sehen: Wenn das System, das das Passwort speichert, sowie das System, das das zufällige Salz speichert, gefährdet sind, hat der Angreifer Zugriff auf Hash und Salz. Es spielt also keine Rolle, ob das Salz zufällig ist oder nicht. Der Angreifer kann vorberechnete Regenbogentabellen generieren, um den Hash zu knacken. Hier kommt der interessante Teil - es ist nicht so trivial, vorberechnete Tabellen zu generieren. Nehmen wir ein Beispiel für ein WPA-Sicherheitsmodell. Ihr WPA-Passwort wird eigentlich nie an den Wireless Access Point gesendet. Stattdessen wird es mit Ihrer SSID (dem Netzwerknamen wie Linksys, Dlink usw.) gehasht. Eine sehr gute Erklärung, wie das funktioniert, finden Sie hier. Um das Passwort vom Hash abzurufen, Sie müssen das Passwort sowie Salt (Netzwerkname) kennen. Church of Wifi hat bereits Hash-Tabellen mit 1000 SSIDs und etwa 1 Million Passwörtern vorberechnet. Die Größe aller Tabellen beträgt ca. 40 GB. Wie Sie auf ihrer Website lesen können, hat jemand 3 Tage lang 15 FGPA-Arrays verwendet, um diese Tabellen zu generieren. Angenommen, das Opfer verwendet die SSID als "a387csf3" und das Passwort als "123456". Wird sie von diesen Tabellen geknackt? Nein! .. es kann nicht. Selbst wenn das Passwort schwach ist, haben die Tabellen keine Hashes für die SSID a387csf3. Das ist das Schöne an zufälligem Salz. Es wird Cracker abschrecken, die von vorberechneten Tabellen leben. Kann es einen entschlossenen Hacker aufhalten? Wahrscheinlich nicht. Die Verwendung von zufälligen Salzen bietet jedoch eine zusätzliche Verteidigungsschicht. Während wir uns mit diesem Thema befassen, Lassen Sie uns den zusätzlichen Vorteil der Lagerung von zufälligen Salzen auf einem separaten System diskutieren. Szenario 1: Kennwort-Hashes werden auf System X gespeichert, und für das Hashing verwendete Salzwerte werden auf System Y gespeichert. Diese Salzwerte sind erraten oder bekannt (z. B. Benutzername). Szenario 2: Kennwort-Hashes werden auf System X gespeichert und Salzwerte für verwendet Hashing wird auf System Y gespeichert. Diese Salzwerte sind zufällig. Falls System X kompromittiert wurde, wie Sie sich vorstellen können, besteht ein großer Vorteil darin, zufälliges Salz auf einem separaten System zu verwenden (Szenario 2). Der Angreifer muss Additionswerte erraten, um Hashes knacken zu können. Wenn ein 32-Bit-Salt verwendet wird, können für jedes erratene Passwort 2 ^ 32 = 4.294.967.296 (ca. 4,2 Milliarden) Iterationen erforderlich sein. Passwort-Hashes werden auf System X gespeichert, und für das Hashing verwendete Salt-Werte werden auf System Y gespeichert. Diese Salt-Werte sind erraten oder bekannt (z. B. Benutzername). Szenario 2: Passwort-Hashes werden auf System X gespeichert und Salt-Werte, die für das Hashing verwendet werden, werden auf System X gespeichert System Y. Diese Salzwerte sind zufällig. Falls System X kompromittiert wurde, wie Sie sich vorstellen können, besteht ein großer Vorteil darin, zufälliges Salz auf einem separaten System zu verwenden (Szenario 2). Der Angreifer muss Additionswerte erraten, um Hashes knacken zu können. Wenn ein 32-Bit-Salt verwendet wird, können für jedes erratene Passwort 2 ^ 32 = 4.294.967.296 (ca. 4,2 Milliarden) Iterationen erforderlich sein. Passwort-Hashes werden auf System X gespeichert, und für das Hashing verwendete Salt-Werte werden auf System Y gespeichert. Diese Salt-Werte sind erraten oder bekannt (z. B. Benutzername). Szenario 2: Passwort-Hashes werden auf System X gespeichert und Salt-Werte, die für das Hashing verwendet werden, werden auf System X gespeichert System Y. Diese Salzwerte sind zufällig. Falls System X kompromittiert wurde, wie Sie sich vorstellen können, besteht ein großer Vorteil darin, zufälliges Salz auf einem separaten System zu verwenden (Szenario 2). Der Angreifer muss Additionswerte erraten, um Hashes knacken zu können. Wenn ein 32-Bit-Salt verwendet wird, können für jedes erratene Passwort 2 ^ 32 = 4.294.967.296 (ca. 4,2 Milliarden) Iterationen erforderlich sein. Diese Salzwerte sind zufällig. Falls System X kompromittiert wurde, wie Sie sich vorstellen können, besteht ein großer Vorteil darin, zufälliges Salz auf einem separaten System zu verwenden (Szenario 2). Der Angreifer muss Additionswerte erraten, um Hashes knacken zu können. Wenn ein 32-Bit-Salt verwendet wird, können für jedes erratene Passwort 2 ^ 32 = 4.294.967.296 (ca. 4,2 Milliarden) Iterationen erforderlich sein. Diese Salzwerte sind zufällig. Falls System X kompromittiert wurde, wie Sie sich vorstellen können, besteht ein großer Vorteil darin, zufälliges Salz auf einem separaten System zu verwenden (Szenario 2). Der Angreifer muss Additionswerte erraten, um Hashes knacken zu können. Wenn ein 32-Bit-Salt verwendet wird, können für jedes erratene Passwort 2 ^ 32 = 4.294.967.296 (ca. 4,2 Milliarden) Iterationen erforderlich sein.

Ich möchte nur darauf hinweisen, dass PHP 5.5 eine Passwort-Hashing-API enthält , die einen Wrapper bietet crypt(). Diese API vereinfacht das Hashing, Überprüfen und Aufbereiten von Kennwort-Hashes erheblich. Der Autor hat auch ein Kompatibilitätspaket (in Form einer einzelnen password.php-Datei, die Sie einfach requireverwenden können) für diejenigen veröffentlicht, die PHP 5.3.7 und höher verwenden und dieses sofort verwenden möchten.

Derzeit wird nur BCRYPT unterstützt, es soll jedoch problemlos um andere Kennwort-Hashing-Techniken erweitert werden. Da die Technik und die Kosten als Teil des Hash gespeichert werden, werden Änderungen an Ihrer bevorzugten Hashing-Technik / den Kosten die aktuellen Hashes und das Framework nicht ungültig machen wird automatisch die richtige Technik / Kosten bei der Validierung verwenden. Es wird auch die Erzeugung eines "sicheren" Salzes behandelt, wenn Sie Ihr eigenes nicht explizit definieren.

Die API bietet vier Funktionen:

• password_get_info() - gibt Informationen über den angegebenen Hash zurück
• password_hash() - Erstellt einen Passwort-Hash
• password_needs_rehash()- prüft, ob der angegebene Hash mit den angegebenen Optionen übereinstimmt. Nützlich, um zu überprüfen, ob der Hash Ihrer aktuellen Technik / Ihrem aktuellen Kostenschema entspricht, sodass Sie ihn bei Bedarf erneut aufbereiten können
• password_verify() - überprüft, ob ein Passwort mit einem Hash übereinstimmt

Momentan akzeptieren diese Funktionen die Passwortkonstanten PASSWORD_BCRYPT und PASSWORD_DEFAULT, die derzeit synonym sind. Der Unterschied besteht darin, dass sich PASSWORD_DEFAULT "in neueren PHP-Versionen ändern kann, wenn neuere, stärkere Hashing-Algorithmen unterstützt werden." Durch die Verwendung von PASSWORD_DEFAULT und password_needs_rehash () beim Anmelden (und ggf. erneutes Aufwärmen) sollte sichergestellt werden, dass Ihre Hashes gegenüber Brute-Force-Angriffen einigermaßen widerstandsfähig sind, ohne dass Sie Arbeit benötigen.

EDIT: Ich habe gerade festgestellt, dass dies in der Antwort von Robert K kurz erwähnt wird. Ich werde diese Antwort hier belassen, da ich denke, dass sie ein bisschen mehr Informationen über die Funktionsweise und die Benutzerfreundlichkeit für diejenigen bietet, die die Sicherheit nicht kennen.

Ich verwende Phpass , eine einfache PHP-Klasse mit einer Datei, die in fast jedem PHP-Projekt sehr einfach implementiert werden kann. Siehe auch die H .

Standardmäßig wurde die stärkste verfügbare Verschlüsselung verwendet, die in Phpass implementiert ist. Dies ist bcryptund greift auf andere Verschlüsselungen bis hin zu MD5 zurück, um die Abwärtskompatibilität mit Frameworks wie Wordpress zu gewährleisten.

Der zurückgegebene Hash kann unverändert in der Datenbank gespeichert werden. Beispiel für die Verwendung zum Generieren von Hash ist:

$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($password);

Um das Passwort zu überprüfen, kann man verwenden:

$t_hasher = new PasswordHash(8, FALSE);
$check = $t_hasher->CheckPassword($password, $hash);

DINGE ZU ERINNERN

Es wurde viel über die Kennwortverschlüsselung für PHP gesagt, von denen die meisten sehr gute Ratschläge sind. Bevor Sie jedoch mit der Verwendung von PHP für die Kennwortverschlüsselung beginnen, stellen Sie sicher, dass Folgendes implementiert ist oder implementiert werden kann.

SERVER

HÄFEN

Egal wie gut Ihre Verschlüsselung ist, wenn Sie den Server, auf dem PHP und DB ausgeführt werden, nicht ordnungsgemäß sichern, sind alle Ihre Bemühungen wertlos. Die meisten Server funktionieren relativ gleich, ihnen sind Ports zugewiesen, mit denen Sie entweder über FTP oder Shell remote auf sie zugreifen können. Stellen Sie sicher, dass Sie den Standardport der jeweils aktiven Remoteverbindung ändern. Wenn Sie dies nicht tun, haben Sie den Angreifer tatsächlich dazu gebracht, einen Schritt weniger auf Ihr System zuzugreifen.

NUTZERNAME

Verwenden Sie für alles, was auf der Welt gut ist, nicht den Benutzernamen admin, root oder ähnliches. Auch wenn Sie sich auf einem Unix-basierten System befinden, machen Sie die Anmeldung für das Root-Konto NICHT zugänglich. Es sollte immer nur sudo sein.

PASSWORT

Sie fordern Ihre Benutzer auf, gute Passwörter zu erstellen, um nicht gehackt zu werden. Machen Sie dasselbe. Was bringt es, wenn Sie die Vordertür abschließen, wenn die Hintertür weit geöffnet ist?

DATENBANK

SERVER

Idealerweise möchten Sie Ihre Datenbank und ANWENDUNG auf separaten Servern. Dies ist aus Kostengründen nicht immer möglich, bietet jedoch eine gewisse Sicherheit, da der Angreifer zwei Schritte ausführen muss, um vollständig auf das System zugreifen zu können.

BENUTZER

Lassen Sie Ihre Anwendung immer über ein eigenes Konto verfügen, um auf die Datenbank zuzugreifen, und geben Sie ihr nur die erforderlichen Berechtigungen.

Dann haben Sie ein separates Benutzerkonto für Sie, das nirgendwo auf dem Server gespeichert ist, auch nicht in der Anwendung.

Wie immer NICHT diese Wurzel oder ähnliches machen.

PASSWORT

Befolgen Sie die gleichen Richtlinien wie bei allen guten Passwörtern. Verwenden Sie dasselbe Kennwort auch nicht auf SERVER- oder DB-Konten auf demselben System.

PHP

PASSWORT

Speichern Sie NIEMALS ein Passwort in Ihrer Datenbank, sondern den Hash und das eindeutige Salt. Ich werde später erklären, warum.

HASHING

ONE WAY HASHING !!!!!!! auf die gleiche Weise und vergleichen Sie die beiden Hashes. Dies bedeutet, dass ein Angreifer, selbst wenn er Zugriff auf die Datenbank erhält, nicht weiß, wie das eigentliche Kennwort lautet, sondern nur den daraus resultierenden Hash. Dies bedeutet mehr Sicherheit für Ihre Benutzer im schlimmsten Fall.

Es gibt viele gute Hashing - Funktionen gibt ( password_hash, hashetc ...) , aber Sie brauchen einen guten Algorithmus zu wählen , für die Hash wirksam zu sein. (bcrypt und ähnliche sind anständige Algorithmen.)

Wenn die Hashing-Geschwindigkeit der Schlüssel ist, ist Brate Force-Angriffe umso widerstandsfähiger, je langsamer sie sind.

Einer der häufigsten Fehler beim Hashing ist, dass Hashes nicht nur für Benutzer gelten. Dies liegt hauptsächlich daran, dass Salze nicht eindeutig erzeugt werden.

SALZEN

Passwörter sollten vor dem Hashing immer gesalzen werden. Salting fügt dem Kennwort eine zufällige Zeichenfolge hinzu, sodass ähnliche Kennwörter in der Datenbank nicht gleich angezeigt werden. Wenn das Salz jedoch nicht für jeden Benutzer einzigartig ist (dh Sie verwenden ein hartcodiertes Salz), haben Sie Ihr Salz so ziemlich wertlos gemacht. Denn sobald ein Angreifer ein Passwort herausfindet, hat er das Salz für alle.

Wenn Sie ein Salt erstellen, stellen Sie sicher, dass es für das zu salzende Kennwort eindeutig ist, und speichern Sie dann sowohl den vollständigen Hash als auch das Salt in Ihrer Datenbank. Dies bewirkt, dass ein Angreifer jedes Salz und jeden Hasch einzeln knacken muss, bevor er Zugriff erhält. Dies bedeutet viel mehr Arbeit und Zeit für den Angreifer.

BENUTZER, DIE PASSWÖRTER ERSTELLEN

Wenn der Benutzer ein Kennwort über das Frontend erstellt, bedeutet dies, dass es an den Server gesendet werden muss. Dies führt zu einem Sicherheitsproblem, da das unverschlüsselte Kennwort an den Server gesendet wird und wenn ein Angreifer abhören und darauf zugreifen kann, dass Ihre gesamte Sicherheit in PHP wertlos ist. Übertragen Sie die Daten IMMER SICHER, dies geschieht über SSL, aber seien Sie müde, auch wenn SSL nicht fehlerfrei ist (der Heartbleed-Fehler von OpenSSL ist ein Beispiel dafür).

Lassen Sie den Benutzer auch ein sicheres Passwort erstellen, es ist einfach und sollte immer gemacht werden, der Benutzer wird am Ende dafür dankbar sein.

Unabhängig davon, welche Sicherheitsmaßnahmen Sie ergreifen, ist nichts 100% sicher. Je fortschrittlicher die zu schützende Technologie ist, desto fortschrittlicher werden die Angriffe. Wenn Sie diese Schritte befolgen, wird Ihre Website sicherer und für Angreifer weitaus weniger wünschenswert.

Hier ist eine PHP-Klasse, die auf einfache Weise einen Hash und Salt für ein Passwort erstellt

http://git.io/mSJqpw

Google sagt, dass SHA256 für PHP verfügbar ist.

Sie sollten auf jeden Fall ein Salz verwenden. Ich würde empfehlen, zufällige Bytes zu verwenden (und sich nicht auf Zeichen und Zahlen zu beschränken). Wie gewöhnlich wird es umso langsamer, je länger Sie wählen. 64 Bytes sollten in Ordnung sein, denke ich.

Letztendlich bietet Double-Hashing mathematisch keinen Vorteil. In der Praxis ist es jedoch nützlich, um Angriffe auf der Basis von Regenbogentabellen zu verhindern. Mit anderen Worten, es ist nicht vorteilhafter als das Hashing mit einem Salz, was in Ihrer Anwendung oder auf Ihrem Server viel weniger Prozessorzeit in Anspruch nimmt.

Ich habe hier ein perfektes Thema zu diesem Thema gefunden: https://crackstation.net/hashing-security.htm , ich wollte, dass Sie davon profitieren. Hier ist auch der Quellcode, der auch Schutz vor zeitbasierten Angriffen bietet.

<?php
/*
 * Password hashing with PBKDF2.
 * Author: havoc AT defuse.ca
 * www: https://defuse.ca/php-pbkdf2.htm
 */

// These constants may be changed without breaking existing hashes.
define("PBKDF2_HASH_ALGORITHM", "sha256");
define("PBKDF2_ITERATIONS", 1000);
define("PBKDF2_SALT_BYTES", 24);
define("PBKDF2_HASH_BYTES", 24);

define("HASH_SECTIONS", 4);
define("HASH_ALGORITHM_INDEX", 0);
define("HASH_ITERATION_INDEX", 1);
define("HASH_SALT_INDEX", 2);
define("HASH_PBKDF2_INDEX", 3);

function create_hash($password)
{
    // format: algorithm:iterations:salt:hash
    $salt = base64_encode(mcrypt_create_iv(PBKDF2_SALT_BYTES, MCRYPT_DEV_URANDOM));
    return PBKDF2_HASH_ALGORITHM . ":" . PBKDF2_ITERATIONS . ":" .  $salt . ":" . 
        base64_encode(pbkdf2(
            PBKDF2_HASH_ALGORITHM,
            $password,
            $salt,
            PBKDF2_ITERATIONS,
            PBKDF2_HASH_BYTES,
            true
        ));
}

function validate_password($password, $good_hash)
{
    $params = explode(":", $good_hash);
    if(count($params) < HASH_SECTIONS)
       return false; 
    $pbkdf2 = base64_decode($params[HASH_PBKDF2_INDEX]);
    return slow_equals(
        $pbkdf2,
        pbkdf2(
            $params[HASH_ALGORITHM_INDEX],
            $password,
            $params[HASH_SALT_INDEX],
            (int)$params[HASH_ITERATION_INDEX],
            strlen($pbkdf2),
            true
        )
    );
}

// Compares two strings $a and $b in length-constant time.
function slow_equals($a, $b)
{
    $diff = strlen($a) ^ strlen($b);
    for($i = 0; $i < strlen($a) && $i < strlen($b); $i++)
    {
        $diff |= ord($a[$i]) ^ ord($b[$i]);
    }
    return $diff === 0; 
}

/*
 * PBKDF2 key derivation function as defined by RSA's PKCS #5: https://www.ietf.org/rfc/rfc2898.txt
 * $algorithm - The hash algorithm to use. Recommended: SHA256
 * $password - The password.
 * $salt - A salt that is unique to the password.
 * $count - Iteration count. Higher is better, but slower. Recommended: At least 1000.
 * $key_length - The length of the derived key in bytes.
 * $raw_output - If true, the key is returned in raw binary format. Hex encoded otherwise.
 * Returns: A $key_length-byte key derived from the password and salt.
 *
 * Test vectors can be found here: https://www.ietf.org/rfc/rfc6070.txt
 *
 * This implementation of PBKDF2 was originally created by https://defuse.ca
 * With improvements by http://www.variations-of-shadow.com
 */
function pbkdf2($algorithm, $password, $salt, $count, $key_length, $raw_output = false)
{
    $algorithm = strtolower($algorithm);
    if(!in_array($algorithm, hash_algos(), true))
        die('PBKDF2 ERROR: Invalid hash algorithm.');
    if($count <= 0 || $key_length <= 0)
        die('PBKDF2 ERROR: Invalid parameters.');

    $hash_length = strlen(hash($algorithm, "", true));
    $block_count = ceil($key_length / $hash_length);

    $output = "";
    for($i = 1; $i <= $block_count; $i++) {
        // $i encoded as 4 bytes, big endian.
        $last = $salt . pack("N", $i);
        // first iteration
        $last = $xorsum = hash_hmac($algorithm, $last, $password, true);
        // perform the other $count - 1 iterations
        for ($j = 1; $j < $count; $j++) {
            $xorsum ^= ($last = hash_hmac($algorithm, $last, $password, true));
        }
        $output .= $xorsum;
    }

    if($raw_output)
        return substr($output, 0, $key_length);
    else
        return bin2hex(substr($output, 0, $key_length));
}
?>

Normalerweise verwende ich SHA1 und Salz mit der Benutzer-ID (oder einer anderen benutzerspezifischen Information), und manchmal verwende ich zusätzlich ein konstantes Salz (also habe ich 2 Teile zum Salz).

SHA1 wird jetzt auch als etwas kompromittiert angesehen, jedoch in weitaus geringerem Maße als MD5. Durch die Verwendung eines Salzes (eines beliebigen Salzes) verhindern Sie die Verwendung einer generischen Regenbogentabelle , um Ihre Hashes anzugreifen (einige Leute haben sogar erfolgreich Google als eine Art Regenbogentabelle verwendet, indem sie nach dem Hash gesucht haben). Ein Angreifer könnte möglicherweise mit Ihrem Salz eine Regenbogentabelle erstellen. Deshalb sollten Sie ein benutzerspezifisches Salz hinzufügen. Auf diese Weise müssen sie für jeden Datensatz in Ihrem System eine Regenbogentabelle erstellen, nicht nur für Ihr gesamtes System! Mit dieser Art des Salzens ist sogar MD5 anständig sicher.

SHA1 und ein Salz sollten auf absehbare Zeit ausreichen (natürlich abhängig davon, ob Sie etwas für Fort Knox oder ein Anmeldesystem für Ihre Einkaufsliste codieren ). Wenn SHA1 für Sie nicht gut genug ist, verwenden Sie SHA256 .

Die Idee eines Salzes ist es, die Hashing-Ergebnisse sozusagen aus dem Gleichgewicht zu bringen. Es ist zum Beispiel bekannt, dass der MD5-Hash einer leeren Zeichenfolge ist d41d8cd98f00b204e9800998ecf8427e. Wenn also jemand mit einem guten Gedächtnis diesen Hash sehen und wissen würde, dass es der Hash einer leeren Zeichenfolge ist. Wenn die Zeichenfolge jedoch gesalzen ist (z. B. mit der Zeichenfolge " MY_PERSONAL_SALT"), wird der Hash für die "leere Zeichenfolge" (dh " MY_PERSONAL_SALT") aeac2612626724592271634fb14d3ea6und ist daher für die Rückverfolgung nicht offensichtlich. Was ich versuche zu sagen, dass es besser ist , zu verwenden , jedes Salz, als nicht zu. Daher ist es nicht allzu wichtig zu wissen, welches Salz verwendet werden soll.

Es gibt tatsächlich Websites, die genau dies tun - Sie können ihm einen (md5) -Hash geben, und er spuckt einen bekannten Klartext aus, der diesen bestimmten Hash generiert. Wenn Sie Zugriff auf eine Datenbank erhalten würden, in der einfache MD5-Hashes gespeichert sind, wäre es für Sie trivial, den Hash für den Administrator eines solchen Dienstes einzugeben und sich anzumelden. Wenn die Kennwörter jedoch gesalzen wären, würde ein solcher Dienst zu einem solchen Dienst unwirksam.

Außerdem wird Double-Hashing im Allgemeinen als schlechte Methode angesehen, da es den Ergebnisraum verringert. Alle gängigen Hashes haben eine feste Länge. Sie können also nur endliche Werte dieser festen Länge haben, und die Ergebnisse werden weniger unterschiedlich. Dies könnte als eine andere Form des Salzens angesehen werden, aber ich würde es nicht empfehlen.

ok in der Fitsy brauchen wir Salz Salz muss einzigartig sein, also lassen Sie es erzeugen

   /**
     * Generating string
     * @param $size
     * @return string
     */
    function Uniwur_string($size){
        $text = md5(uniqid(rand(), TRUE));
        RETURN substr($text, 0, $size);
    }

auch wir brauchen den Hash Ich benutze sha512 es ist das beste und es ist in PHP

   /**
     * Hashing string
     * @param $string
     * @return string
     */
    function hash($string){
        return hash('sha512', $string);
    }

Jetzt können wir diese Funktionen verwenden, um ein sicheres Passwort zu generieren

// generating unique password
$password = Uniwur_string(20); // or you can add manual password
// generating 32 character salt
$salt = Uniwur_string(32);
// now we can manipulate this informations

// hashin salt for safe
$hash_salt = hash($salt);
// hashing password
$hash_psw = hash($password.$hash_salt);

Jetzt müssen wir unseren Variablenwert $ hash_psw und unsere Variable $ salt in der Datenbank speichern

und für die Autorisierung werden wir die gleichen Schritte verwenden ...

Dies ist der beste Weg, um die Passwörter unserer Kunden zu schützen ...

Ps für die letzten 2 Schritte können Sie Ihren eigenen Algorithmus verwenden ... aber stellen Sie sicher, dass Sie dieses Hash-Passwort in Zukunft generieren können, wenn Sie den Benutzer autorisieren müssen ...