Kein Login mehr nach Restore mit UpdraftPlus

Hallo,
ich habe eine Sicherung von UpdraftPlus in mein WP eingespielt und zwar die DB und Themes. Seitdem kann ich mich nicht mehr einloggen.

Gleich nach dem erfolgreichen Restore mit UpdraftPlus meldete mir WP seltsamerweise eine abgelaufene Session, so dass ich mich neu anmelden musste. Es klappt aber nicht mehr. Der htaccess-Admin-Login klappt noch, aber der anschließende WP-Login nicht mehr. Hab's schon 10 mal probiert, Vertippen also ausgeschlossen. Mit anderem Browser klappt's auch nicht.

Die Sicherung war vom 5.7. und am 7.7. musste ich meine Passwörter ändern, einschl. des DB-Passwortes. Der Hoster hat ein Sicherheitsproblem entdeckt und eine Rundmail geschrieben. Ich dachte jetzt, das wäre die Ursache fürs misslingende Login, denn in meiner nicht vom Restore erfassten wp-config ist das neue PW und restored habe ich aber eine DB mit noch altem PW.

Wenn ich in meinem Kunden-Account bei der DB nachschaue, ist aber auch dort nach wie vor das neue PW drin. Also doch alles Paletti und es liegt an etwas ganz anderem? Oder übersehe ich etwas?

Zitat von Autor33

Hallo,

Die Sicherung war vom 5.7. und am 7.7. musste ich meine Passwörter ändern, einschl. des DB-Passwortes. Der Hoster hat ein Sicherheitsproblem entdeckt und eine Rundmail geschrieben. Ich dachte jetzt, das wäre die Ursache fürs misslingende Login, denn in meiner nicht vom Restore erfassten wp-config ist das neue PW und restored habe ich aber eine DB mit noch altem PW.

Wenn ich in meinem Kunden-Account bei der DB nachschaue, ist aber auch dort nach wie vor das neue PW drin. Also doch alles Paletti und es liegt an etwas ganz anderem? Oder übersehe ich etwas?

Um Missverständnisse zu vermeiden: Ich spreche hier immer nur vom Datenbank-PW. Das "normale" Wordpress-PW habe ich am 07.07. nicht geändert. Mit dem normalen Wordpress-PW sollte das Restore vom 05.07 also keine Probleme haben.

Hallo Sepp55,
unsere postings haben sich gerade überschnitten. Danke für deinen Beitrag. Ich versuche es nochmal verständlicher.

1. Am 07.07. habe ich auf Aufforderung des Hosters das Kunden-PW für meinen Hosting-Account, meine Hoster-E-Mails und das Datenbank-PW geändert. Letzteres in der wp-config und in meinem Kundenaccount beim Unterpunkt "MySQl-Datenbanken - Edit - PW ändern/prüfen".

2. Das normale Wordpress-PW habe ich am 07.07. nicht geändert. Ebenso wenig das PW für den zusätzlichen Admin-htaccess-Login.

3. Diese neuen Passwörter sind alle noch aktiv und gültig. Ich logge mich damit in den Kundenaccount ein, schaue meine Mails an und das neue DB-PW steht unverändert in wp-config und im Kundenaccount bei der betreff. MySQL-DB. Bis gestern war "logintechnisch" alles in Ordnung.

4. Gestern abend habe ich die Sicherung vom 05.07. eingespielt, DB und Themes. Seitdem klappt der Wordpress-Login nicht mehr. Htaccess-Login ja, der anschließende WP-Login nicht.

5. In wp-config und im Kundenaccount/MySQL-DB ist nach wie vor das neue Datenbank-PW vom 07.07. drin.

Die Sicherung vom 05.07. sollte eigentlich kein Problem mit dem normalen Wordpress-PW haben, da ich dieses am 07.07. gar nicht geändert habe.

Was ich geändert habe, war das Datenbank-PW. Das steht da noch immer so in der wp-config und im Kundenaccount wie am 07.07. neu angelegt. Kann damit das Restore dennoch ein Problem haben?

Kann das geänderte Datenbank-PW ursächlich sein oder doch das normale WP-PW, das ich aber gar nicht geändert habe am 07.07.?

Keiner?

Wenn es am Datenbank-PW läge, sollte die Website überhaupt nicht aufrufbar sein, oder? Da sie das ist, kann es also wohl nicht am Datenbank-PW liegen. Wobei ich nicht weiß, ob das überhaupt irgendwo in der (neu eingespielten) DB hinterlegt wäre (ähnlich dem Wordpress-PW in der users-Tabelle).

Da ich das Wordpress-PW gar nicht geändert habe, verstehe ich zwar nicht, warum und wie mit einer eingespielten DB-Sicherung das Login nicht mehr klappen sollte, aber es sieht so aus. Jetzt wollte ich mal schauen in der phpMyAdmin, was für ein PW dort eingetragen ist. Leider sieht man es dort aber nur in einer "Hash"-Ansicht, einem langem Zahlen/Buchstaben-Wurm. Kann man das - nur zu Ansichtszwecken - nicht wenigstens kurzfristig mal in Klarschrift sichtbar machen, was da für ein PW tatsächlich in der wp-users als Wordpress-PW eingetragen ist?

