kittokit
DE
DEV-TOOL

.htpasswd-Generator: bcrypt 12 mit nginx-Hinweis

Passwort-Hash für Apache und nginx, bcrypt mit Cost-12-Default, Webserver-Toggle gegen falsche Algorithmus-Wahl, Batch-Modus für ganze Teams.

Tool

Eine `.htpasswd`-Zeile in der richtigen Hash-Variante zu erzeugen, ist 2026 eine kleine Kopfschmerz-Quelle: Apache will am liebsten bcrypt, nginx weist bcrypt seit Jahren ab, Legacy-Hoster akzeptieren nur APR1-MD5. Der Generator nimmt dir die Wahl ab, du sagst „Apache“ oder „nginx“, er setzt den passenden Algorithmus-Default und warnt sofort, wenn die Kombination nicht funktioniert.

01: Anleitung

Wie benutzt du dieses Tool?

  1. Webserver wählen, Apache oder nginx. Die Auswahl setzt den Hash-Algorithmus-Default und sperrt inkompatible Optionen.
  2. Benutzername und Passwort eingeben. Der Strength-Meter zeigt Entropie und Heuristik-Warnungen live an.
  3. Bei bcrypt: Cost-Factor wählen (10/12/14). Der Single-Shot-Benchmark misst auf deinem Gerät, wie lange Hashing dauert.
  4. Single- oder Batch-Modus. Batch akzeptiert `user:password` pro Zeile und emittiert einen kompletten `.htpasswd`-Block.
  5. Ergebnis kopieren oder als `.htpasswd` herunterladen. Alles passiert im Browser: kein Server, kein Account.

Was macht der htpasswd-Generator?

Der Generator emittiert Apache-.htpasswd-Zeilen, pure-client, ohne dass dein Passwort den Browser verlässt. Du wählst den Webserver (Apache oder nginx), gibst Benutzer plus Passwort ein, und der Generator setzt den passenden Hash-Algorithmus als Default: bcrypt für Apache, APR1-MD5 für nginx. Wenn du eine inkompatible Kombination versuchst (bcrypt auf nginx), erscheint die Warnung sofort, nicht erst beim Production-Deploy, wenn crypt_r() failed (22) im Error-Log auftaucht.

Vier Hash-Algorithmen sind eingebaut, ausgewählt nach 2026-Sicherheitsstand:

  • bcrypt, OWASP-Default, Cost-Factor 4 / 10 / 12 / 14 wählbar. Single-Shot-Benchmark misst die tatsächliche Hashing-Latenz auf deinem Gerät vor dem Hashen.
  • APR1-MD5, Apache-Legacy + nginx-Kompatibilität. 1000 MD5-Iterationen mit 8-Byte-Salt.
  • SHA-1: {SHA}-Präfix, kein Salt, kein Stretching. Nur als nginx-Fallback wenn APR1 nicht geht; sonst nicht empfohlen.
  • crypt (DES), der ursprüngliche Apache-Standard. Schneidet Passwörter nach 8 Zeichen ab, ist 2026 gegen Wörterbuch-Angriffe trivial. Nur für historische Setups.

Single-Modus und Batch-Modus sind getrennte Tabs. Im Batch fügst du user:password-Zeilen ein und bekommst einen kompletten .htpasswd-Block heraus, mit pro-Eintrag-Cost-Override-Option. Der Strength-Meter zeigt Entropie und Heuristik-Warnungen (Wörterbuch-Treffer, gängige Substitutionen, Tastatur-Walks) live an, während du tippst.

Welcher bcrypt Cost-Factor wird 2026 empfohlen?

bcrypt ist der einzige der vier .htpasswd-Algorithmen, der 2026 noch ohne Vorbehalt empfohlen wird. Der Algorithmus stammt aus 1999, basiert auf der Blowfish-Block-Cipher und nutzt einen adaptiven Cost-Factor, pro Stufe verdoppelt sich die Hashing-Zeit. Das macht bcrypt zukunftssicher: Wenn GPU-Hardware in fünf Jahren doppelt so schnell wird, erhöhst du Cost um eins und das Sicherheits-Level bleibt gleich.

Die OWASP Password Storage Cheat Sheet empfiehlt für 2026 Cost 12 als Minimum. Der Apache-htpasswd-CLI-Default ist immer noch Cost 10, das war 2014 angemessen, ist heute zu schwach. Cost 14 ist konservativer (~1,5 s pro Hash), aber für Login-Workflows spürbar langsam.

Der Generator misst die tatsächliche Hashing-Zeit auf deinem Gerät, bevor du das endgültige Passwort hashst. Du siehst: „Cost 12 = 287 ms auf diesem Browser”. Damit kannst du Cost-Factor nach Latenz statt nach Bauchgefühl wählen. Auf langsamen Mobile-Browsern reicht Cost 11; auf modernen Desktops ist Cost 13 oft noch flott. Voreinstellungen: 4 (Demos), 10 (Apache-CLI), 12 (OWASP), 14 (konservativ).

Welcher Algorithmus passt zu Apache oder nginx?

Apache mod_auth_basic plus mod_authn_file akzeptieren alle vier Algorithmen einwandfrei, die empfohlene Wahl ist bcrypt. Der Generator setzt das automatisch, wenn du oben „Apache” auswählst. Die .htaccess daneben lautet:

AuthType Basic
AuthName "Protected"
AuthUserFile /pfad/zu/.htpasswd
Require valid-user

Den passenden Block kannst du parallel mit dem .htaccess-Generator bauen, dort gibt es eine HTTP-Basic-Auth-Regel mit Realm und Pfad-Feld.

