Passwortschutz für Ihre Webseite –
htpasswd erstellen in 2 Minuten

Eine simple Textdatei mit einer Zeile pro Benutzer nach dem Muster benutzername:passworthash. Der Apache-Webserver (und auch nginx) gleicht eingegebene Zugangsdaten gegen diese Datei ab, sobald eine .htaccess den Schutz aktiviert. Das Passwort selbst steht dort nie im Klartext – gespeichert wird nur der Hash, also eine Art kryptografischer Fingerabdruck.

Nein, zu keinem Zeitpunkt. Dieser kostenlose Webseiten-Passwort-Generator rechnet vollständig in Ihrem Browser – es gibt schlicht keinen Server-Code, der Ihre Eingaben entgegennehmen könnte. Sie müssen uns das übrigens nicht glauben, sondern können es selbst nachprüfen: Netzwerk-Tab der Entwicklertools öffnen (F12) oder gleich das WLAN abschalten. Der Generator läuft unbeirrt weiter. Beim Schließen der Seite ist alles weg; gespeichert wird nichts, nicht einmal Einstellungen. Übrigens: Die anonyme Besucherzählung der Webseite (siehe Datenschutzerklärung) ist davon komplett getrennt – sie misst standardmäßig ohne Cookies, Wiedererkennungs-Cookies gibt es nur mit Ihrer Einwilligung, und mit Ihren Eingaben im Generator hat beides nichts zu tun.

Beim Laden rechnet das Tool eine Reihe fest hinterlegter Prüfwerte nach – bekannte Passwörter, deren korrekte bcrypt-, MD5(APR1)- und SHA-1-Hashes vorab mit den Referenzimplementierungen der Serverwelt (u. a. OpenSSL) erzeugt wurden. Nur wenn jedes Ergebnis Bit für Bit übereinstimmt, erscheint der grüne Haken. Sie sehen damit auf einen Blick, dass die Verschlüsselungsberechnung in Ihrem Browser wirklich sauber arbeitet und nicht durch einen exotischen Browser, ein altes Gerät oder eine unvollständig geladene Seite verfälscht wird. Schlägt der Test fehl, zeigt die Seite das offen an – dann bitte keine Hashes erzeugen, sondern zunächst die Seite neu laden. Idealer Weise auch einen anderen Browser verwenden!

Kurz: bcrypt. Es ist gesalzen, absichtlich rechenintensiv und seit über 25 Jahren gut untersucht. Apache unterstützt es seit Version 2.4 (erschienen 2012) – bei praktisch jedem aktuellen Hoster also kein Thema. Nur wenn ein wirklich altes System im Spiel ist, weichen Sie auf APR1-MD5 aus, dann aber bitte mit einem langen Zufallspasswort. Die ausführliche Bewertung aller Verfahren finden Sie oben in der Tabelle.

Der häufigste Stolperstein überhaupt. Apache braucht den Pfad im Dateisystem des Servers (etwa /var/www/vhosts/beispiel.de/.htpasswd), nicht die Internetadresse. Am schnellsten geht's mit dem PHP-Einzeiler aus dem Baukasten: <?php echo __DIR__; ?> in eine Datei packen, aufrufen, Pfad ablesen, Datei löschen. Viele Hoster zeigen den Pfad auch im Kundenmenü unter Stichworten wie „Verzeichnisschutz“ oder „Webspace-Pfad“ an.

Die .htaccess kommt in genau das Verzeichnis, das geschützt werden soll – sie wirkt automatisch auch auf alle Unterverzeichnisse. Die .htpasswd legen Sie am besten außerhalb des öffentlich erreichbaren Web-Ordners ab, eine Ebene über httpdocs, htdocs oder public_html. Falls Ihr Hoster das nicht erlaubt, ist es kein Beinbruch: Apache blockiert den direkten Abruf von Dateien, die mit .ht beginnen, in der Standardkonfiguration ohnehin.

