Frage Sichere Hash und Salz für PHP Passwörter


Es wird derzeit gesagt, dass MD5 teilweise unsicher ist. Wenn ich das in Betracht ziehe, würde ich gerne wissen, welcher Mechanismus für den Passwortschutz verwendet werden soll.

Diese Frage, Ist das "doppelte Hashing" eines Passworts weniger sicher als nur einmal zu hashen?  schlägt vor, dass das mehrfache Hashing eine gute Idee sein kann Wie implementiere ich einen Passwortschutz für einzelne Dateien? schlägt vor, Salz zu verwenden.

Ich benutze PHP. Ich möchte ein sicheres und schnelles Passwort-Verschlüsselungssystem. Ein Passwort millionenfach zu hacken ist zwar sicherer, aber auch langsamer. Wie erreiche ich ein gutes Gleichgewicht zwischen Geschwindigkeit und Sicherheit? Außerdem würde ich bevorzugen, 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 verwenden (in diesem Fall sind alle Salze gleich gut? Gibt es eine Möglichkeit, gute Salze zu erzeugen?)

Sollte ich zwei Felder in der Datenbank speichern (eines mit MD5 und eines mit SHA)? Wäre es sicherer oder unersättlicher?

Falls ich nicht klar genug war, möchte ich wissen, welche Hashfunktion (en) zu verwenden sind und wie man ein gutes Salz auswählt, um einen sicheren und schnellen Passwortschutzmechanismus zu erhalten.

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, Passwörter für asp.net
Wie würden Sie in Tomcat 5.5 gesalzene Passwörter implementieren?


1049
2017-12-30 22:02


Ursprung


Antworten:


HAFTUNGSAUSSCHLUSS: Diese Antwort wurde 2008 geschrieben.

Seitdem hat PHP uns gegeben password_hash und password_verify und seit ihrer Einführung sind sie die empfohlene Hashing- und Prüfmethode für Kennwörter.

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

TL; DR