nginx ist anders. auth_basic_user_file ruft die System-crypt()-Funktion auf und akzeptiert nur Hashes, die crypt() versteht: APR1-MD5 ($apr1$), SHA-1 ({SHA}), DES-crypt und Plain-Text (das solltest du natürlich nie nutzen). bcrypt wird abgelehnt, der Generator schaltet beim Webserver- Toggle automatisch um und macht bcrypt deaktivierbar. Wer auf nginx trotzdem bcrypt-Verifikation will, nutzt OpenResty mit Lua-Modul oder ein dediziertes Auth-Plugin, beides aber außerhalb der Basic-Auth-Standard-Direktive.

Warum ist APR1-MD5 veraltet und wie migriert man?

APR1-MD5 hat eine merkwürdige Doppel-Rolle: Auf Apache veraltet, auf nginx Standard. Der Algorithmus nutzt 1000 MD5-Iterationen mit 8-Byte-Salt, 2010 noch ausreichend, 2026 in unter einer Sekunde mit GPU-Brute-Force durchbrechbar. Wer eine Apache-Installation neu aufsetzt, sollte nie zu APR1 greifen; wer eine bestehende APR1-.htpasswd migriert, ersetzt die Zeilen schrittweise durch bcrypt-Versionen.

Migrationsschritte:

  1. Neue bcrypt-Hashes pro Benutzer generieren (Generator-Batch-Modus).
  2. Alte APR1-Zeilen aus .htpasswd löschen, neue bcrypt-Zeilen einfügen.
  3. .htaccess neu laden (Apache-Reload reicht, kein Restart).
  4. Login einmal pro Benutzer testen, Apache verifiziert beide Formate parallel, der Switch ist transparent.

Für nginx-Setups ist die Migration komplizierter, weil bcrypt nicht akzeptiert wird. Drei Pfade: (a) APR1 behalten und Passwörter regelmäßig rotieren, (b) auf OpenResty + Lua-Auth-Modul umsteigen, (c) Basic-Auth komplett durch ein modernes Auth-System (OAuth2-Proxy, Authelia, Cloudflare Access) ersetzen. Variante (c) ist für 2026 die langfristig richtige Antwort, Basic-Auth war nie als Production-Auth gedacht.

Wie verlässt das Passwort niemals den Browser?

Dieses Passwort sieht niemand außer dir. Der Generator hat keinen Server-Endpunkt für Hashing, keinen Telemetrie-Ping, keinen Cookie, keinen Account. Die einzige Web-Crypto-API-Nutzung ist crypto.getRandomValues für Salt-Bytes, das passiert im Browser, ohne Netzwerk-Aufruf. Der bcrypt-Algorithmus ist als pure-JS-Implementation eingebaut; APR1, SHA-1 und crypt ebenfalls.

So überprüfst du das selbst:

  1. Tool öffnen, Browser-DevTools (F12).
  2. Tab „Netzwerk” / „Network” wählen, Filter auf „Alle”.
  3. Passwort eingeben, Hash erzeugen.
  4. Im Netzwerk-Tab erscheint kein einziger Request während des Hashings: kein POST, kein WebSocket, nichts.

Das Form-Element trägt kein action-Attribut, die Inputs haben autocomplete=\"new-password\" damit dein Browser den Klartext nicht in seinen Form-History speichert. Wenn du das Tab schließt, ist das Passwort weg, der Generator persistiert nichts in localStorage oder sessionStorage. Wer einen Audit braucht: Der Source-Code ist auf GitHub einsehbar und der Lint blockt jeden fetch-Aufruf in diesem Tool-Pfad.

Wie nutze ich den Batch-Modus für Team-Setups?

Der Batch-Modus löst das DevOps-Team-Setup-Szenario: Zehn Entwickler brauchen Zugriff auf eine Staging-Umgebung, jeder mit eigenem Passwort. Du fügst zehn user:password-Zeilen in das Batch-Feld ein, wählst Algorithmus plus Cost-Factor, und bekommst eine komplette .htpasswd-Datei heraus, ein Hash pro Zeile, bereit zum Hochladen auf den Server.

Der Strength-Meter läuft pro Eintrag mit, du siehst sofort, wer ein schwaches Passwort genommen hat. Optional: Pro-Eintrag-Cost-Override, Admin-Konten bekommen Cost 14, Service-Accounts Cost 12. Der Download-Knopf liefert die Datei direkt im richtigen Format. Kombiniert mit dem .htaccess-Generator baust du die komplette HTTP-Basic-Auth-Konfiguration in zwei Tab-Wechseln auf, .htaccess plus .htpasswd, beide pure-client erzeugt.

Was ist absichtlich nicht gebaut?

  • Keine Passwort-Vorschläge, Passwort-Generierung gehört in den dedizierten Passwort-Generator, nicht in einen Hash-Emitter. Eine Mischung beider Funktionen würde Vertrauen kosten („sieht der Generator mein Passwort?“-FAQ).
  • Kein Hash-Cracking: Der Generator emittiert, er bricht nicht. Wer einen verlorenen Hash zurückrechnen will, nutzt John the Ripper oder hashcat lokal, kein Browser-Tool kann das in vernünftiger Zeit.
  • Keine SSO-/OAuth-Integration, HTTP-Basic-Auth ist ein eigenes Auth-Schema. Für moderne Auth nutzt man OIDC-Provider, nicht .htpasswd. Der Generator dient genau dem klassischen Basic-Auth-Use-Case.
  • Keine Argon2-Variante, Apache htpasswd unterstützt Argon2 nicht. Wer Argon2 will, konfiguriert ein dediziertes Auth-Modul oder steigt auf Application-Layer-Auth um.

Wo finde ich mehr Details?

Zuletzt aktualisiert:

Das könnte dir auch gefallen