.htaccess-Passwortschutz: Verzeichnis mit einem Passwort sperren

Für eine Staging-Umgebung, ein Kundenverzeichnis oder einen Bereich, der noch nicht öffentlich sein soll, ist die Basisauthentifizierung von Apache immer noch der schnellste Weg. Zwei Dateien, keine Software, keine Datenbank.

Wie es funktioniert#

Es sind immer zwei Dateien:

• .htaccess — sagt Apache, dass hier ein Passwort verlangt wird, und wo die Nutzerliste liegt.
• .htpasswd — enthält Benutzername und Passwort-Hash, eine Zeile je Nutzer.

Die .htaccess in das zu schützende Verzeichnis:

`` AuthType Basic AuthName "Interner Bereich" AuthUserFile /vollstaendiger/pfad/zu/.htpasswd Require valid-user ``

Vier Zeilen, und eine davon ist die Fehlerquelle: AuthUserFile braucht den absoluten Serverpfad, nicht die Adresse und nicht den relativen Pfad. Also /var/www/vhosts/deinedomain.de/.htpasswd, nicht /.htpasswd. Den Pfad findest du im Hosting-Panel oder über eine PHP-Datei mit echo __DIR__;.

Der Schutz gilt für das Verzeichnis und alle darunter.

Die .htpasswd erzeugen — und woher der Hash kommt#

Der Inhalt sieht so aus:

`` redaktion:$apr1$k3nJ2q9x$8fTv1oQ3nZ5mW0pLd2xYb. ``

Benutzername, Doppelpunkt, Hash. Das Passwort steht dort nie im Klartext.

Auf dem Server, wenn du eine Shell hast:

`` htpasswd -c /pfad/zu/.htpasswd redaktion ``

Das -c legt die Datei neu an und überschreibt eine vorhandene. Für jeden weiteren Nutzer ohne -c.

Ohne Shell, mit PHP — eine Datei anlegen, aufrufen, danach löschen:

``php <?php echo password_hash('DeinPasswort', PASSWORD_BCRYPT); ``

Apache versteht bcrypt seit Version 2.4. Für ältere Server ist crypt oder das Apache-eigene $apr1$ nötig.

Und jetzt der Punkt, um den es hier eigentlich geht: Es gibt Dutzende Webseiten, die dir einen .htpasswd-Hash erzeugen. Sie funktionieren. Aber du tippst dein Passwort in ein fremdes Formular, das es zur Erzeugung im Klartext braucht — und du hast keine Möglichkeit zu prüfen, ob es dort protokolliert wird.

Für ein Wegwerf-Passwort auf einer Testinstallation mag das vertretbar sein. Für alles andere: erzeuge den Hash selbst. Die PHP-Zeile oben ist drei Sekunden Arbeit und verlässt deinen Server nicht.

Die .htpasswd selbst schützen#

Die Datei enthält Hashes, nicht Klartext — aber Hashes lassen sich angreifen, und der Dateiname ist bekannt.

Am besten außerhalb des Web-Wurzelverzeichnisses ablegen. Dann ist sie über den Browser gar nicht erreichbar. Geht das nicht, in die .htaccess:

`` <Files ".htpasswd"> Require all denied </Files> ``

Auf Apache 2.2 hieß das noch Order allow,deny / Deny from all. Wer beide Fassungen mischt, bekommt einen 500er.

Was dieser Schutz taugt — und was nicht#

Er taugt für den Zweck, für den er gedacht ist: einen Bereich vor Zufallsbesuchern und Suchmaschinen verschließen. Eine passwortgeschützte Staging-Umgebung erscheint nicht in der Suche, und das ist der halbe Grund, sie zu schützen — sonst konkurriert sie mit der echten Seite um dieselben Inhalte.

Er taugt nicht als ernsthafte Zugangskontrolle für sensible Daten:

• Ohne HTTPS gehen Name und Passwort im Klartext über die Leitung. Basisauthentifizierung ist nur mit TLS vertretbar — ob deins sauber sitzt, prüft der Security-Scan.
• Es gibt keine Sperre nach Fehlversuchen. Wer raten will, kann das beliebig oft tun, es sei denn, davor sitzt etwas, das mitzählt.
• Der Browser merkt sich die Anmeldung bis zum Schließen; ein Abmelden ist nicht vorgesehen.

Für WordPress-Anmeldeseiten ist das trotzdem eine wirksame zusätzliche Hürde: Ein /wp-login.php hinter Basisauthentifizierung nimmt automatisierten Anmeldeversuchen die Grundlage, bevor PHP überhaupt startet. Das ist einer der Punkte aus WordPress vor Hacking schützen.

Auf nginx gibt es das auch#

Dort heißt es auth_basic und auth_basic_user_file, steht in der zentralen Konfiguration statt in einer Datei im Verzeichnis — und die .htpasswd hat dasselbe Format. Wer eine .htaccess auf einen nginx-Server legt, wundert sich sonst, warum nichts passiert; die Datei wird dort schlicht nicht gelesen. Welcher Server bei dir läuft, sagt der Tech-Stack-Check.