Es gibt verschiedene Gründe, warum man ein WordPress-Backup wiederherstellt.
Vielleicht zieht die Website auf einen anderen Server um. Vielleicht muss nach einem Sicherheitsproblem eine saubere Sicherung zurückgespielt werden. Oder man arbeitet mit einer Master-Installation: einer vorbereiteten WordPress-Seite, in der Plugins, Einstellungen und grundlegende Konfigurationen bereits eingerichtet sind und die anschließend als Ausgangspunkt für eine weitere Website dient.
Gerade bei einer solchen Kopie sollte man allerdings nicht einfach alles unverändert übernehmen.
Ein Punkt, den ich dabei kontrolliere, sind die WordPress Security Keys und Salts in der wp-config.php.
Was sind die WordPress Keys und Salts?
In einer normalen WordPress-Konfiguration findet man acht entsprechende Konstanten:
AUTH_KEYSECURE_AUTH_KEYLOGGED_IN_KEYNONCE_KEYAUTH_SALTSECURE_AUTH_SALTLOGGED_IN_SALTNONCE_SALT
Genau genommen handelt es sich also um vier Keys und vier Salts.
Dahinter stehen lange, zufällige Zeichenfolgen. Sie werden von WordPress unter anderem verwendet, um Authentifizierungsdaten und Cookies kryptografisch abzusichern.
Diese Zeichenfolgen sollte man nicht selbst nach dem Muster „Das sieht schön zufällig aus“ zusammenbauen. WordPress stellt dafür einen eigenen Generator zur Verfügung.
Neue WordPress Security Keys und Salts generieren
Bei jedem Aufruf erhält man einen neuen Satz aus acht zufällig erzeugten Zeilen.
Warum sollte ich die Salts bei einer kopierten Website ändern?
Wenn ich eine komplette WordPress-Installation als Master-Backup verwende, wird zunächst auch deren wp-config.php kopiert.
Damit würden verschiedene Installationen mit denselben dort eingetragenen Security Keys und Salts starten.
Das möchte ich nicht. Für eine neue, eigenständige WordPress-Installation verwende ich auch eigene zufällige Schlüssel.
Nach einer Wiederherstellung wegen eines Sicherheitsvorfalls gibt es noch einen weiteren guten Grund: Werden die Keys und Salts geändert, verlieren bisherige WordPress-Authentifizierungs-Cookies ihre Gültigkeit. Bereits angemeldete Benutzer müssen sich anschließend neu anmelden.
Ein Salt-Wechsel ist bei einer gehackten Website allerdings nur ein Teil der Arbeit. Zugangsdaten, Benutzerkonten, Plugins, Themes, WordPress-Core, Server und mögliche Ursachen des Angriffs müssen ebenfalls geprüft werden. Ein paar neue Zeichenfolgen machen aus einer kompromittierten Installation nicht automatisch wieder eine saubere Website.
So tausche ich die WordPress Keys und Salts aus
Der eigentliche Austausch ist überschaubar. Trotzdem verändert man mit der wp-config.php eine zentrale WordPress-Datei. Entsprechend sorgfältig sollte man vorgehen.
- Ein funktionierendes Backup der Website erstellen.
- Zusätzlich die aktuelle
wp-config.phpseparat sichern. - Über den offiziellen WordPress-Generator einen neuen Satz Keys und Salts erzeugen.
- Die
wp-config.phpüber den Serverzugang herunterladen oder dort kontrolliert bearbeiten. - Die acht vorhandenen KEY- und SALT-Zeilen suchen.
- Genau diese acht vollständigen Zeilen durch die neu erzeugten Zeilen ersetzen.
- Die Datei wieder auf den Server übertragen.
- Website und Administrationsbereich aufrufen und die Funktion kontrollieren.
- Neu bei WordPress anmelden.
Für die Dateiübertragung würde ich, wenn der Hoster es unterstützt, SFTP oder eine vergleichbar abgesicherte Verbindung einem unverschlüsselten klassischen FTP-Zugang vorziehen.
Die alten und neuen Werte nicht vermischen
Ich würde immer den kompletten Satz austauschen und nicht anfangen, einzelne alte und neue Zeilen miteinander zu kombinieren.
Wichtig ist außerdem, wirklich nur die vorgesehenen Konstanten zu ersetzen. Datenbankname, Datenbankpasswort, Tabellenpräfix oder andere Einstellungen der wp-config.php haben damit nichts zu tun.
Die vom WordPress-Generator erzeugten Zeichenfolgen können ziemlich wild aussehen. Sonderzeichen gehören dort dazu. Deshalb ändere ich diese Werte nicht nachträglich und tippe sie möglichst auch nicht von Hand ab, sondern übernehme die vollständig generierten Zeilen.
Nach dem Austausch ist die Abmeldung normal
Nach dem Speichern kann es zunächst so aussehen, als hätte WordPress einen einfach hinausgeworfen.
Genau das ist zu erwarten.
Durch die neuen Keys und Salts passen die vorherigen Authentifizierungs-Cookies nicht mehr zur neuen Konfiguration. WordPress verlangt deshalb eine neue Anmeldung.
Benutzername und Passwort werden dadurch nicht geändert. Es werden auch keine Benutzerkonten gelöscht.
Man meldet sich einfach erneut an und WordPress erzeugt neue gültige Authentifizierungsdaten auf Grundlage der neuen Konfiguration.
Vorsicht bei Security- und 2FA-Plugins
Bei Sicherheitsplugins würde ich nicht pauschal sagen: Vorher immer deaktivieren.
Das Ändern der WordPress Keys und Salts benötigt grundsätzlich kein deaktiviertes Security-Plugin.
Allerdings können Sicherheitslösungen eigene Login-Verfahren, zusätzliche Cookies, Zwei-Faktor-Authentifizierung oder andere Schutzmechanismen verwenden. Manche Erweiterungen nutzen WordPress-Schlüssel außerdem für eigene kryptografische Funktionen.
Deshalb sollte man vor dem Austausch wissen, wie die eigene Sicherheitslösung arbeitet.
Wenn es bei einer bestimmten Kombination bekannte Probleme gibt, kann eine vorübergehende Deaktivierung sinnvoll sein. Dann sollte aber bereits vorher geklärt sein, wie man das Plugin anschließend wieder aktiviert und wie man notfalls über den Serverzugang zurück zur vorherigen Konfiguration gelangt.
Ein funktionierender Zugang zum Webspace und eine gesicherte alte wp-config.php sind an dieser Stelle deutlich hilfreicher als Optimismus.
Nach dem Salt-Wechsel kontrollieren
Nach der Änderung prüfe ich mindestens:
- Lässt sich die Website normal aufrufen?
- Funktioniert die WordPress-Anmeldung?
- Funktioniert eine vorhandene Zwei-Faktor-Authentifizierung?
- Arbeitet das Sicherheitsplugin weiterhin wie vorgesehen?
- Gibt es Fehlermeldungen im Backend oder auf der Website?
Erst wenn diese Punkte funktionieren, ist die Änderung für mich erledigt.
Keine fremden Beispiel-Salts übernehmen
Man findet im Internet immer wieder komplette Beispiele der acht Zeilen. Auch WordPress zeigt solche Beispiele in seiner Dokumentation.
Diese Werte sollte man nicht übernehmen.
Der Sinn der Sache besteht gerade darin, eigene zufällige und möglichst einzigartige Werte für die jeweilige Installation zu verwenden. Deshalb veröffentliche ich an dieser Stelle auch keinen festen Satz zum Kopieren.
Der offizielle Generator liefert bei jedem Aufruf neue Werte:
WordPress Secret-Key Service öffnen
Backup bedeutet nicht: alles ungeprüft übernehmen
Ein vollständiges Backup ist praktisch, weil es Einstellungen, Dateien und Konfigurationen erhält. Bei einer Master-Installation ist genau das sogar der Sinn der Sache.
Aber nicht jede übernommene Einstellung soll zwischen zwei eigenständigen Websites identisch bleiben.
Die Security Keys und Salts gehören für mich deshalb zu den Dingen, die ich nach dem Klonen einer WordPress-Installation kontrolliere und erneuere.
Der Aufwand dafür ist gering. Man arbeitet allerdings an einer der wichtigsten Konfigurationsdateien der Website.
Also vorher sichern, genau hinschauen und nicht einfach acht Zeilen austauschen, während man nebenbei Kaffee über die Tastatur schiebt.
Eine wp-config.php besitzt wenig Sinn für Humor.