Zitat von b3317133

Das DB-Passwort ist nirgends in der DB hinterlegt, nur in wp-config.php

Gut, dann ist das schon mal 100%ig ausgeschlossen.

Zitat von b3317133

Wurden ggf. die xxx_KEY oder xxx_SALT Werte in der wp-config.php geändert?

Ich habe manuell nur das Datenbank-PW geändert und da das Restore nur DB und themes betraf, nicht WP selbst (kann man mit UpdraftPlus meines Wissens auch gar nicht backupen und restoren), hat auch das Restore die wp-config nicht angerührt. Die langen Salt-Zeichenketten könnte ich evtl. prüfen, ich glaube, die bei der Erst-Installation speziell gesichert zu haben auf einem USB-Stick. Kanns mir aber nicht vorstellen.

Zitat von b3317133

Ein neues Passwort via phpMyAdmin kannst Du mit MD5 hashen und in beim Benutzer eintragen, in den Suchmaschinen gibt es dazu eine Vielzahl von Anleitungen. Bestehende Passwörter sichtbar machen kann man nicht, und das ist auch gut so.

Das heißt, auch als Admin kann man ein Mal eingetragenes/vorhandenes PW in phpMyAdmin nicht mehr in Klarschift sichtbar machen? Auch nicht außerhalb der DB, z.B. indem man den hash-wert in ein entsprechendes MD5-Tool eingibt und quasi den üblichen Vorgang umdreht? (Ich habe jetzt einfach mal meine Fantasie spielen lassen, sicherheitstechnisch wäre das natürlich nicht gut für WP-Webmaster).

Das wäre in meinem Fall jetzt blöd, ich würde brennend gerne wissen, was da für ein PW drin steht.

Die betreffende Website habe ich vor mind. 2,5 Jahren als Wordpress-Site gestartet.

Zitat von b3317133

Notiere Dir den jetzt existierenden Hash, setze einen neuen MD5 Hash, loggge Dich ein, ändere das Passwort auf alle möglichen Variante, die es sein könnten, vergleiche jeweils den Hash der Datenbank mit dem notierten, das bringt ggf. Licht ins Dunkel...

Du meinst, ich solle einfach mal verschiedene, in Frage kommende PW neu anlegen per phpMyAdmin, schauen, was per MD5 dann für ein Hash erzeugt wird und wenn es der gleiche ist wie der Notierte, dann weiß ich das angelegte PW (in Klarschrift)?

Ich habe mal den dort sichtbaren Hash-Wert verglichen mit zwei anderen Sites/DBen, die das gleiche Wordpress-Passwort haben. Der ist jeweils verschieden, drei unterschiedliche Hash-Werte, obwohl das gleiche PW? Die eine Site ist etwas über drei Jahre alt, die andere nicht ganz drei Jahre.

Zitat von danielgoehr

Ganz generell:
Der Zweck eines Hashs ist, dass man daraus eben nicht das Passwort im Klartext wiederherstellen kann. Genau deshalb werden die Passwörter in der Datenbank gehasht.

Abgesehen davon, dass du gerne wüsstest, was für ein Passwort dort drin steht (was aus o.g. Grund schwer wird): Kannst du dich denn wieder einloggen, wenn du das Passwort, wie von @b3317133 beschrieben/verlinkt, zurücksetzt?

Ich habe es bisher nicht ausprobiert, das WP-PW einfach zu ändern, weder über phpMyAdmin noch über den "PW vergessen"-Link. Der Support des Hosters weiß auch nicht, warum das unberührte WP-PW nicht mehr funktioniert und empfahl dasselbe: Einfach ein neues PW anlegen und wenn's funktioniert, dann ist alles gut und es war halt ein unerklärlicher "Sommer-Käfer".
Diese Option bleibt mir ja immer, einfach PW ändern und vermutlich geht es dann mit dem neuen PW.

Ich will aber eine lokal etwas veränderte Version der Site per Duplicator-Klon wieder live einspielen und das alles nur wegen einer anderen Unerklärlichkeit auf dem Webserver, der etwas nicht zulässt, was ich daher lokal machen muss, nämlich bestimmte Tabellen befüllen.

Beim Einspielen des Klons live wird immerhin die gesamte Installation gelöscht und neu angelegt, was ich noch nie gemacht habe. Wenn dann beim Einspielen des neuen Klons auf der Live-Site wieder irgendetwas nicht plangemäß läuft, dann kennt sich kein Schwein mehr aus, woran das dann liegen könnte, weil dann habe ich
- ein ungelöstes Webserver-Problem (das ich mittels der gesamten Aktion per lokal/Mamp/Duplicator alternativ lösen will)
- eine zwar gelöste PW-Sache, die aber ungeklärt blieb
- seit kurzem eine seltsame Fehlermeldung in der lokalen DB in allen Tabellen, die auch noch ungeklärt ist

