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

StackOverflow https://stackoverflow.com/questions/401656

Frage

Derzeit heißt es, MD5 sei teilweise unsicher.Vor diesem Hintergrund würde ich gerne wissen, welchen Mechanismus ich zum Passwortschutz verwenden soll.

Diese Frage, Ist das „doppelte Hashing“ eines Passworts weniger sicher als das einmalige Hashing? legt nahe, dass mehrmaliges Hashing eine gute Idee sein könnte Wie implementiert man einen Passwortschutz für einzelne Dateien? schlägt die Verwendung von Salz vor.

Ich verwende PHP.Ich möchte ein sicheres und schnelles Passwortverschlüsselungssystem.Das millionenfache Hashen eines Passworts ist möglicherweise sicherer, aber auch langsamer.Wie erreicht man eine gute Balance 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 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 (eines beispielsweise mit MD5 und ein anderes mit SHA)?Würde es es sicherer oder unsicherer machen?

Falls ich mich nicht klar genug ausgedrückt habe: Ich möchte wissen, welche Hashing-Funktion(en) ich verwenden muss und wie ich ein gutes Salt 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 Passwortverschlüsselung
Sichere Methoden zum Speichern von Schlüsseln und Passwörtern für asp.net
Wie würden Sie gesalzene Passwörter in Tomcat 5.5 implementieren?

War es hilfreich?

Lösung

HAFTUNGSAUSSCHLUSS:Diese Antwort wurde 2008 verfasst.

Seitdem hat uns PHP gegeben password_hash Und password_verify und seit ihrer Einführung sind sie die empfohlene Methode zum Hashen und Überprüfen von Passwörtern.

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

TL;DR

Verbote

  • Beschränken Sie nicht die Zeichen, die Benutzer für Passwörter eingeben können.Das machen nur Idioten.
  • Beschränken Sie nicht die Länge eines Passworts.Wenn Ihre Benutzer einen Satz mit supercalifragilisticexpialidocious möchten, hindern Sie sie nicht daran, ihn zu verwenden.
  • Speichern Sie das Passwort Ihres Benutzers niemals im Klartext.
  • Senden Sie Ihrem Benutzer niemals ein Passwort per E-Mail es sei denn, sie haben ihr Exemplar verloren und Sie haben ein vorübergehendes Exemplar geschickt.
  • Protokollieren Sie niemals Passwörter in irgendeiner Weise.
  • Hashen Sie niemals Passwörter mit SHA1 oder MD5 oder sogar SHA256! Moderne Cracker kann 60 bzw. 180 Milliarden Hashes/Sekunde überschreiten.
  • Nicht mischen bcrypt und mit dem roh Ausgabe von hash(), verwenden Sie entweder die Hex-Ausgabe oder base64_encode sie.(Dies gilt für alle Eingaben, die möglicherweise einen Fehler enthalten \0 enthalten, was die Sicherheit ernsthaft schwächen kann.)

DOS

  • Verwenden Sie Scrypt, wenn Sie können.bcrypt, wenn Sie das nicht können.
  • 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–10 Zeichen und fordern Sie außerdem mindestens 1 Großbuchstaben, 1 Kleinbuchstaben, eine Zahl und ein Symbol.Dadurch wird die Entropie des Passworts verbessert, was wiederum das Knacken erschwert.(Einige Diskussionen finden Sie im Abschnitt „Was macht ein gutes Passwort aus?“).

Warum überhaupt Hash-Passwörter?

Das Ziel hinter dem Hashing von Passwörtern ist einfach:Verhinderung böswilliger Zugriffe auf Benutzerkonten durch Gefährdung der Datenbank.Das Ziel des Passwort-Hashings besteht also darin, einen Hacker oder Cracker abzuschrecken, indem es ihn zu viel Zeit oder Geld kostet, die Klartext-Passwörter zu berechnen.Und Zeit/Kosten sind die besten Abschreckungsmittel in Ihrem Arsenal.

