OK - das habe ich schon mal verstanden:
Code: Alles auswählen
HTTP_HOST: www.mobirise-tutorials.com
MD5 SiteKey: 26f67********ecb7c4bfb
Temp-Verzeichnis: /tmp
Benutzerdatei: /tmp/vn_login_users_26f676*******************b7c4bfb.json
------------------------------------------------------------
{
"admin": {
"password": "******lrQMHgjN***********MDMbnt2Wr*******wEXiU.tHQftTwIq",
"email": "",
"status": "active",
"created": "2026-07-04 09:33:28"
},
"tester": {
"password": "$2y$********************CYuclwBYuCk5ZE2Il7tZvg9vUbD2B.jw5G8kGwiS",
"email": "",
"status": "active",
"created": "2026-07-04 09:34:30"
}
}
Du weißt aber auch, dass ein Aufruf mal
mit www. oder
ohne www. zu verschiedenen Login Dateien führt
Für eine kleine private Test-Anwendung ist das schon brauchbar, aber als „wirklich sicher“ würde ich diese Lösung so noch nicht bezeichnen.
Der wichtigste Punkt zuerst: Das Passwort selbst wird korrekt gehasht gespeichert:
password_hash($password, PASSWORD_BCRYPT)
Das ist grundsätzlich gut. Auch password_verify() ist dafür richtig. In der JSON-Datei steht also kein Klartextpasswort.
Trotzdem sehe ich einige Schwachstellen.
Was daran gut ist
Die Benutzerdatei liegt nicht direkt im Webverzeichnis, sondern im Server-Temp-Ordner:
sys_get_temp_dir()
Dadurch kann man sie normalerweise nicht einfach per Browser herunterladen. Außerdem wird das Passwort nicht entschlüsselbar gespeichert, sondern als Hash.
Für eine einfache Login-Verwaltung ist das schon besser als viele Bastellösungen.
Was problematisch ist:
Der Temp-Ordner ist kein besonders guter Dauer-Speicherort. Je nach Server kann /tmp irgendwann automatisch gelöscht werden. Dann wäre plötzlich wieder firstRun aktiv und jeder, der die Setup-Seite aufruft, könnte theoretisch einen neuen Admin anlegen.
Das ist aus meiner Sicht die größte Schwachstelle.
Problematisch ist auch diese Logik:
$firstRun = ($users === null);
Sobald die Datei fehlt oder kaputt ist, wird wieder Setup erlaubt. Das ist bequem, aber gefährlich.
Besser wäre: Das Setup sollte nach der ersten Einrichtung zusätzlich durch eine feste Sperre geschützt werden, zum Beispiel durch eine Datei im Webspace oder eine Konstante wie:
define('ALLOW_SETUP', false);
Nach der Einrichtung müsste man das manuell auf false setzen.
Weitere Schwachstellen
Es gibt keinen Schutz gegen viele Login-Versuche. Jemand könnte also sehr viele Passwörter ausprobieren. Mindestens eine kleine Sperre nach z.B. 5 Fehlversuchen wäre sinnvoll.
Außerdem sehe ich keinen CSRF-Schutz für Admin-Aktionen wie Benutzer löschen oder anlegen. Wenn du als Admin eingeloggt bist und eine manipulierte Seite besuchst, könnten theoretisch Aktionen ausgelöst werden, falls die Anwendung entsprechend eingebunden ist.
Auch die Session wird nicht besonders gehärtet. Vor einem Login wäre z.B. sinnvoll:
session_regenerate_id(true);
direkt nach erfolgreichem Login und Setup. Das schützt besser gegen Session-Fixation.
Meine Einschätzung
Für „Volker testet etwas, du testest mit, nicht öffentlich beworben“: okay, aber mit Vorsicht.
Für eine öffentliche Anwendung mit echten Benutzern: so noch nicht ausreichend sicher.
Ich würde mindestens diese Dinge ändern:
1. Benutzerdatei nicht in /tmp speichern, sondern in einen geschützten Ordner außerhalb des Webroots.
2. Setup nach der Einrichtung dauerhaft sperren.
3. Login-Versuche begrenzen.
4. session_regenerate_id(true) nach Login/Setup einbauen.
5. Admin-Aktionen mit CSRF-Token absichern.
6. JSON-Datei mit LOCK_EX speichern.
Besonders Punkt 1 und 2 würde ich unbedingt machen. Das Zurücksetzen über „Datei löschen“ ist praktisch, aber genau diese Bequemlichkeit ist sicherheitstechnisch heikel.
