Florian Köhler 
07.08.2011 
8 KommentareDas Problem
Nach reibungsloser Installation von Typo3 (4.5.4) auf einem Windows Server (2003) mit PHP 5.2.6 wollte ich mich ins Backend von Typo3 als Standard-User (admin / password) einloggen. Doch zu meiner Verwunderung bekam ich im Login Fenster stets folgende Meldung angezeigt:
Ihr Anmeldeversuch war nicht erfolgreich. Bitte stellen Sie sicher, dass Ihr Benutzername und Passwort korrekt sind. Groß-/Kleinschreibung wird unterschieden.
Erfolglose Versuche
- Mehrmaliges Anlegen eines neuen Administrators über das Backend
- Bereinigen der Installationsverzeichnisse / Datenbanktabellen und Neuinstallation (vers. 4.5.0, 4.5.2, 4.5.4)
- Löschen aller Dateien im Temp-Verzeichnis und Temp-Dateien in typo3conf
- Testen in verschiedenen Standard-Browsern (Cache/Cookie- Problematik)
- Anlegen einer neuen Domain in Plesk
- Löschen des Administratorpasswortes (Hashwert) in der be_user Tabelle der MySQL Datenbank
- Verzicht auf den UTF-8 Zeichensatz
Die (vorrübergehende) Lösung
Nach unzähligen erfolglosen Versuchen stieß ich im Typo3 Install-Tool unter All Configuration auf folgende Einstellungsmöglichkeit:
loginSecurityLevel ($TYPO3_CONF_VARS[‘BE’][‘loginSecurityLevel’])
Mit dieser Option kann festgelegt werden, welche Authentifizierungsmethode Typo3 beim Login im Backend verwenden soll. Standardmäßig ist hier nichts eingetragen, wodurch das Passwort als MD5- Hashsumme in die Tabelle be_user eingetragen wird. Mit zwei einfachen Schritten lässt sich Backend-Bereich von Typo3 wie gewohnt erreichen:
1. Trägt man bei [‘BE’][‘loginSecurityLevel’] den Wert ‚normal‘ ein, so wird auf die Bildung des Hashwertes bei der Authentifizierung verzichtet.
2. Als logische Folge daraus muss nun in der Datenbanktabelle „be_user“ für das Passwort statt der Hashsumme der eigentliche Wert eingetragen werden (für den Standarduser „admin“ somit „password“). Das funktioniert am einfachsten über das PhpMyAdmin Tool.
Nun Sollte der der Login wie gewohnt funktionieren.
Folgerungen und Sicherheitsproblematik
Das beschriebene Workaround ist im Hinblick auf entstehende Sicherheitsrisiken nicht die Premiumlösung, da das Passwort nun „unverschlüsselt“ in der Datenbank zu finden ist. Allerdings muss man solche Risiken auch immer ein wenig realtivieren:
Typo3 selbst schreibt im Manual:
Passwortübertragung und Speicherung (Backend) sind MD5 verschlüsselt.
Zum einen handelt es sich bei der standardmäßig verwendeten Authentifizierung (MD5) nicht um eine Verschlüsselung im eigenen Sinne. Wer zur Pseudo-Verschlüsselung MD5 mehr wissen möchte, dem empfehle ich diesen Link. Somit wird weder das im Browser eingegebene Passwort auf dem Weg zum Server standardmäßig verschlüsselt noch wird es verschlüsselt in der Datenbank abgelegt.
Hat ein Hacker es zum anderen wirklich auf die das Typo3 System und somit die Datenbank abgesehen, so benötigt er zunächst in irgendeiner Form Zugang zu dieser, unabhängig, in welcher Form das Passwort des Backend- Administrators hinterlegt ist. Hat sich der Unbefugte diesen Zugang erst einmal erschlichen, wird er sich wohl kaum die Mühe machen, das der Hashsumme zu Grunde liegende Passwort des Administrators zu ermitteln, wenn er auch die Möglichkeit besitze, innerhalb von einer halben Minute einen eigenständigen Admin-User anzulegen.
Für alle, die ebenfalls auf das Problem mit dem fehlerhaften Login gestoßen sind und nicht gewillt sind, das Passwort im Klartext einzutragen, könnte, ohne es probiert und getestet zu haben, auch die von Typo3 mitgelieferte Erweiterung rsaauth/ saltedpasswords eine Alternative sein. Hierzu muss im Install-Tool für [‘BE’][‘loginSecurityLevel’] der Wert ‚rsa‘ eingetragen werden.
Ursache
Da auf dem selben Server ein weiteres Typo3 (4.5.0) im Einsatz ist, bei dem die Standardauthentifizierung problemlos funktioniert, erschließt sich mir die eigentliche Ursache für das Problem derzeit noch gar nicht. Eine meiner ersten Vermutungen, eine veraltete PHP Version / Bibliothek, kann somit eigentlich nahezu ausgeschlossen werden.
Für Feedback, Anregungen und Neuigkeiten hierzu bin ich Euch sehr dankbar.
Update: Möglicher Lösungsansatz
Ich hatte es eigentlich fast schon aufgegeben, nach einer Lösung für das Problem zu suchen. Bei einem neuen Projekt (Windows Server 2008) trat der selbe Fehler allerdings erneut auf. Doch diesmal wurde ich dank dem folgenden Boardeintrag fündig: Schuld waren fehlende Schreibberechtigungen für den Ordner, den PHP zum Anlegen von Sessions und error logs verwendet. Nachdem der entsprechende IUSR die Rechte erhalten hatte, funktionierte nun auch der BE Login.
Auch ich habe das selbe Problem. Bei mir trat das Problem dann auf, als ich Typo3 von Windows auf Linux portiert habe. Version 4.5.3.
Konntest du die Ursache schon ausfindig machen?
Hallo Robert. Viele Dank für den Hinweis. Das schließt zumindest aus, dass der Fehler einzig und allein auf Windows Plattformen auftritt, was ich eigentlich vermutet hatte.
Da es zu dem Thema zwar unzählige Ansätze gibt, aber keine “Generallösung” könnte es natürlich auch gut sein, dass unsere beiden Probleme unterschiedlichen Ursprungs sind. Hast du mal den MD5 Hash rausgenommen und getestet, ob es bei dir dann funktioniert?
Ich hab leider auch noch keine anderen Tipps bekommen.
Grüße
Flo
Update: Fehlende Schreibberechtigungen für den Sessionsordner waren bei mir Ursache des Problems.
Natürlich ist md5 keine Verschlüsselung. Denn sonst wäre es ja möglich einen Hash-Wert wieder zurückzurechnen. Genau dies soll ja nicht passieren können. Hat man einen langen md5-hash, so kann nicht das Passwort zurückberechenen. Wenn Passwörter allerdings als leslicher Text in der DB vorliegen, dann kann ein Hacker mit der Kombi Benutzername und Passwort eineiiges anstellen!!! Viele User verwenden auch das gleiche Passwort an anderer Stelle. Nicht auszudenken, welche Türen und Toren durch deine Methode geöffnet werden.
Bei einem hash wird gar nicht das Passwort (auch nicht verschlüsselt) abgespeichert. Man kann nur vergleichen, ob der Hash von z verschiedenen Zeichenketten identisch ist oder nicht. Genau deshalb verwendet man das auch so. Bei einem Typo3 CMS mit Klartextspeicherung des Passwortes möchte ich kein user sein.
Hallo Paul, danke für deinen Kommentar. Ich geb dir vollkommen recht und hatte auf die Sicherheitsrisiken verwiesen. Die Ursache liegt ganz klar an den fehlenden Schreibberechtigungen: PHP benötigt für das Anlegen von Session wohl einen Ordner mit Schreibzugriff. Da der IUSR für diesen Ordner nicht eingetragen war, konnte die Session nicht gestartet werden.
Gruß Flo
Wo finde ich denn diese Ordner, die ich nun benötige um diese Sache mit PHP zu bereinigen? Und was kommt da rein?
Ich habe Typo3 auch hochgeladen mit der 5.2 Version von PHP. Danach habe ich erst 5.3 aktiviert, da ja Typo3 nun 5.3 benötigt!
Jetzt komme ich nicht ins BE hinein.
Das Verzeichnis wird in der php.ini im Bereich unter session.save_path definiert. Prinzipiell kann ein x-beliebiges Verzeichnis dafür verwendet werden, wichtig ist nur, dass der Webserver-User (IUSR, Netzwerkdienst, …) darauf das “Ändern” Recht erhält.
Ich habe heute folgendes festgestellt:
Nachdem ich mich nach einem Neustart des Browsers erfolgreich im BE anmelden konnte, hat mich Typo3 nach ein paar Minuten herausgeschmissen. Daraufhin konnte ich mich nicht erneut anmelden. Die Loginmaske kam immer wieder.
Sobald ich den Browser cache gellert habe, konnte ich mit diesem Spiel solange fortfahren, bis mich das System wieder herausgeschmissen habe.
Was kann ich tun?