Keine Panik – fast immer steckt einer von drei Klassikern dahinter: ein Tippfehler in der .htaccess, ein falscher Pfad bei AuthUserFile oder eine Direktive, die der Hoster schlicht nicht erlaubt. Erste Hilfe: die .htaccess per FTP umbenennen (z. B. in htaccess.txt) – läuft die Seite wieder, liegt es definitiv an der Datei. Dann Pfad kontrollieren, Datei erneut aus dem Baukasten erzeugen und Stück für Stück testen. Ein Blick ins Error-Log des Hosters nennt die Ursache meist beim Namen.

Dann ignoriert der Server Ihre .htaccess vermutlich komplett. Bei eigenem Server/VPS muss im vHost AllowOverride AuthConfig (oder All) gesetzt sein – Standard ist oft None. Beim Shared Hosting ist .htaccess-Unterstützung fast immer aktiv; prüfen Sie dann eher, ob die Datei wirklich .htaccess heißt (mit Punkt, ohne Endung) und im richtigen Verzeichnis liegt. Manche FTP-Programme blenden Punkt-Dateien übrigens standardmäßig aus.

Ja, mit zwei Unterschieden: nginx liest keine .htaccess-Dateien, der Schutz gehört direkt in die Server-Konfiguration (auth_basic und auth_basic_user_file – die fertigen Zeilen liefert der Baukasten im nginx-Tab). Und: Welche Hash-Verfahren funktionieren, hängt von der crypt-Bibliothek des Systems ab. Auf aktuellen Linux-Distributionen werden bcrypt-Hashes im $2y$-Format anstandslos akzeptiert.

Einfach hier einen neuen Benutzer erzeugen und die neue Zeile ans Ende der bestehenden .htpasswd anhängen – pro Benutzer genau eine Zeile, die Reihenfolge spielt keine Rolle. Alternativ bauen Sie die Datei komplett im Generator zusammen: Bestehende Einträge bleiben in der Vorschau erhalten, bis Sie die Seite schließen. Zum Entfernen eines Benutzers löschen Sie schlicht seine Zeile.

Der Mechanismus selbst ist simpel gestrickt: Der Browser schickt Benutzername und Passwort bei jedem Request mit – lediglich Base64-kodiert, und das ist keine Verschlüsselung, sondern nur eine andere Schreibweise. Ohne HTTPS könnte also jeder Mitlauscher die Zugangsdaten im Klartext abgreifen. Deshalb die klare Ansage: Verzeichnisschutz nur zusammen mit HTTPS einsetzen (dank Let's Encrypt heute bei praktisch jedem Hoster kostenlos dabei). Dann ist Basic Auth für Staging-Umgebungen, interne Bereiche und Kundenvorschauen ein absolut solider, bewährter Schutz.

Aus dem Hash lässt sich das Passwort nicht zurückrechnen – das ist ja gerade der Sinn der Sache. Die Lösung ist zum Glück unspektakulär: neues Passwort hier generieren, die betreffende Zeile in der .htpasswd durch die neue ersetzen, fertig. Es gehen dabei keine Daten verloren, es ändert sich nur der Zugang.

Aus Überzeugung. crypt(3) schneidet Passwörter nach 8 Zeichen ab, ohne Sie zu warnen – der Rest Ihres schönen langen Passworts ist wirkungslos, und geknackt ist so ein Hash in Minuten. Klartext wiederum funktioniert auf Linux-Servern gar nicht erst und wäre bei einem Datei-Leak der Totalschaden. Ein Generator, der Sicherheit verspricht, sollte solche Fallen nicht mit anbieten – auch nicht „für Spezialfälle“.

Für Staging-Seiten, Admin-Bereiche und Downloads für einen begrenzten Kreis: ja, in Kombination mit HTTPS und starken Passwörtern ist das seit Jahrzehnten bewährte Praxis. Für hochsensible Daten (Patientenakten, Finanzdaten u. Ä.) sollte Basic Auth dagegen nur eine von mehreren Schichten sein – etwa zusätzlich zu einem Anwendungs-Login. Und ein Punkt wird gern vergessen: Der Schutz greift nur über den Webserver. Wer FTP-Zugang zum Verzeichnis hat, liest die Dateien trotzdem.