Was ist eine .htpasswd-Datei?
Eine .htpasswd-Datei speichert Benutzernamen und Passwort-Hashes für HTTP-Basic-Auth, den Passwortschutz, den Webserver direkt mitbringen. Jede Zeile hat die Form benutzer:hash. Beim Aufruf einer geschützten Seite fragt der Browser nach Name und Passwort, der Server berechnet den Hash des eingegebenen Passworts und vergleicht ihn mit der Datei. Das Passwort selbst steht nirgends im Klartext.
In vier Schritten zum Passwortschutz
- Server wählen. Der Generator stellt danach das passende Verfahren ein: bcrypt für Apache, Caddy und Traefik, SHA-512-crypt für nginx und HAProxy.
- Benutzer anlegen. Name und Passwort eingeben oder ein Zufallspasswort erzeugen lassen, dann „.htpasswd erzeugen“.
- Datei speichern. Den Inhalt als .htpasswd auf dem Server ablegen, außerhalb des Webverzeichnisses und nur für den Webserver lesbar.
- Server einrichten und testen. Die Konfiguration aus dem zweiten Reiter einfügen, den Server neu laden und mit
curl -Iprüfen, dass ohne Anmeldung 401 zurückkommt.
Welches Verfahren für welchen Server?
Nicht jeder Server liest jedes Format. Die Tabelle fasst die Angaben aus der Dokumentation von Apache 2.4, nginx, Caddy 2, Traefik und HAProxy zusammen. „System“ heißt: Der Server nutzt die crypt-Funktion des Betriebssystems, und es kommt auf deren Fähigkeiten an.
| Verfahren | Apache | nginx | Caddy | Traefik | HAProxy | Sicherheit |
|---|---|---|---|---|---|---|
bcrypt $2y$ | ja, ab 2.4.4 | System | ja, nur dieses | ja | System | gut |
SHA-512-crypt $6$ | System (Linux) | ja | nein | nein | ja | gut |
Apache-MD5 $apr1$ | ja | ja | nein | ja | nein | schwach |
SHA-1 {SHA} | ja | ja | nein | ja | nein | unsicher |
Aktuelle Linux-Distributionen bringen meist eine crypt-Bibliothek mit, die auch bcrypt kennt. Wer das nicht prüfen kann, nimmt für nginx und HAProxy SHA-512-crypt; das läuft unter Linux überall.
Typische Einsätze
- Testseite oder Relaunch verbergen
- Ganze Website schützen, Let's Encrypt freigeben. Ohne Anmeldung antwortet der Server mit 401, Google indexiert nichts.
- WordPress-Anmeldung vor Bots schützen
- Nur wp-login.php bekommt ein zweites Passwort. Das Verzeichnis wp-admin bleibt frei, weil Themes und Plugins über admin-ajax.php darauf zugreifen.
- Traefik-Dashboard oder Docker-Dienst absichern
- Middleware basicauth an den Router hängen; in docker-compose.yml jedes $ doppelt schreiben.
- Monitoring-Endpunkt wie /metrics
- Einen Pfad unter nginx schützen, den eigenen Prometheus-Server per IP freigeben.
- Download-Bereich für Kunden
- Ein Verzeichnis per .htaccess schützen und je Kunde einen Benutzer anlegen. Wer keinen Zugang mehr haben soll, wird aus der Liste gelöscht.
- Dienst in Kubernetes
- Secret mit der Datei „auth“ anlegen und per Annotation am Ingress einbinden.
Wie hoch sollen die bcrypt-Kosten sein?
Bei Basic Auth schickt der Browser die Zugangsdaten mit jeder Anfrage, und der Server prüft sie jedes Mal neu, auch für Bilder, Skripte und Stylesheets. Jede Stufe der Kosten verdoppelt die Rechenzeit. Kosten 10 halten Angreifer deutlich auf und belasten den Server bei normalem Verkehr kaum. Das Apache-Werkzeug htpasswd nimmt ohne -C nur 5. Unter Apache lassen sich mit mod_authn_socache erfolgreiche Prüfungen kurz zwischenspeichern; dann sind auch höhere Kosten unproblematisch.
Sicherheit
- Nur mit HTTPS. Basic Auth überträgt Name und Passwort lediglich Base64-kodiert.
- Datei außerhalb des Webverzeichnisses. Apache sperrt
.ht*-Dateien in der Standardkonfiguration, nginx nicht. Liegt sie doch im Webverzeichnis, unter nginxlocation ~ /\.ht { deny all; }ergänzen. - Rechte setzen.
chmod 640und als Gruppe den Benutzer des Webservers, etwa www-data. - Lange Zufallspasswörter. Der Würfel neben dem Passwortfeld erzeugt 20 Zeichen mit gut 116 Bit; bcrypt wertet höchstens 72 Byte aus.
- Fehlversuche begrenzen. Basic Auth zählt keine Fehlversuche. fail2ban erkennt fehlgeschlagene Anmeldungen in den Logs von Apache und nginx und sperrt die Adresse.
Wenn es nicht funktioniert
- Apache meldet 500 Internal Server Error
- Meist ist der Pfad in AuthUserFile falsch oder relativ, oder der Server erlaubt keine Anmeldeanweisungen in .htaccess. Das Fehlerlog nennt den Grund; für .htaccess braucht das Verzeichnis
AllowOverride AuthConfig. - Die Seite ist ohne Passwort sichtbar
- Unter nginx wird eine .htaccess ignoriert, die Anweisungen gehören in die Serverkonfiguration. Unter Apache steht vermutlich
AllowOverride None. - Die Anmeldung schlägt trotz richtigem Passwort fehl
- Der Server liest das Hash-Format nicht, etwa bcrypt unter nginx ohne passende crypt-Bibliothek. Mit SHA-512-crypt neu erzeugen und im Reiter „Passwort prüfen“ gegenprüfen. Die Datei mit Linux-Zeilenenden (LF) speichern.
- nginx antwortet mit 500 oder 403
- Bei 500 kann nginx die Datei nicht lesen, Rechte und Pfad prüfen. Bei 403 greift eine deny-Regel, etwa wegen
satisfy anymit einer nicht freigegebenen Adresse. - Let's Encrypt kann das Zertifikat nicht erneuern
- Die HTTP-Prüfung unter /.well-known/acme-challenge/ landet hinter dem Passwort. Die Option „Let's Encrypt freigeben“ erzeugt die nötige Ausnahme.
.htpasswd auf der Kommandozeile erstellen
Auf Linux-Servern liefert das Paket apache2-utils (Debian, Ubuntu) bzw. httpd-tools (RHEL, Fedora) das Werkzeug htpasswd. Ohne diese Pakete hilft OpenSSL oder ein Docker-Container.
# Neue Datei mit dem ersten Benutzer (-c überschreibt eine vorhandene Datei)
htpasswd -c -B -C 10 /etc/apache2/.htpasswd admin
# Weiteren Benutzer hinzufügen oder Passwort ändern
htpasswd -B -C 10 /etc/apache2/.htpasswd redaktion
# Benutzer löschen und Passwort prüfen
htpasswd -D /etc/apache2/.htpasswd redaktion
htpasswd -v /etc/apache2/.htpasswd admin
# Mit OpenSSL (SHA-512-crypt), fragt nach dem Passwort
printf 'admin:%s\n' "$(openssl passwd -6)" >> /etc/nginx/.htpasswd
# Mit Docker, ohne Installation
docker run --rm -it httpd:2.4-alpine htpasswd -nB -C 10 adminPasswörter nicht mit -b auf der Kommandozeile übergeben; sie landen sonst im Verlauf der Shell und sind in der Prozessliste sichtbar.
Häufige Fragen
Werden meine Passwörter an den Server übertragen?
Nein. Hashes, Prüfung und Konfiguration entstehen in deinem Browser. Die Seite schickt keine Formulardaten an fanizza.de und lädt keine Skripte von anderen Servern. Benutzer, Passwörter und Hashes werden auch nicht im Browser gespeichert.
Welches Verfahren soll ich für die .htpasswd nehmen?
bcrypt für Apache, Caddy und Traefik. Für nginx und HAProxy SHA-512-crypt ($6$), weil beide bcrypt nur lesen, wenn die crypt-Bibliothek des Betriebssystems es kann. Apache-MD5 (apr1) und SHA-1 nur noch für Systeme, die nichts anderes verstehen.
Funktioniert der Passwortschutz per .htaccess auch mit nginx?
Nein. nginx liest keine .htaccess-Dateien. Die Anweisungen auth_basic und auth_basic_user_file gehören in die Serverkonfiguration, also in den server- oder location-Block. Die .htpasswd selbst funktioniert mit nginx genauso wie mit Apache.
Wo speichere ich die .htpasswd-Datei?
Außerhalb des Webverzeichnisses, etwa unter /etc/apache2/.htpasswd oder /etc/nginx/.htpasswd. In der Konfiguration steht immer der absolute Pfad auf dem Server. Apache sperrt Dateien, die mit .ht beginnen, in der Standardkonfiguration; nginx tut das nicht, dort darf die Datei nie im Webverzeichnis liegen.
Wie hoch sollen die bcrypt-Kosten sein?
Kosten 10 sind ein guter Kompromiss. Bei Basic Auth prüft der Server das Passwort bei jeder Anfrage, also auch für jedes Bild und jede CSS-Datei, und jede Stufe verdoppelt die Rechenzeit. Apache htpasswd nimmt ohne Angabe nur 5. Wer höhere Kosten will, kann unter Apache die Prüfergebnisse mit mod_authn_socache zwischenspeichern.
Ist Basic Auth ohne HTTPS sicher?
Nein. Der Browser schickt Benutzername und Passwort bei jeder Anfrage nur Base64-kodiert, nicht verschlüsselt. Ohne HTTPS kann jeder im selben Netz mitlesen. Mit HTTPS ist Basic Auth für interne Bereiche, Testseiten und Werkzeuge gut geeignet.
Wie melde ich mich bei Basic Auth wieder ab?
Eine Abmeldung sieht das Verfahren nicht vor. Der Browser merkt sich die Zugangsdaten, bis er geschlossen wird. In privaten Fenstern endet die Anmeldung mit dem Fenster.
Schützt eine .htpasswd meine Testseite vor Google?
Ja. Geschützte Seiten antworten ohne Anmeldung mit dem Status 401, und Suchmaschinen indexieren sie nicht. Das ist zuverlässiger als noindex oder robots.txt, weil auch kein Inhalt sichtbar ist.
Darf der Benutzername Umlaute oder Sonderzeichen enthalten?
Ein Doppelpunkt ist verboten, weil er Name und Passwort im Header trennt. Umlaute funktionieren mit aktuellen Browsern meist, werden aber nicht überall gleich kodiert. Für Benutzernamen sind Buchstaben ohne Umlaute, Ziffern, Punkt, Binde- und Unterstrich am sichersten.
Was ist der Unterschied zwischen .htaccess und .htpasswd?
Die .htaccess enthält Anweisungen für Apache, zum Beispiel dass ein Verzeichnis ein Passwort verlangt. Die .htpasswd enthält die Benutzer mit ihren Passwort-Hashes. Die .htaccess verweist mit AuthUserFile auf die .htpasswd.
Verwandte Werkzeuge
- Passwort-Generator für lange Zufallspasswörter und Passphrasen.
- Hash-Generator für Argon2id, bcrypt und PBKDF2 sowie Prüfsummen von Dateien.
- Benutzernamen-Generator mit Regeln für Instagram, GitHub und andere Plattformen.