Ein weiterer Grund dafür, dass Sie einen guten, robusten Hash für ein Benutzerkonto wünschen, besteht darin, dass Sie genügend Zeit haben, alle Passwörter im System zu ändern.Wenn Ihre Datenbank kompromittiert ist, benötigen Sie genügend Zeit, um dies zu beheben am wenigsten Sperren Sie das System, wenn nicht, ändern Sie jedes Passwort in der Datenbank.

Jeremiah Grossman, CTO von Whitehat Security, erklärte auf seinem Blog nach einer kürzlich erfolgten Passwortwiederherstellung, die eine brutale Aufhebung seines Passwortschutzes erforderte:

Interessanterweise habe ich durch das Durchleben dieses Albtraums VIEL über das Knacken, Speichern und die Komplexität von Passwörtern gelernt, was ich nicht wusste. Ich habe verstanden, warum die Speicherung von Passwörtern so viel wichtiger ist als die Komplexität von Passwörtern.Wenn Sie nicht wissen, wie Ihr Passwort gespeichert wird, können Sie sich nur auf die Komplexität verlassen. Dies mag für Passwort- und Krypto-Profis allgemein bekannt sein, aber für den durchschnittlichen InfoSec- oder Web-Sicherheitsexperten bezweifle ich es stark.

(Hervorhebung von mir.)

Was macht ein Gut Passwort trotzdem?

Entropie.(Nicht, dass ich Randalls Standpunkt voll und ganz unterstütze.)

Kurz gesagt, Entropie gibt an, wie groß die Variation innerhalb des Passworts ist.Wenn ein Passwort nur aus lateinischen Kleinbuchstaben besteht, sind das nur 26 Zeichen.Das ist nicht viel Abwechslung.Besser sind alphanumerische Passwörter mit 36 ​​Zeichen.Die zulässige Groß- und Kleinschreibung mit Symbolen beträgt jedoch etwa 96 Zeichen.Das ist viel besser als nur Briefe.Ein Problem besteht darin, dass wir Muster einfügen, um unsere Passwörter einprägsam zu machen – was die Entropie verringert.Hoppla!

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

Es gibt eine längere Diskussion über die Passwort-Entropie Krypto-StackExchange Website.Auch eine gute Google-Suche liefert viele Ergebnisse.

In den Kommentaren habe ich mit @popnoodles gesprochen, der darauf hingewiesen hat Strikt Eine Passwortrichtlinie der Länge X mit vielen Buchstaben, Zahlen, Symbolen usw. kann tatsächlich die Entropie reduzieren, indem sie das Passwortschema vorhersehbarer macht.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 die Erstellung des besten Passworts der Welt ein Haken.Entweder ist es nicht einprägsam, zu vorhersehbar, zu kurz, zu viele Unicode-Zeichen (auf einem Windows-/Mobilgerät schwer einzugeben), zu lang usw.Für unsere Zwecke ist kein Passwort wirklich gut genug, deshalb müssen wir sie schützen, als wären sie in Fort Knox.

Empfohlene Vorgehensweise

Bcrypt und verschlüsseln sind die aktuellen Best Practices. Verschlüsseln wird mit der Zeit besser sein als bcrypt, wurde aber weder von Linux/Unix noch von Webservern als Standard übernommen und es wurden noch keine ausführlichen Rezensionen zu seinem Algorithmus veröffentlicht.Dennoch sieht die Zukunft des Algorithmus vielversprechend aus.Wenn Sie mit Ruby arbeiten, gibt es eine Verschlüsselungsjuwel Das wird Ihnen weiterhelfen, und Node.js hat jetzt ein eigenes verschlüsseln Paket.Sie können Scrypt in PHP entweder über verwenden Verschlüsseln Erweiterung oder die Libsodium Erweiterung (beide sind in PECL verfügbar).

