Eine htpasswd-Datei ist, womit Apache und nginx ein Verzeichnis mit Benutzername und Passwort schützen, und jede Zeile darin besteht aus einem Benutzernamen, einem Doppelpunkt und einem Passwort-Hash. Der Hash ist der entscheidende Teil: Die Datei liegt meist im Verzeichnis der Website selbst, alles Umkehrbare darin wäre also überhaupt kein Schutz. Erzeugt wird ein bcrypt-Eintrag — genau das, was der Befehl htpasswd mit der Option -B schreibt.
Der Kostenwert ist auf 10 festgelegt, den Standard von Apache, und es gibt hier keine Einstellung dafür. Die Bibliothek gibt die Kennung $2a$ aus, und das Präfix wird auf $2y$ umgeschrieben — derselbe Algorithmus. Die neuere Kennung wurde eingeführt, um Implementierungen zu markieren, die frei von einem alten Fehler sind, den diese nie hatte, und $2y$ ist das, was eine Administratorin in der Datei erwartet.
Die Datei richtig erzeugen
-
Ein Benutzername darf keinen Doppelpunkt enthalten:
Er ist das Trennzeichen der Felder, ein Doppelpunkt erzeugt also eine Zeile, die nicht gelesen werden kann. Sie wird hier abgelehnt statt geschrieben.
-
Legen Sie die Datei nach Möglichkeit außerhalb des Web-Roots ab:
Auch gehasht ist eine Passwortdatei nichts, was ausgeliefert werden sollte. Muss sie innerhalb liegen, konfigurieren Sie den Server so, dass er Anfragen darauf ablehnt.
-
Bcrypt liest nur die ersten 72 Bytes:
Ein längeres Passwort wird stillschweigend abgeschnitten, es wird hier also abgelehnt, statt einen Eintrag zu erzeugen, der schwächer ist als er wirkt.
-
Basic Authentication sendet das Passwort bei jeder Anfrage:
Geschützt wird es allein durch die Verbindung, dies gehört also hinter HTTPS und sonst nirgendwohin.
A real hash, not something that merely looks encoded
Every line of an htpasswd file is a username, a colon, and a password hash, and the hash is the part that actually matters — the file itself usually sits inside the site's own directory, so anything reversible written there offers no protection at all. Base64 is sometimes mistaken for a hash because the output looks similarly unreadable, but it is only an encoding: it reverses in a single step, and a password stored that way is effectively stored in the clear. The [msm_tool slug="htpasswd-generator"] produces a genuine bcrypt entry, the same format the `htpasswd` command itself writes with its `-B` option.
The cost is fixed at ten
There is no cost control here; every entry is generated at cost 10, which is Apache's own default. Anyone who wants a different cost factor for a different purpose has the dedicated bcrypt tool, which exposes that control directly — this one is built specifically to produce what an `.htpasswd` file expects, not a general-purpose hash.
Why the hash starts with $2y$ rather than $2a$
Both identifiers name the same algorithm. The newer `$2y$` prefix exists to mark implementations that are free of an old sign-extension bug in certain non-ASCII passwords — a bug this implementation never had — and it is rewritten to that prefix regardless, because `$2y$` is what Apache writes itself and what an administrator opening the file expects to see.
A colon in the username breaks the file
The colon is the field separator between username and hash, so a username containing one would produce a line the file format cannot parse correctly. That case is refused outright rather than written out and left to fail quietly later.
Where the file should actually live
Placing `.htpasswd` outside the web root is the safer choice wherever the hosting setup allows it, since even a properly hashed password file is not something meant to be served to a browser. Where it has to sit inside the web root, the server needs an explicit rule blocking direct requests for it — the file being hashed does not make serving it harmless.
Basic authentication needs HTTPS, not just a hash
Basic authentication sends the password on every single request, protected by nothing but the connection it travels over. A carefully generated hash in the file does not change that; the credential is only as safe as the HTTPS in front of it.