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.

Läuft lokal im Browser — Passwörter werden niemals hochgeladen, nicht gespeichert, nicht gecacht.

Webserver

Bestimmt sinnvolle Default-Algorithmen und blendet Inkompatibilitäts-Hinweise ein.

Algorithmus

APR1 MD5 ist universell mit Apache und nginx kompatibel. SHA-1 nur für Legacy-Setups. bcrypt und DES crypt sind im Browser-Build nicht verfügbar — für bcrypt das `htpasswd -B` CLI auf dem Server nutzen.

APR1 MD5 is legacy. Apache supports it for backwards compatibility, but bcrypt via the `htpasswd -B` CLI is the modern recommendation.

So funktioniert es
  1. 01

    Text oder Code einfügen

    Füge deinen Inhalt in das Eingabefeld ein oder tippe direkt.

  2. 02

    Automatische Verarbeitung

    Das Tool verarbeitet den Inhalt sofort und zeigt das Ergebnis.

  3. 03

    Ergebnis kopieren

    Kopiere das Ergebnis mit einem Klick in die Zwischenablage.

Datenschutz

Alle Berechnungen laufen direkt in deinem Browser. Keine Daten werden auf Server übertragen.

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