Ich empfehle dringend, die Dokumentation zu lesen Krypta-Funktion Wenn Sie verstehen möchten, wie man bcrypt verwendet, oder sich selbst eine finden möchten Gut Verpackung oder verwenden Sie so etwas wie PHPASS für eine ältere Implementierung.Ich empfehle mindestens 12 Runden bcrypt, wenn nicht 15 bis 18.

Ich änderte meine Meinung über die Verwendung von bcrypt, als ich erfuhr, dass bcrypt nur den Schlüsselplan von Blowfish mit einem variablen Kostenmechanismus verwendet.Letzteres ermöglicht es Ihnen, die Kosten für die Brute-Force-Ermittlung eines Passworts zu erhöhen, indem Sie den ohnehin schon teuren Schlüsselplan von Blowfish erweitern.

Durchschnittliche Praktiken

Ich kann mir diese Situation fast nicht mehr vorstellen. PHPASS unterstützt PHP 3.0.18 bis 5.3, sodass es auf fast jeder erdenklichen Installation verwendet werden kann – und sollte verwendet werden, wenn dies nicht der Fall ist weiß es genau dass Ihre Umgebung bcrypt unterstützt.

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

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

Zukünftige Praktiken

Mit PHP 5.5 kommt ein Vollständige Passwortschutzbibliothek Das erspart Ihnen den Aufwand bei der Arbeit mit bcrypt.Während die meisten von uns in den meisten gängigen Umgebungen, insbesondere auf gemeinsam genutzten Hosts, mit PHP 5.2 und 5.3 feststecken, hat @ircmaxell eine entwickelt Kompatibilitätsschicht für die kommende API, die abwärtskompatibel zu PHP 5.3.7 ist.

Zusammenfassung und Haftungsausschluss zur Kryptographie

Die dafür erforderliche Rechenleistung ist tatsächlich erforderlich Riss Es existiert kein gehashtes Passwort.Die einzige Möglichkeit für Computer, ein Passwort zu „knacken“, besteht darin, es neu zu erstellen und den Hashing-Algorithmus zu simulieren, der zu seiner Sicherung verwendet wird.Die Geschwindigkeit des Hashs hängt linear von seiner Fähigkeit ab, brutal erzwungen zu werden.Schlimmer noch: Die meisten Hash-Algorithmen können leicht parallelisiert werden, um noch schneller zu arbeiten.Aus diesem Grund sind kostspielige Systeme wie bcrypt und scrypt so wichtig.

Sie können unmöglich alle Bedrohungen oder Angriffswege vorhersehen und müssen daher Ihr Bestes tun, um Ihre Benutzer zu schützen vorne.Wenn Sie dies nicht tun, übersehen Sie möglicherweise sogar die Tatsache, dass Sie angegriffen wurden, bis es zu spät ist ... und du bist haftbar.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.

Zuletzt:Ich bin kein Kryptograf.Was auch immer ich gesagt habe, ist meine Meinung, aber ich denke zufällig, dass sie auf dem guten alten gesunden Menschenverstand basiert ...und viel Lektüre.Denken Sie daran, so paranoid wie möglich zu sein, das Eindringen in die Dinge so schwer wie möglich zu machen, und wenn Sie dann immer noch besorgt sind, wenden Sie sich an einen White-Hat-Hacker oder Kryptographen, um zu erfahren, was er über Ihren Code/Ihr System sagt.

Andere Tipps

Eine viel kürzere und sicherere Antwort - Schreiben Sie überhaupt nicht Ihren eigenen Passwortmechanismus, Verwenden Sie einen bewährten Mechanismus.

  • Php 5.5 oder höher: password_hash () ist gute Qualität und Teil des PHP -Kerns.
  • Ältere PHP -Versionen: OpenWall's Phass Die Bibliothek ist viel besser als die meisten benutzerdefinierten Code - verwendet in WordPress, Drupal usw.