Also aus dem größeren Zweck heraus wäre es mir schon recht, nicht ein Fragezeichen auf das nächste zu schichten, selbst wenn es irgendwie "funktioniert". Wenn es nicht anders geht, o.k. dann würde ich notfalls halt ein neues PW anlegen und wenn's einloggen damit klappt, dann das PW-Rätsel ein Rätsel bleiben lassen.

Zitat von b3317133

Nein, Du notierst den Hash und machst dann den Account wieder zugänglich, mit einem MD5 Hash via phpMyAdmin.

Dann loggst Du Dich ein

Dann setzt Du via WordPress in Frage kommende Passwörter...

In Frage kommende Passwörter? Hm, ich habe noch nie das PW geändert seit der Installation. Da liegt wohl die Herausforderung des Vorschlages.
Der im Klartext sichtbare Benutzer in der phpMyAdmin ist jedenfalls unverändert korrekt.

Zitat von b3317133

Mit anderen Installationen kann man die Hashes nicht vergleichen, da auch die _KEY und _SALT Werte eine Rolle spielen, die je Website unterschiedlich sind bzw. sein sollten.

Das erklärt, dass das gleiche PW bei unterschiedlichen Sites unterschiedliche Hashes hat.

Gibt es eigentlich in WP eine Automatik, dass nach dem 5. (?) fehlgeschlagenen Loginversuch dann alle nachfolgenden für eine bestimmte Zeit ebenfalls abgelehnt werden, obwohl der 6. vielleicht der richtige wäre?

Für heute reicht's mir, ich geh jetzt ins Bett.

Zitat von b3317133

Notiere per phpMyAdmin den bestehenden Hash, dann kannst Du ihn auch wieder manuell einspielen, falls nötig.

Und was lässt der Webserver denn nicht zu, das Du lokal machen musst und das dann aber über das Einspielen des Duplicator Pakets vom Ergebnis her irgendwie doch zugelassen wird?

Und wie lautet die "seltsame Fehlermeldung"?

Es geht darum, das alte theme mittels eines Konvertierungsplugins auf dessen Nachfolger umzuswitchen. Das Konvertierungsplugin tut das in zwei Schritten, zuerst legt es ein paar neue Tabellen an (für das neue theme) und dann befüllt es diese. Die neu angelegten Tabellen bleiben aber leer, das Beschreiben erfolgt nicht: "keine Einträge", "0 rows" laut phpMyAdmin.
Das Plugin bringt keine Fehlermeldung und auch per "display errors on" wird keine Fehlermeldung gebracht. Vermutlich irgendein Sicherheitsfeature auf dem Server. Der Support findet aber nichts.
Deswegen der ganze Zinnober. Würde es normal funktionieren, bräuchte ich alles andere (Duplicator ect.) nicht.

Für den Hostersupport hatte ich einen eigenen Account eingerichtet, fällt mir noch ein. Der ist mit dem Restore der DB vom 05.07. wieder verschwunden, weil am 05.07. gab es den noch nicht. In phpMyAdmin bin auch nur Ich als Admin in der wp_users jetzt zu sehen. Vielleicht hat es aber doch damit zu tun?

Und noch eine letzte Info kann ich geben: Die Site hat (noch) kein SSL/https, aber ins Backend komme ich immer mit einer entsprechenden Ausnahmeregelung im Browser per https rein. UpdraftPlus hat deswegen vor dem Restore eine Warnung gegeben (sinngemäß "restored wird http-Site, jetzt hat die Site aber https"). Hätte ich wohl ignorieren können, habe dann aber kurzfristig die Browser-Ausnahme gelöscht und das Restore mit http (und ohne Warnung von UpdraftPlus) gemacht.
Login funktioniert aber weder mit http noch mit https.

Zitat von b3317133

Und wie lautet die "seltsame Fehlermeldung"?

Die seltsame Fehlermeldung lautet
"Warning in .\libraries\sql.lib.php#615
count(): Parameter must be an array or an object that implements Countable".
Siehe Anhang.
Das Installieren von Mamp, das Anlegen der DB und das Importieren des Klons hat ganz normal funktioniert. Warum jetzt plötzlich diese Fehlermeldung in den Tabellen, k.A.
Ein paar Quellen in G sprechen von altem PHP, Mamp nimmt immer das neueste, laut Einstellungen 7.2.1. Die Site hatte 7.0 auf dem Server. Der Hoster unterstützt auf dem Webserver 7.2.3, 7.1.6, 7.1.10 und 7.1.15.

Ein normales PW-Reset per "Lost-your-PW-Link" hat geklappt. Die Ursache des fehlschlagenden Logins mit dem unveränderten WP-PW ist aber noch unklar im Moment.