Don'ts

  • Beschränken Sie nicht, welche Zeichen Benutzer für Kennwörter eingeben können. Nur Idioten machen das.
  • Beschränken Sie nicht die Länge eines Passwortes. Wenn Ihre Benutzer einen Satz mit supercalifragilisticexpialidocious darin wollen, verhindern Sie nicht, dass sie ihn benutzen.
  • Speichern Sie niemals das Passwort Ihres Benutzers im Klartext.
  • Senden Sie niemals ein Passwort an Ihren Benutzer außer wenn sie ihre verloren haben, und Sie haben eine vorübergehende geschickt.
  • Passwörter niemals auf irgendeine Weise auf.
  • Hash-Passwörter niemals mit SHA1 oder MD5 oder sogar SHA256! Moderne Cracker kann 60 bzw. 180 Milliarden Hashes / Sekunde überschreiten.
  • Nicht mischen bcrypt und mit der roh Ausgabe von Hash ()Verwenden Sie entweder hex output oder base64_encode it. (Dies gilt für alle Eingaben, die möglicherweise einen Rogue enthalten \0 darin, was 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 kompromittiert ist.
  • Implementieren Sie eine angemessene Mindestlänge von 8-10 Zeichen plus mindestens 1 Großbuchstaben, 1 Kleinbuchstaben, eine Zahl und ein Symbol. Dies verbessert die Entropie des Passworts und macht es dadurch schwieriger zu knacken. (Siehe Abschnitt "Was macht ein gutes Passwort?" Für einige Diskussionen.)

Warum Hash-Passwörter sowieso?

Das Ziel hinter Hash-Passwörtern ist einfach: Verhindern bösartigen Zugriffs auf Benutzerkonten durch Kompromittierung der Datenbank. Das Ziel von Password Hashing ist also, einen Hacker oder Cracker davon abzuhalten, zu viel Zeit oder Geld zu investieren, um die Klartextpasswörter zu berechnen. Und Zeit / Kosten sind die beste Abschreckung in Ihrem Arsenal.

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

Jeremiah Grossman, CTO von Whitehat Security, sagte auf seinem Blog nach einer kürzlich erfolgten Passwortwiederherstellung, bei der der Passwortschutz brute-force gebrochen wurde:

Interessanterweise habe ich, als ich diesen Albtraum erlebte, gelernt, dass ich nichts über Passwort-Cracking, Speicher und Komplexität wusste. Ich habe erkannt, warum die Speicherung von Passwörtern wichtiger ist als die Komplexität von Passwörtern. Wenn Sie nicht wissen, wie Ihr Passwort gespeichert ist, können Sie sich nur auf Komplexität verlassen. Dies ist zwar für Kennwörter und Krypto-Profis allgemein bekannt, aber für den durchschnittlichen InfoSec- oder Web-Security-Experten bezweifle ich es sehr.

(Hervorhebung von mir.)

Was macht a gut Passwort sowieso?

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

Kurz gesagt, Entropie ist, wie viel Variation innerhalb des Passworts ist. Wenn ein Passwort nur aus kleinen Buchstaben besteht, sind das nur 26 Zeichen. Das ist nicht viel Variation. Alphanumerische Passwörter sind besser, mit 36 ​​Zeichen. Aber Groß- und Kleinschreibung mit Symbolen ist etwa 96 Zeichen lang. Das ist viel besser als nur Buchstaben. Ein Problem besteht darin, dass wir Muster einfügen, um unsere Passwörter unvergesslich zu machen - was die Entropie reduziert. Hoppla!

Passwort Entropie ist approximiert leicht. Die Verwendung des vollen Bereichs von ASCII-Zeichen (etwa 96 typisierbare Zeichen) ergibt eine Entropie von 6,6 pro Zeichen, die für ein Passwort nach 8 Zeichen 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 wirklich die Entropie eines Passworts und machen es schwieriger zu knacken.

Es gibt eine längere Diskussion der Passwort Entropie auf der CryptoStackExchange Seite? ˅. Eine gute Google-Suche wird auch viele Ergebnisse ergeben.

In den Kommentaren habe ich mit @popnoodles gesprochen, die darauf hingewiesen haben Durchsetzung Eine Passwortrichtlinie mit X-Länge mit X vielen Buchstaben, Zahlen, Symbolen usw. kann die Entropie tatsächlich reduzieren, indem das Passwortschema berechenbarer wird. Ich stimme zu. Randomess, so zufällig wie möglich, ist immer die sicherste, aber am wenigsten denkwürdige Lösung.

So weit ich sagen konnte, ist das Catch-22 das weltweit beste Passwort. Entweder es ist nicht einprägsam, zu vorhersehbar, zu kurz, zu viele Unicode-Zeichen (schwer auf einem Windows / Mobile-Gerät eingeben), zu lang, etc. Kein Passwort ist wirklich gut genug für unsere Zwecke, also müssen wir sie schützen, als ob sie waren in Fort Knox.

Best Practices

Bcrypt und scrypt sind die aktuellen Best Practices. Scrypt ist besser als bcrypt in der Zeit, aber es hat die Einführung als Standard von Linux / Unix oder von Webservern noch nicht gesehen, und hat seinen Algorithmus noch nicht gründlich überprüft. Dennoch sieht die Zukunft des Algorithmus vielversprechend aus. Wenn Sie mit Ruby arbeiten, gibt es ein scrypt gem das wird dir helfen, und Node.js hat jetzt seine eigene scrypt Paket. Sie können Scrypt in PHP entweder über die Scrypt Verlängerung oder die Libsodium Erweiterung (beide sind in PECL verfügbar).

Ich schlage vor, die Dokumentation für die Verschlüsselungsfunktion Wenn Sie wissen möchten, wie Sie bcrypt verwenden oder sich selbst finden gut  Verpackung oder benutze sowas 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. Mit letzterem können Sie die Kosten erhöhen, um ein Passwort zu erzwingen, indem Sie den bereits teuren Schlüsselplan von blowfish erhöhen.

Durchschnittliche Praxis

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 denkbaren Installation verwendet werden kann - und sollte verwendet werden, wenn Sie dies nicht tun sicher wissen 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 dem maximale Anzahl von Runden dass Ihre Umgebung / Anwendung / Benutzerwahrnehmung tolerieren kann. Die niedrigste Zahl, die ich empfehlen würde, ist 2500 Runden. Stellen Sie auch sicher, zu verwenden hash_hmac () wenn es verfügbar ist, um die Operation schwieriger zu reproduzieren.

Zukunftspraktiken

In PHP 5.5 kommt ein vollständige Passwortschutzbibliothek das abstrahiert jegliche Mühe, mit bcrypt zu arbeiten. Während die meisten von uns mit PHP 5.2 und 5.3 in den meisten gängigen Umgebungen, vor allem Shared Hosts, beschäftigt sind, hat @ircmaxell eine Kompatibilitätsebene für die kommende API, die abwärtskompatibel zu PHP 5.3.7 ist.

Kryptographie-Zusammenfassung und Haftungsausschluss

Die erforderliche Rechenleistung, um tatsächlich Riss Ein Hash-Passwort existiert nicht. Die einzige Möglichkeit für Computer, ein Kennwort zu knacken, besteht darin, es neu zu erstellen und den Hash-Algorithmus zu simulieren, mit dem es gesichert wird. Die Geschwindigkeit des Hashes hängt linear mit seiner Fähigkeit zusammen, brutal zu sein. Schlimmer noch, die meisten Hash-Algorithmen können leicht parallelisiert werden, um noch schneller zu arbeiten. Deshalb sind kostspielige Systeme wie bcrypt und scrypt so wichtig.

Sie können möglicherweise nicht alle Bedrohungen oder Angriffsmöglichkeiten vorhersehen, und Sie müssen sich daher nach besten Kräften bemühen, Ihre Benutzer zu schützen vorne. Wenn Sie das nicht tun, verpassen Sie vielleicht 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 oder die Konten anderer Benutzer zu ändern oder auf deren Daten zuzugreifen. Wenn Sie die Sicherheit Ihres Systems nicht testen, können Sie niemanden beschuldigen außer sich selbst.

Zu guter Letzt: Ich bin kein Kryptograph. Was auch immer ich gesagt habe, ist meine Meinung, aber ich glaube, dass es auf gutem gesunden Menschenverstand basiert ... und viel Lesen. Denken Sie daran, seien Sie so paranoid wie möglich, machen Sie es so schwer wie möglich zu stören, und kontaktieren Sie dann, wenn Sie sich Sorgen machen, einen White-Hat-Hacker oder Kryptograph, um zu sehen, was sie über Ihren Code / Ihr System sagen.


892
2017-12-30 22:15



Eine viel kürzere und sicherere Antwort - Schreibe keinen 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: OpenWalls phpass Bibliothek ist viel besser als die meisten benutzerdefinierten Code - in WordPress, Drupal usw. verwendet

Die meisten Programmierer haben einfach nicht die Erfahrung, kryptografischen Code sicher zu schreiben, ohne Sicherheitslücken einzugehen.

Schneller Selbsttest: Was ist Passwort-Stretching und wie viele Iterationen sollten Sie verwenden? Wenn Sie die Antwort nicht kennen, sollten Sie verwenden password_hash(), da das Passwortstrecken aufgrund der wesentlich schnelleren CPUs und der Verwendung von GPUs und FPGAs Passwörter zu Rate von knacken Milliarden von Raten pro Sekunde (mit GPUs).

Zum Beispiel können Sie knacken Sie alle 8-stelligen Windows-Passwörter in 6 Stunden Verwendung von 25 GPUs, die auf 5 Desktop-PCs installiert sind. Dies ist Brute-Forcing, d.h. Aufzählen und Prüfen jedes Windows-Passwort mit 8 Zeicheneinschließlich Sonderzeichen, und ist kein Wörterbuchangriff. Das war 2012, ab 2018 könnten Sie weniger GPUs verwenden oder mit 25 GPUs schneller knacken.

Es gibt auch viele Rainbow-Table-Angriffe auf Windows-Passwörter, die auf gewöhnlichen CPUs laufen und sehr schnell sind. All das ist, weil Windows immer noch  nicht salzen oder dehnen seine Passwörter, sogar in Windows 10 - Machen Sie nicht den gleichen Fehler wie Microsoft!

Siehe auch: 

  • ausgezeichnete Antwort mit mehr über warum password_hash() oder phpass sind der beste Weg zu gehen.
  • guter Blogartikel geben empfohlene "Arbeitsfaktoren" (Anzahl der Iterationen) für Hauptalgorithmen einschließlich bcrypt, scrypt und PBKDF2.

120
2017-11-08 12:02



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


40
2017-12-30 22:18



Obwohl die Frage beantwortet wurde, möchte ich nur wiederholen, dass die für das Hashing verwendeten Salze zufällig und nicht wie die in der ersten Antwort vorgeschlagene E-Mail-Adresse sein 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, ob Password-Hashes zufällig gesalzen werden   Bits sind sicherer als der, der mit Erratenen oder Bekannten gesalzen wird   Salze. Mal sehen: Wenn das Passwort speichernde System als gefährdet gilt   Sowie das System, das das zufällige Salz speichert, wird der Angreifer   haben Zugriff auf Hash sowie Salz, also ob das Salz zufällig ist oder   nicht, ist egal. Der Angreifer kann vorberechnete generieren   Regenbogen-Tabellen, um den Hash zu knacken. Hier kommt der interessante Teil dazu   ist nicht so trivial, vorberechnete Tabellen zu generieren. Nehmen wir ein Beispiel   des WPA-Sicherheitsmodells. Ihr WPA-Passwort wird tatsächlich nie gesendet   WLAN-Zugangspunkt. Stattdessen wird es mit Ihrer SSID (dem   Netzwerkname - wie Linksys, Dlink usw.). Eine sehr gute Erklärung wie   Das funktioniert hier. Um das Passwort aus dem Hash zu holen, werden Sie   müssen das Passwort sowie Salz (Netzwerkname) wissen. Kirche von   Wifi hat bereits Hash-Tabellen vorberechnet, die die Top 1000 SSIDs und hat   ungefähr 1 Million Passwörter. Die Größe aller Tabellen beträgt ca. 40 GB.   Wie Sie auf ihrer Website lesen können, hat jemand 15 FGPA Arrays für 3 Tage benutzt   um diese Tabellen zu generieren. Angenommen, das Opfer verwendet die SSID als   "A387csf3" und Passwort als "123456", wird es von diesen geknackt werden   Tabellen? Nein! .. es kann nicht. Auch wenn das Passwort schwach ist, die Tabellen   Keine Hashes für SSID a387csf3. Das ist die Schönheit des Habens   zufälliges Salz. Es wird Cracker, die auf Vorberechnung gedeihen   Tabellen. Kann es einen entschlossenen Hacker aufhalten? Wahrscheinlich nicht. Aber benutzen   Random-Salze bieten eine zusätzliche Verteidigungsschicht. Während wir sind   In diesem Thema wollen wir den zusätzlichen Vorteil der zufälligen Speicherung diskutieren   Salze auf einem separaten System. Szenario 1: Passwort-Hashes werden gespeichert   auf System X und Salzwerte, die zum Hashing verwendet werden, werden auf System Y gespeichert.   Diese Salzwerte sind erraten oder bekannt (z. B. Benutzername) Szenario # 2:   Passwort-Hashes werden auf System X gespeichert und Salzwerte für verwendet   Hashing wird auf System Y gespeichert. Diese Salzwerte sind zufällig. Im Fall   System X wurde kompromittiert, wie Sie sich vorstellen können, gibt es eine große   Vorteil der Verwendung von Zufallssalz auf einem separaten System (Szenario # 2).   Der Angreifer muss zusätzliche Werte erraten, um knacken zu können   Hashes. Wenn ein 32-Bit-Salz verwendet wird, 2 ^ 32 = 4,294,967,296 (etwa 4,2   Milliarden) Iterationen können für jedes Passwort erforderlich sein.


30
2018-02-12 00:52



Ab PHP 5.5 bietet PHP einfache, sichere Funktionen zum Hashing und Verifizieren 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 es einen zufälligen Salt und fügt ihn in den ausgegebenen Hash ein (zusammen mit den verwendeten Kosten und dem Algorithmus). password_verify() liest dann diesen Hash und bestimmt die verwendete Salz- und Verschlüsselungsmethode und verifiziert diese gegen das bereitgestellte Klartext-Passwort.

Bereitstellung der PASSWORD_DEFAULT weist PHP an, den Standard-Hashing-Algorithmus der installierten PHP-Version zu verwenden. Genau welcher Algorithmus das heißt, soll sich in zukünftigen Versionen im Laufe der Zeit ändern, so dass er immer einer der stärksten verfügbaren Algorithmen sein wird.

Steigende Kosten (standardmäßig 10) machen den Hash zu Brute-Force, aber das bedeutet auch, dass das Generieren von Hashes und das Verifizieren von Passwörtern für sie mehr Arbeit für die CPU Ihres Servers bedeutet.

Beachten Sie, dass auch wenn sich der standardmäßige Hashing-Algorithmus ändert, alte Hashes weiterhin gut verifiziert werden, da der verwendete Algorithmus im Hash gespeichert ist und password_verify() nimmt es auf.


30
2017-09-21 21:33



Ich möchte nur darauf hinweisen, dass PHP 5.5 ein Passwort Hash-API das bietet einen Wrapper um crypt(). Diese API vereinfacht die Hashing-, Verifying- und Rashashing-Funktion für Passwort-Hashes erheblich. Der Autor hat auch ein Kompatibilitätspaket (in Form einer einzigen password.php Datei, die Sie einfach require zu verwenden), für diejenigen, die PHP 5.3.7 und höher benutzen und dieses jetzt benutzen wollen.

Es unterstützt derzeit nur BCRYPT, aber es soll einfach um andere Passwort-Hashing-Techniken erweitert werden und da die Technik und die Kosten als Teil des Hashes gespeichert werden, werden Änderungen an Ihrer bevorzugten Hashing-Technik / Kosten die aktuellen Hashes, das Framework nicht ungültig machen wird automatisch die korrekte Technik / Kosten bei der Validierung verwenden. Es behandelt auch das Generieren eines "sicheren" Salzes, wenn Sie nicht explizit Ihr eigenes definieren.

Die API bietet vier Funktionen:

  • password_get_info() - gibt Informationen über den gegebenen Hash zurück
  • password_hash() - Erstellt einen 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 mit Ihrem aktuellen Technik- / Kostenschema übereinstimmt, so dass Sie bei Bedarf einen erneuten Hash erstellen können
  • password_verify() - überprüft, ob ein Passwort mit einem Hash übereinstimmt

Im Moment akzeptieren diese Funktionen die Passwortkonstanten PASSWORD_BCRYPT und PASSWORD_DEFAULT, die momentan auch synonym sind. Der Unterschied ist, dass PASSWORD_DEFAULT "in neueren PHP-Versionen geändert werden kann, wenn neuere, stärkere Hashing-Algorithmen unterstützt werden." Die Verwendung von PASSWORD_DEFAULT und password_needs_rehash () beim Anmelden (und ggf. beim erneuten Speichern) sollte sicherstellen, dass Ihre Hashes relativ robust gegenüber Brute-Force-Angriffen sind, mit wenig oder gar keiner Arbeit für Sie.

EDIT: Ich habe gerade gemerkt, dass dies in Robert Ks Antwort kurz erwähnt wird. Ich werde diese Antwort hier lassen, da ich denke, dass sie ein bisschen mehr Informationen darüber gibt, wie es funktioniert und wie einfach es für diejenigen ist, die Sicherheit nicht kennen.


25
2018-04-27 21:41



Ich benutze Passieren Dies ist eine einfache Ein-Datei-PHP-Klasse, die in fast jedem PHP-Projekt sehr einfach implementiert werden konnte. Siehe auch Der H.

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

Der zurückgegebene Hash könnte 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);

