Sind die Standardsalze sicher?

Wenn Sie ein neues WordPress installieren, sollten Sie die Salze in wp-config.php .

Der Abschnitt sieht so aus

 define('AUTH_KEY', 'put your unique phrase here'); define('SECURE_AUTH_KEY', 'put your unique phrase here'); define('LOGGED_IN_KEY', 'put your unique phrase here'); define('NONCE_KEY', 'put your unique phrase here'); define('AUTH_SALT', 'put your unique phrase here'); define('SECURE_AUTH_SALT', 'put your unique phrase here'); define('LOGGED_IN_SALT', 'put your unique phrase here'); define('NONCE_SALT', 'put your unique phrase here'); 

Wenn der Client diese Salze ändert oder die Konstanten fehlen, speichert WordPress diese Werte stattdessen in der database.

Für die Erzeugung der Salze wird wp_generate_password(64, true, true) Der Code, der dies tut, kann in Pluggable ab Zeile 1993 gefunden werden.

Jetzt ist die Frage:

  • Ist wp_generate_password so sicher wie die von der empfohlenen https://api.wordpress.org/secret-key/1.1/salt/ erzeugten Salze

  • Gibt es eine Herabstufung der Sicherheit durch die Salze in der database, da diese Methode darauf zurückgreift.

  • Hat es irgendwelche Auswirkungen auf die Sicherheit, die Werte nicht zu setzen und sie zufällig auf dem Weg zur db generieren zu lassen?

Solutions Collecting From Web of "Sind die Standardsalze sicher?"

  1. Ist wp_generate_password() so sicher wie die von der empfohlenen https://api.wordpress.org/secret-key/1.1/salt/ erzeugten Salze?

Diese Details können nicht aus offensichtlichen Gründen beantwortet werden, die Interna sind der Öffentlichkeit unbekannt. Wenn wir das beantworten könnten, wären Details bekannt, die ein Reverse-Engineering des processes ermöglichen. Dies könnte zu einer Verringerung der Sicherheit führen. Beachten Sie, dass jemand immer noch versuchen könnte, eine Menge Anfragen an diese URL zu stellen und dann den process rückgängig zu machen, um zu beobachten, welche Blasen an die Oberfläche gelangen.

  1. Gibt es eine Herabstufung der Sicherheit durch die Salze in der database, da diese Methode darauf zurückgreift?

Ja. Sie möchten nicht , dass Sicherheitsdetails / Authentifizierungsdaten überall gespeichert werden, wo andere Benutzer darauf zugreifen können. Das beinhaltet:

  • Versionskontrolle
  • Befehlszeilenverlauf
  • database- oder Datei-Backups

Bewahren Sie Ihre Authentifizierungsdaten und zugehörigen Daten (wie z. B. “salt”) in .env Dateien (siehe Dotenv-Paket ) in Ihrem geheimen sicheren Port für Bereitstellungsdienste in separaten Konfigurationsdateien (z. B. für die AWS-Anmeldeinformationsdatei) auf einzelner Standort.

  1. Hat es irgendwelche Auswirkungen auf die Sicherheit, die Werte nicht zu setzen und sie zufällig auf dem Weg zur db generieren zu lassen ?

Ja. Da auch in Cookies Authentifizierungskonstanten verwendet werden, würden Sie die Anmeldesitzungen Ihrer Benutzer ungültig machen, indem Sie die Cookies Ihrer Benutzer ungültig machen. Das sind Konstanten aus einem Grund: Sie sollten haften und sich nicht pro Anfrage ändern.

Edit: Da @gmazzap mich darauf hingewiesen hat, habe ich nicht über in der database gespeicherte Werte gesprochen, sondern über Konstanten, die “on the fly” generiert wurden . Falls Sie es in der database speichern, lesen Sie bitte Punkt 2 bezüglich Sicherheit.

Für weitere Ergänzungen, folgen Sie bitte dem Link von @Mark Kaplun und lesen Sie @ gmazzap im Detail (und upvote beides).

Zusätzliche Anmerkung / Erinnerung: Fügen Sie den abgerufenen Daten von den API-Servern immer eigene Pseudozufallszeichen hinzu. Und geben Sie niemals Ihre Anmeldeinformationen oder Ihre database aus den Händen. Sie werden nicht glauben, was Menschen per E-Mail senden, auf USB-Sticks, ihren privaten Dropbox-Konten oder auf Festplatten auf Laptops ohne Passwort speichern …