Die meisten Programmierer haben einfach nicht das Know -how, um kryptobezogene Code sicher zu schreiben, ohne Schwachstellen einzuführen.

Schneller Selbsttest: Was ist das Passwortdehnen und wie viele Iterationen sollten Sie verwenden? Wenn Sie die Antwort nicht kennen, sollten Sie verwenden password_hash(), da die Kennwortstreckung jetzt eine kritische Funktion von Kennwortmechanismen aufgrund viel schnellerer CPUs und der Verwendung von ist GPUs und FPGAs Passwörter mit Raten von zu knacken Milliarden von Vermutungen pro Sekunde (mit GPUs).

Zum Beispiel können Sie Knacken Sie alle 8-Charakter-Windows-Passwörter in 6 Stunden mit 25 gpus in 5 Desktop -PCs installiert. Dies ist Brute-Forcing-IE-Aufzählung und Überprüfung Alle 8-Charakter-Windows-Passwort Passwort, einschließlich Sonderfiguren, und ist kein Wörterbuchangriff. Das war 2012, dass Sie ab 2018 weniger GPUs verwenden oder mit 25 GPUs schneller knacken können.

Es gibt auch viele Regenbogentischangriffe auf Windows -Passwörter, die auf normalem CPUs ausgeführt werden und sehr schnell sind. All dies liegt daran, dass Windows still Salzt oder dehnt nicht seine Passwörter, Sogar in Windows 10 - Machen Sie nicht den gleichen Fehler wie Microsoft!

Siehe auch:

  • Ausgezeichnete Antwort mit mehr darüber warum password_hash() oder phpass sind der beste Weg zu gehen.
  • Guter Blog -Artikel Empfehlung "Arbeitsfaktoren" (Anzahl der Iterationen) für Hauptalgorithmen, einschließlich Bcrypt, Scrypt und PBKDF2.

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

Ab PHP 5.5 verfügt PHP über einfache, sichere Funktionen für Hashing und Überprüfung 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

Wann password_hash() Wird verwendet, erzeugt ein zufälliges Salz und enthält es in den ausgegebenen Hash (zusammen mit den verwendeten Kosten und Algorithmus). password_verify() Anschließend liest und bestimmt die verwendete Salz- und Verschlüsselungsmethode und überprüft es mit dem bereitgestellten Klartextkennwort.

Bereitstellung der PASSWORD_DEFAULT Weisen Sie PHP an, den Standard -Hashing -Algorithmus der installierten Version von PHP zu verwenden. Genau welcher Algorithmus das bedeutet, dass sich in zukünftigen Versionen im Laufe der Zeit ändern soll, damit er immer einer der stärksten verfügbaren Algorithmen ist.

Die Erhöhung der Kosten (die standardmäßig auf 10) sind, erschwert den Hash, der die Brute-Force-Force hat, aber auch bedeutet, Hashes zu generieren und Passwörter gegen sie zu überprüfen, ist mehr Arbeit für die CPU Ihres Servers.

Beachten Sie, dass sich der Standard -Hashing -Algorithmus, obwohl sich der Standard -Hashing -Algorithmus ändern kann, alte Hashes weiterhin gut überprüft, da der verwendete Algorithmus im Hash und im Hash und im Hash und im Bereich gespeichert ist password_verify() nimmt es auf.

Obwohl die Frage beantwortet wurde, möchte ich nur wiederholen, dass Salze, die für Hashing verwendet werden, zufällig sein sollten und nicht wie E -Mail -Adresse, wie in der ersten Antwort vorgeschlagen.

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