17
2018-06-26 08:05



Dinge zu erinnern

Es wurde viel über die Passwortverschlüsselung für PHP gesagt, von denen die meisten sehr gute Ratschläge sind, aber bevor Sie überhaupt mit der Verwendung von PHP für die Passwortverschlüsselung beginnen, stellen Sie sicher, dass Sie Folgendes implementiert haben oder für die Implementierung bereit sind.

SERVER

HÄFEN

Egal wie gut Ihre Verschlüsselung ist, wenn Sie den Server, auf dem PHP und DB laufen, nicht richtig sichern, sind all Ihre Bemühungen wertlos. Die meisten Server funktionieren auf die gleiche Art und Weise. Sie haben Ports zugewiesen, damit Sie per FTP oder Shell auf sie zugreifen können. Stellen Sie sicher, dass Sie den Standardport der Remote-Verbindung ändern, die Sie aktiviert haben. Wenn Sie dies nicht getan haben, haben Sie den Angreifer tatsächlich dazu veranlasst, einen Schritt weniger beim Zugriff auf Ihr System zu tun.

NUTZERNAME

Für alles, was in der Welt gut ist, benutze nicht den Benutzernamen admin, root oder etwas Ähnliches. Auch wenn Sie auf einem Unix-basierten System sind, sollten Sie den root-Account-Login NICHT zugänglich machen, er sollte immer nur sudo sein.