Edit: Wie @stephenharris in [chat] darauf hingewiesen hat, gibt es zu diesem Thema einen interessanten Blogbeitrag, der viel detaillierter ist als unsere Antworten hier.

Is wp_generate_password() so sicher wie die Salze, die vom empfohlenen https://api.wordpress.org/secret-key/1.1/salt/ erzeugt werden Is wp_generate_password()

Wie @kaiser sagte, sind die internen Details der API-Salzgenerierung nicht bekannt, aber – ehrlich gesagt – die API gibt eine Zeichenfolge mit 64 Zeichen zurück, wobei jedes Zeichen eines der 92 möglichen Zeichen ist, die von wp_generate_password() .

Wenn der Server PHP 7 hat, werden zufällige Ganzzahlen, die verwendet werden, um eines der 92 Zeichen auszuwählen , mit PHP 7 CSPRNG erzeugt, und ich bezweifle, dass API etwas stärkeres als dieses haben wird. In älteren PHP-Versionen werden zufällige Werte von mt_rand bereitgestellt.

Wenn man bedenkt, dass die Stärke eines Passworts viel mehr auf dem Verschlüsselungsalgorithmus als auf dem verwendeten Salz wp_generate_password , kann ich sagen, dass wp_generate_password sehr wahrscheinlich genauso sicher ist wie die Salze, die von API erzeugt werden.

Gibt es eine Herabstufung der Sicherheit durch die Salze in der database, da diese Methode darauf zurückgreift.

Für diesen Punkt stimme ich @Kaiser zu .

Nehmen wir an, dass jemand eine Kopie Ihres database-Dumps für eine Sicherung erhält. In diesem DB-Dump können sie die Kennwörter Ihrer Benutzer sehen, jedoch verschlüsselt.

Wenn sie Zugang zu Salzen haben, ist es einfacher für sie, Ihre Website zu hacken.

Durch die Kenntnis des verwendeten Salzes, Benutzer-IDs und Benutzer-Metas (wo Sitzungstoken gespeichert sind) lassen sich darüber hinaus sehr einfach Nonce-Werte für einen beliebigen Benutzer reproduzieren, ohne das “entschlüsselte” Passwort zu kennen.

Natürlich, wenn ein böswilliger Benutzer eine Kopie Ihrer database erhält, ist Ihre Sicherheit sowieso sehr kompromittiert, aber indem Sie Salze in db speichern, machen Sie das Leben dieses böswilligen Benutzers einfacher.

Hat es irgendwelche Auswirkungen auf die Sicherheit, die Werte nicht zu setzen und sie zufällig auf dem Weg zur db generieren zu lassen?

Wenn überhaupt keine Salze gesetzt sind, werden sie nur mit wp_generate_password() generiert, wp_generate_password() WP zum ersten Mal versucht, auf sie zuzugreifen, dann in der database gespeichert wird und bei nachfolgenden Anfragen von dort abgerufen wird.

Wie bereits erwähnt, sind die von wp_generate_password() erzeugten Salze per se nicht schlecht, aber da sie in db gespeichert sind, sind die Implikationen für die Secuity wie bereits erwähnt: Wenn jemand Zugriff auf eine Kopie Ihrer db hat, ist es gefährlicher Diese databasekopie enthält die Salze.

Die wirklichen Auswirkungen auf die Sicherheit sind jedoch, wenn für Salze nicht sichere Werte verwendet werden. In der Tat, wenn schwache Werte in der Konfiguration eingestellt sind, erzeugt WP keinen Wert, sondern verwendet diese schwachen Werte. Kurz gesagt, wenn die Wahl zwischen keinen Salzen in der Konfiguration und schwachen Salzen ist, ist ersteres sicherlich besser.

Beachten Sie, dass in neueren Versionen von WP (nicht sicher seit welcher Version) der Standardwert 'put your unique phrase here' ignoriert wird. Wenn also wp-config.php diesen Wert für jedes Salz enthält, ignoriert WordPress ihn und verwendet einen Wert generiert mit wp_generate_password() , das ist besser als ein schwacher Wert, aber schlechter als ein starker Wert, der in config gespeichert ist (weil das Speichern von Salzen in db …). Automatisch erzeugte Werte werden auch dann verwendet, wenn derselbe Salzwert für mehr als einmal Salz verwendet wird.