Vor kurzem hatte ich eine Diskussion, ob Passwort -Hashes mit zufälligen Bits sicherer sind als die, die mit erratenen oder bekannten Salzen gesalzen ist. Mal sehen: Wenn das System des Systems, das das Kennwort speichert, ebenso wie das System, das das zufällige Salz speichert, beeinträchtigt wird, hat der Angreifer sowohl Zugriff auf Hash als auch Salz. Ob das Salz zufällig ist oder nicht, spielt keine Rolle. Der Angreifer kann vorbereitete Regenbogentische erzeugen, um den Hash zu knacken. Hier kommt der interessante Teil- es ist nicht so trivial, vorbereitete Tabellen zu erzeugen. Nehmen wir ein Beispiel für das WPA -Sicherheitsmodell. Ihr WPA -Passwort wird tatsächlich nie an Wireless Access Point gesendet. Stattdessen ist es mit Ihrem SSID (dem Netzwerknamen wie Linksys, Dlink usw.) gehasht. Eine sehr gute Erklärung, wie dies funktioniert, ist hier. Um das Passwort von Hash abzurufen, müssen Sie das Kennwort sowie Salz (Netzwerkname) kennen. Church of WiFi hat bereits vorbereitete Hash-Tabellen mit Top 1000 SSIDs und etwa 1 Millionen Passwörtern. Die Größe von allen Tischen beträgt ca. 40 GB. Wie Sie auf seiner Website lesen können, hat jemand 15 FGPA -Arrays für 3 Tage verwendet, um diese Tabellen zu generieren. Angenommen, das Opfer verwendet die SSID als „A387CSF3“ und Passwort als „123456“, wird es durch diese Tabellen geknackt? Nein! .. es kann nicht. Auch wenn das Passwort schwach ist, haben die Tabellen kein Hashes für SSID A387CSF3. Dies ist die Schönheit, zufälliges Salz zu haben. Es wird Cracker abschrecken, die auf vorbereiteten Tischen gedeihen. Kann es einen entschlossenen Hacker aufhalten? Wahrscheinlich nicht. Die Verwendung von zufälligen Salzen liefert jedoch eine zusätzliche Verteidigungsschicht. Während wir uns mit diesem Thema befassen, diskutieren wir zusätzlichen Vorteil, dass Sie zufällige Salze auf einem separaten System gespeichert werden. Szenario Nr. 1: Passwort -Hashes werden auf System X gespeichert und Salzwerte, die für Hashing verwendet werden, werden auf System Y gespeichert. Diese Salzwerte sind erraten oder bekannt (z. Hashing werden auf System Y gespeichert. Diese Salzwerte sind zufällig. Falls System X kompromittiert wurde, gibt es, wie Sie vermuten können, einen großen Vorteil, dass ein zufälliges Salz in einem separaten System verwendet wird (Szenario Nr. 2). Der Angreifer muss zusätzliche Werte erraten, um Hashes knacken zu können. Wenn ein 32 -Bit -Salz verwendet wird, können 2^32 = 4,294.967.296 (ca. 4,2 Milliarden) Iterationen für jedes geschätzte Passwort erforderlich sein.

Ich möchte nur darauf hinweisen, dass PHP 5.5 a enthält Passwort Hashing -API Das liefert eine Wrapper herum crypt(). Diese API vereinfacht die Aufgabe, Passwort -Hashes zu vermitteln, zu überprüfen und zu räumen. Der Autor hat auch a veröffentlicht Kompatibilitätspaket (In Form einer einzelnen password.php -Datei, die Sie einfach require zu verwenden) für diejenigen, die PHP 5.3.7 und später verwenden und dies jetzt verwenden möchten.

Es unterstützt BCrypt nur vorerst, zielt jedoch leicht zu erweitern, um andere Hashing -Techniken für Passwort einzubeziehen. Da die Technik und die Kosten im Rahmen des Hashs gespeichert werden, werden Änderungen an Ihrer bevorzugten Hashing -Technik/-kosten nicht ungültig werden, um aktuelle Hashes zu erhalten, den Framework, der Framework werden nicht ungültig machen Verwendet automatisch die richtige Technik/Kosten beim Validieren. Es behandelt auch ein "sicheres" Salz, wenn Sie Ihre eigenen nicht explizit definieren.

Die API enthüllt vier Funktionen:

  • password_get_info() - Gibt Informationen über den angegebenen Hash zurück
  • password_hash() - Erstellt ein Passwort -Hash
  • password_needs_rehash() - Überprüft, ob der angegebene Hash mit den angegebenen Optionen übereinstimmt. Nützlich, um zu überprüfen, ob der Hash an Ihr aktuelles Technik-/Kostenschema entspricht, sodass Sie bei Bedarf wieder aufgerufen werden können
  • password_verify() - Überprüft, ob ein Passwort einem Hash entspricht

Im Moment akzeptieren diese Funktionen die Kennwortkonstanten von Password_Bcrypt und Password_Default, die momentan synonym sind. Der Unterschied besteht darin, dass Password_Default "in neueren PHP -Releases ändert, wenn neuere, stärkere Hashing -Algorithmen unterstützt werden." Verwenden von password_default und password_needs_rehash () beim Login (und bei Bedarf) sollte sicherstellen, dass Ihre Hashes angemessen gegen brutaler Angriffe mit wenig bis gar keinem Arbeitsplatz für Sie sind.

Bearbeiten: Ich habe gerade festgestellt, dass dies in Robert Ks Antwort kurz erwähnt wird. Ich werde diese Antwort hier hinterlassen, da ich denke, dass sie ein bisschen mehr Informationen darüber liefert, wie sie funktioniert, und die Benutzerfreundlichkeit für diejenigen, die die Sicherheit nicht kennen.

Ich benutze Phass Dies ist eine einfache PHP-Klasse mit einer Datei, die in nahezu jedem PHP-Projekt sehr leicht implementiert werden könnte. Siehe auch Das h.

Standardmäßig wurde die stärkste verfügbare Verschlüsselung verwendet, die in Phass implementiert ist, nämlich bcrypt und fällt auf andere Verschlüsse bis MD5 zurück, um Frameworks wie WordPress rückwärtskompatibilität zu bieten.

Der zurückgegebene Hash könnte in der Datenbank so gespeichert werden, wie sie ist. Die Verwendung von Hashs für die Probe 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, an die man sich erinnern sollte

Es wurde viel über die Passwortverschlüsselung für PHP gesagt. Die meisten davon sind sehr gute Ratschläge. Bevor Sie jedoch überhaupt mit dem Prozess der Verwendung von PHP für die Kennwortverschlüsselung beginnen, stellen Sie sicher, dass Sie die folgenden oder bereit für die Implementierung bereitgestellt haben.

SERVER

HÄFEN

Egal wie gut Ihre Verschlüsselung ist, wenn Sie den Server, der den PHP und DB ausführt, nicht ordnungsgemäß sichern, alle Ihre Bemühungen sind wertlos. Die meisten Server funktionieren relativ auf die gleiche Weise, sie haben Ports zugewiesen, damit Sie über FTP oder Shell aus der Ferne auf sie zugreifen können. Stellen Sie sicher, dass Sie den Standard -Port ändern, deren Remoteverbindung Sie aktiv haben. Wenn Sie dies nicht tun, haben Sie den Angreifer dazu gebracht, auf Ihr System zuzugreifen.

NUTZERNAME

Für alles, was in der Welt gut ist, verwenden Sie den Benutzernamen -Administrator nicht, root oder ähnliches. Auch wenn Sie sich in einem Unix -basierten System befinden, machen Sie das Stammkonto nicht zugänglich, sondern sollte immer nur sudo sein.

PASSWORT

Sie fordern Ihren Benutzern an, gute Passwörter zu erstellen, um zu vermeiden, dass sie gehackt werden, dasselbe tun. Was macht es, alle Anstrengungen zu durchlaufen, um Ihre Haustür zu sperren, wenn Sie die Hintertür weit geöffnet haben?

DATENBANK

SERVER

Idealerweise möchten Sie Ihre DB und Anwendung auf separaten Servern. Dies ist aufgrund von Kosten nicht immer möglich, ermöglicht jedoch eine gewisse Sicherheit, da der Angreifer zwei Schritte durchlaufen muss, um vollständig auf das System zuzugreifen.

BENUTZER

Lassen Sie Ihre Bewerbung immer ein eigenes Konto haben, um auf die DB zuzugreifen, und geben Sie ihm nur die Berechtigungen, die sie benötigen.

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

Machen Sie diese Wurzel oder ähnliches nicht.

PASSWORT

Befolgen Sie die gleichen Richtlinien wie bei allen guten Passwörtern. Verwenden Sie auch nicht das gleiche Passwort auf Server- oder DB -Konten auf demselben System.

Php

PASSWORT

Speichern Sie niemals ein Passwort in Ihrem DB, speichern Sie stattdessen den Hash und das einzigartige Salz, ich werde später erklären, warum.

Hashing

One Way Hashing !!!!!!!, nie ein Passwort auf eine Weise, die es umgekehrt werden kann. genauso und vergleichen Sie die beiden Hashes. Dies bedeutet, dass ein Angreifer selbst, wenn er Zugang zum DB erhält, nicht weiß, was das tatsächlich Passwort ist, nur sein resultierender Hash. Dies bedeutet mehr Sicherheit für Ihre Benutzer im schlechtesten Szenario.

Es gibt viele gute Hashing -Funktionen da draußen (password_hash, hash, usw.), aber Sie müssen einen guten Algorithmus auswählen, damit der Hash effektiv ist. (Bcrypt und ähnliche ähnliche sind anständige Algorithmen.)

Wenn Hashing -Geschwindigkeit der Schlüssel ist, desto langsamer gegen Brute -Force -Angriffe.

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

Salzen

Passwörter sollten immer vor dem Hashed gesalzen werden. Salben fügt dem Passwort eine zufällige Zeichenfolge hinzu, sodass ähnliche Passwörter im DB nicht gleich angezeigt werden. Wenn das Salz jedoch für jeden Benutzer nicht nur eindeutig ist (dh: Sie verwenden ein hart codiertes Salz), haben Sie Ihr Salz so ziemlich wertlos gemacht. Denn einmal hat ein Angreifer ein Passwort Salz aus dem Salz für alle.

Wenn Sie ein Salz erstellen, stellen Sie sicher, dass es für das Passwort einzigartig ist, das es salzt, und speichern Sie sowohl den vollständigen Hash als auch das Salz in Ihrem DB. Dies wird es so machen, dass ein Angreifer jedes Salz und jedes Hash einzeln knacken muss, bevor er Zugang erhalten kann. Dies bedeutet für den Angreifer viel mehr Arbeit und Zeit.

Benutzer erstellen Passwörter

Wenn der Benutzer ein Passwort über das Frontend erstellt, bedeutet dies, dass er an den Server gesendet werden muss. Dies öffnet ein Sicherheitsproblem, da dies bedeutet, dass das unverschlüsselte Passwort an den Server gesendet wird und ein Angreifer in der Lage ist, zuhören und zugreifen kann, dass Ihre gesamte Sicherheit in PHP wertlos ist. Übertragen Sie die Daten immer sicher, dies geschieht über SSL.

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

Unabhängig von den Sicherheitsmaßnahmen, die Sie nicht ergreifen, ist die fortgeschrittenere Technologie zum Schutz umso fortgeschrittener, desto fortgeschrittener werden die Angriffe. Wenn Sie diese Schritte jedoch befolgen, wird Ihre Website jedoch sicherer und weniger wünschenswerter für Angreifer.

Hier ist eine PHP -Klasse, die leicht einen Hash und Salz für ein Passwort erstellt

http://git.io/msjqpw

Laut Google ist SHA256 PHP zur Verfügung.

Sie sollten auf jeden Fall ein Salz verwenden. Ich würde empfehlen, zufällige Bytes zu verwenden (und sich nicht auf Zeichen und Zahlen beschränken). Je länger Sie sich entscheiden, desto sicherer und langsamer wird es. 64 Bytes sollten in Ordnung sein, denke ich.

Ich fand hier ein perfektes Thema in dieser Angelegenheit: https://crackstation.net/hashing-security.htm, Ich wollte, dass Sie davon profitieren. Hier ist auch der Quellcode, der auch gegen zeitbasierten Angriffe vorbeugt.

<?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));
}
?>