PASSWORT

Sie sagen Ihren Benutzern, dass sie gute Passwörter erstellen müssen, um Hackerangriffe zu vermeiden. Was ist der springende Punkt, wenn du die ganze Tür sperrst, wenn du die Hintertür weit offen hast?

DATENBANK

SERVER

Im Idealfall möchten Sie Ihre DB und APPLICATION auf separaten Servern. Dies ist aus Kostengründen nicht immer möglich, ermöglicht jedoch eine gewisse Sicherheit, da der Angreifer zwei Schritte durchlaufen muss, um vollständig auf das System zugreifen zu können.

BENUTZER

Lassen Sie Ihre Anwendung immer über ihr eigenes Konto verfügen, um auf die Datenbank zuzugreifen, und geben Sie ihr nur die Berechtigungen, die sie benötigen.

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

Wie immer machen Sie diese Wurzel oder etwas ähnliches nicht.

PASSWORT

Befolgen Sie die gleichen Richtlinien wie bei allen guten Passwörtern. Verwende das gleiche Passwort auch nicht für SERVER- oder DB-Konten auf demselben System.

PHP

PASSWORT

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

HASHING

ONE WAY HASHING !!!!!!!, Hash nie ein Passwort in einer Weise, dass es umgekehrt werden kann, Hashes sollte eine Möglichkeit sein, dh Sie nicht umgekehrt und vergleichen Sie sie mit dem Passwort, Sie Hash stattdessen das eingegebene Passwort genauso und vergleiche die beiden Hashes. Dies bedeutet, dass selbst wenn ein Angreifer Zugriff auf die Datenbank erhält, er nicht weiß, was das eigentliche Passwort ist, nur der resultierende Hash. Das bedeutet mehr Sicherheit für Ihre Benutzer im schlimmsten Fall.