Anmerkungen

  • Bei einer Änderung der Salze werden alle Benutzer ausgeloggt, die vor der Änderung bei Ihrer Site angemeldet waren, einschließlich der Benutzer, die nicht angemeldet sind, wenn Sie sich vor der Änderung angemeldet haben.

  • Wenn WordPress mit dem “Installer” (ohne manuelles Erstellen von wp-config.php ) installiert wird, werden wp-config.php Werte erzeugt, indem Werte aus der API gezogen werden.

  1. Es hängt von der Zufälligkeit ab, die auf Ihrer Maschine erreicht werden kann. Ich erinnere nicht die genauen Details, aber die wordpress.org API ist dort, wenn die Zufälligkeit Ihrer Maschine nicht gut genug ist.

  2. Wahrscheinlich nicht. Wenn jemand diese Art von Zugriff auf Ihre database oder Ihren Code hat, dann sind Sie in jedem Fall Toast und das Erhalten der Salze ist das unwichtigste Problem, dem Sie gegenüberstehen.

  3. Was wäre ein Grund, das zu tun? Wenn Sie diese 8 Werte aus der database abrufen, wird jede Seite sehr langsam geschaltet, ohne dass Ihre Sicherheit dadurch verbessert wird.

Edit: Warum Zufall (Entropie) zählt

Erstens, vielleicht diese https://security.stackexchange.com/questions/61676/why-do-wordpress-installations-retrieve-the-crypto-secrets-remotely-on-installat wird es besser erklären als ich

Das Problem ist, dass Salze nicht erraten werden sollten, deshalb werden sie erzeugt, indem einige Zufallszahlengeneratoren weitergeleitet werden, was die meisten Betriebssysteme haben. Aber nicht alle Zufallsgeneratoren werden gleich erzeugt und wenn zum Beispiel Ihr Generator nicht einige Werte aus der Umgebung als Eingabe verwendet, wird er die gleiche Folge von Zahlen erzeugen und daher kann jeder, der das Verhalten des Betriebssystems inspiziert, mit der ersten kommen 1000 Zahlen, die generiert werden, verwenden sie als Salze und haben es leichter, Ihr Passwort zu erraten.

Dies ist besonders problematisch in einer Shared-Hosting-Umgebung, wo alle Sites den gleichen Zufallsgenerator verwenden und daher Zugriff auf die Sequenz der zufällig generierten Zahlen haben und basierend auf dem Wissen des OS und des von ihm verwendeten Zufallsalgorithmus den nächsten und raten können zuvor generierte Zahlen.

Randnotiz: Dies ist der Grund, warum Smartphone und andere Software Sie bittet, einige zufällige Eingaben zu machen, wenn Sie die Geräte / Software initialisieren. Diese zufällige Eingabe dient als Basis für die Generierung von Zufallszahlen und stellt sicher, dass jedes Gerät eine andere Zahlenfolge generiert.

Der Vorteil der Verwendung von wordpress.org als Zufallszahlengenerator besteht darin, dass die von Ihnen erzeugten Zahlen ohne Zugriff auf die Server nicht zu erraten sind, da Sie nicht wissen, welcher Algorithmus verwendet wird, wie er initialisiert wurde und wo in der Reihenfolge, in der du gerade stehst.

Aber wie die Frage, zu der ich mich verbunden habe, aussagt, ist die Weitergabe externer Dienste ebenfalls ein Sicherheitsproblem. Ich finde, dass dies die Paranoia grenzt, da diese Art von Angriffsweg eine Raffinesse erfordert, die den meisten Angreifern fehlt (im Zusammenhang mit angreifenden WordPress-Sites), und ich würde mir keine Sorgen über die Qualität des Zufallsgenerators machen, aber wenn Sie das tun, müssen Sie alles tun erzeugt die Salze selbst, vielleicht mit Hilfe einer Zufallssoftware, die nicht mit dem Server zusammenhängt, und aktualisiert die Konfigurationsdatei.