Letztendlich bietet doppelhäsere mathematisch keinen Nutzen. In der Praxis ist es jedoch nützlich, um Angriffe auf Regenbogen-Tischbasis zu verhindern. Mit anderen Worten, es ist kein Nutzen als Hashing mit einem Salz, das in Ihrer Anwendung oder auf Ihrem Server weitaus weniger Zeit in Anspruch nimmt.

Normalerweise verwende ich SHA1 und Salz mit der Benutzer-ID (oder einem anderen benutzerspezifischen Informationen) und manchmal verwende ich zusätzlich ein konstantes Salz (also habe ich 2 Teile am Salz).

SHA1 wird jetzt auch als etwas beeinträchtigt, aber in weitaus geringerem Maße als MD5 angesehen. Durch die Verwendung eines Salzes (jedes Salz) verhindern Sie die Verwendung eines Generikums Regenbogentisch um Ihren Hashes anzugreifen (einige Leute hatten sogar Erfolg mit Google als eine Art Regenbogentisch, indem sie nach dem Hash suchen). Ein Angreifer könnte möglicherweise einen Regenbogentisch mit Ihrem Salz erzeugen. Aus diesem Grund sollten Sie ein benutzerspezifisches Salz einbeziehen. Auf diese Weise müssen sie für jeden Datensatz in Ihrem System einen Regenbogentisch erzeugen, nicht nur für Ihr gesamtes System! Bei dieser Art des Salzens ist sogar MD5 anständig sicher.