Es gibt viele gute Hashfunktionen (password_hash, hashusw.), aber Sie müssen einen guten Algorithmus auswählen, damit der Hash wirksam wird. (bcrypt und ähnliche sind anständige Algorithmen.)

Wenn die Hash-Geschwindigkeit der Schlüssel ist, ist der Widerstand umso langsamer, je mehr Brute-Force-Angriffen ausgesetzt sind.

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

SALZEN

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

Wenn Sie ein Salz erstellen, stellen Sie sicher, dass es für das gesalzene Passwort eindeutig ist, und speichern Sie dann sowohl den abgeschlossenen Hash als auch das Salz in Ihrer Datenbank. Was dies tun wird, ist, dass ein Angreifer jedes Salz und jeden Hasch einzeln knacken muss, bevor sie Zugang bekommen können. Das bedeutet viel mehr Arbeit und Zeit für den Angreifer.

BENUTZER ERSTELLEN PASSWÖRTER

Wenn der Benutzer ein Kennwort über das Frontend erstellt, muss es an den Server gesendet werden. Dies führt zu einem Sicherheitsproblem, da das unverschlüsselte Passwort an den Server gesendet wird und ein Angreifer in der Lage ist zuzuhören und darauf zuzugreifen, dass all Ihre Sicherheit in PHP wertlos ist. IMMER die Daten SECURELY übertragen, dies geschieht durch SSL, aber sei müde, auch SSL ist nicht fehlerfrei (OpenSSL Heartbleed Fehler ist ein Beispiel dafür).

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

Unabhängig von den Sicherheitsmaßnahmen, die Sie ergreifen, ist nichts zu 100% sicher. Je fortschrittlicher die Technologie zum Schutz wird, desto fortgeschrittener werden die Angriffe. Wenn Sie jedoch diese Schritte befolgen, wird Ihre Site sicherer und für Angreifer weniger wünschenswert.

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

http://git.io/mSJqpw


13
2018-04-09 15:01



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 immer, je länger Sie wählen, desto sicherer, langsamer wird es. 64 Bytes sollten in Ordnung sein, denke ich.


12
2017-12-30 22:20