SHA1 und ein Salz sollte ausreichen (je nachdem, ob Sie etwas für kodieren für Fort Knox oder ein Login -System für Ihre Einkaufsliste) auf absehbare Zeit. Wenn SHA1 nicht gut genug für Sie 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 gut genug ein Gedächtnis diesen Hash sehen und weiß, dass es der Hash einer leeren Saite ist. Aber wenn die Saite gesalzen ist (z. B. mit der Zeichenfolge "MY_PERSONAL_SALT"), der Hash für die 'leere Zeichenfolge' (dh"MY_PERSONAL_SALT") wird aeac2612626724592271634fb14d3ea6, daher nicht offensichtlich für Backtrace. Was ich versuche zu sagen, dass es besser ist, es zu benutzen irgendein Salz, als nicht. Daher ist es nicht allzu sehr wichtig, es zu wissen die Salz zu verwenden.

Es gibt eigentlich Websites, die genau das tun - Sie können es einen (MD5) Hash füttern und es spuckt einen bekannten Klartext aus, der diesen bestimmten Hash generiert. Wenn Sie Zugriff auf eine Datenbank erhalten, die einfache MD5-Hashes speichert, ist es für Sie trivial, den Hash für den Administrator in einen solchen Dienst einzugeben und sich anzumelden. Wenn die Kennwörter gesalzen würden, würde ein solcher Dienst werden unwirksam.

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

Ok im fitsy wir brauchen Salzsalz muss einzigartig sein, also lassen Sie es generieren

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

Außerdem brauchen wir den Hash, den ich sha512 benutze, 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 in der Datenbank unseren variablen Wert $ Hash_psw und $ salz Variable sparen

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

Dies ist der beste Weg, um unsere Kunden Passwörter zu sichern ...

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

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top