Skip to content

htpasswd-generator — bcrypt, Apache MD5 (apr1) & Basic Auth

Genereer htpasswd-vermeldingen met bcrypt, Apache MD5 (apr1), SHA-1 en meer. Krijg direct kopieerbare Apache-, nginx- en Docker-configuratie. 100% in je browser — niets wordt geüpload.

Geen tracking Draait in je browser Gratis
100% in je browser — wachtwoorden verlaten je apparaat nooit.
Server
bcrypt cost: 12
htpasswd-vermelding
Authorization-header
 
Bestaande hash verifiëren
Gecontroleerd op hashcorrectheid en naleving van Basic Auth-standaarden — Go Tools Engineering Team · Jun 4, 2026

Wat is een htpasswd-bestand?

Een .htpasswd-bestand slaat de referenties op die worden gebruikt door HTTP Basic Authentication. Elke regel is een enkel gebruikersnaam:hash-paar, waarbij de hash een eenrichtingsdigest van het wachtwoord is — de leesbare tekst wordt nooit opgeslagen. Webservers lezen dit bestand om te bepalen wie toegang heeft tot een beschermde URL. Bij Apache verwijst een .htaccess-bestand (of een <Directory>-blok) naar het .htpasswd-bestand en vraagt de browser om een gebruikersnaam en wachtwoord voordat de pagina wordt weergegeven.

Het hash-formaat hangt af van het gebruikte algoritme. Apache's htpasswd-tool kan er meerdere genereren: bcrypt (regels die beginnen met $2y$) is het sterkst en wordt aanbevolen voor Apache, Docker Registry en Caddy; apr1 (Apache MD5, beginnend met $apr1$) is het meest overdraagbaar en de veilige standaard voor nginx; SHA-1 (beginnend met {SHA}) is niet gezouten en wordt als onveilig beschouwd; crypt (traditionele DES) is verouderd en knipt wachtwoorden af na 8 tekens; en plain slaat het wachtwoord op als leesbare tekst, wat nooit in productie mag worden gebruikt.

Deze generator werkt volledig in je browser — geen gebruikersnaam, wachtwoord of hash wordt ooit geüpload. Als je een sterk wachtwoord nodig hebt voor je vermelding, gebruik dan onze Willekeurig wachtwoord-generator. Om de Authorization: Basic-header handmatig samen te stellen, is de referentie gewoon base64(user:password), die je kunt maken met onze Base64-encoder. En zodra je eindpunt beveiligd is, test je het vanaf de opdrachtregel met onze cURL Command Builder.

# Apache htpasswd CLI equivalents (apache2-utils / httpd-tools)

# bcrypt entry, printed to stdout (recommended; -B = bcrypt, -n = no file, -b = password on CLI)
htpasswd -Bbn admin 's3cret'
# → admin:$2y$10$N9qo8uLOickgx2ZMRZoMye...

# apr1 (Apache MD5) entry, portable for nginx — no apache2-utils needed
printf "admin:$(openssl passwd -apr1 's3cret')\n"
# → admin:$apr1$k3l4Hj9.$qN8...

# Append a user to an existing file from the shell
htpasswd -B /etc/apache2/.htpasswd alice

# Note: nginx delegates bcrypt to the system crypt(); on Alpine/musl or old
# glibc that fails — prefer apr1 for nginx to stay portable.

Belangrijkste functies

Meerdere hash-algoritmen

Genereer bcrypt ($2y$)-, apr1/Apache MD5 ($apr1$)- en SHA-1 ({SHA})-vermeldingen — plus een plain-optie (leesbare tekst) voor testdoeleinden. Elk formaat dat dit ondersteunt, gebruikt een nieuw cryptografisch salt.

Genereren én verifiëren

Maak nieuwe vermeldingen aan of verifieer bestaande. Plak een opgeslagen user:hash-regel en een kandidaatwachtwoord om direct te controleren of ze overeenkomen — handig bij het debuggen van een 401 in productie.

Kies per server

Selecteer Apache, nginx, Docker of Caddy en het juiste algoritme wordt automatisch gekozen — bcrypt waar ondersteund, apr1 voor nginx-portabiliteit — zodat je stille crypt()-fouten vermijdt.

Direct kopieerbare configuratieblokken

Ontvang zes kant-en-klare configuratiefragmenten — Apache .htaccess, nginx auth_basic, Docker, Kubernetes ingress-nginx, Caddy en Traefik — al gekoppeld aan je gegenereerde .htpasswd-vermelding.

100% client-side

Alle hashing vindt lokaal in je browser plaats via Web Crypto en een meegeleverde bcrypt-implementatie. Geen gebruikersnaam, wachtwoord of hash wordt ooit naar een server verzonden, zodat je productiesleutelgegevens privé kunt genereren.

Voorbeelden

bcrypt-vermelding (aanbevolen)

admin:$2y$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

Een bcrypt-vermelding met een $2y$-prefix en cost 10. Dit is het sterkste en meest overdraagbare formaat — gebruik het voor Apache, Docker Registry, Caddy en Traefik.

apr1-vermelding (portabele nginx)

admin:$apr1$kl3H9j2.$qN8vY7tLp2mZ0xW5cR4fK1

Apache MD5 (apr1) met een salt van 8 tekens na de $apr1$-markering. De veilige standaard voor nginx, waarbij bcrypt-verificatie afhankelijk is van een onbetrouwbare systeem-crypt().

SHA-1-vermelding (verouderd)

admin:{SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=

Een {SHA}-vermelding is de base64 van een ongezouten SHA-1-digest. Apache en nginx accepteren het, maar het is ongezouten en onveilig — alleen opgenomen voor achterwaartse compatibiliteit.

Authorization: Basic-header

Authorization: Basic YWRtaW46czNjcmV0

De client-side referentie voor dezelfde gebruiker: base64('admin:s3cret'). Stuur deze header met curl -H of Postman om te authenticeren zonder een .htpasswd-bestand te schrijven.

Meerdere gebruikers in één .htpasswd-bestand

admin:$2y$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
alice:$2y$10$3bQ8xY7tLp2mZ0xW5cR4fO9vK1jH6sD2nG8aQ5wE3rT7uI4oP1cm
bob:$apr1$mZ0xW5cR$4fK1jH6sD2nG8aQ5wE3rT2

Één gebruikersnaam:hash-regel per gebruiker. Algoritmen mogen in hetzelfde bestand worden gemengd — hier bestaan twee bcrypt-vermeldingen en één apr1-vermelding samen voor drie gebruikers.

Hoe te gebruiken

  1. 1

    Server en algoritme configureren

    Kies je doelserver (Apache, nginx, Docker, Caddy). Het juiste algoritme wordt automatisch geselecteerd — bcrypt voor Apache/Docker/Caddy, apr1 voor portabele nginx — maar je kunt het overschrijven en de bcrypt-cost aanpassen.

  2. 2

    De hash genereren

    Vul een gebruikersnaam en wachtwoord in (of klik op Willekeurig wachtwoord) en klik daarna op Genereren. De hash wordt lokaal berekend met een nieuw willekeurig salt. Genereer het salt opnieuw om een nieuwe vermelding aan te maken.

  3. 3

    De vermelding kopiëren

    Kopieer de user:hash-regel voor je .htpasswd-bestand, kopieer het echo >>-commando voor de shell, of kopieer de Authorization: Basic-header voor curl en Postman.

  4. 4

    De configuratie uitrollen

    Plak het gegenereerde configuratieblok in je Apache .htaccess, nginx-serverblok, Docker-, Kubernetes-ingress-, Caddy- of Traefik-configuratie, verwijs naar je .htpasswd-bestand en herlaad de server.

Veelgebruikte toepassingen

Apache-mapbeveiliging
Vergrendel een map met HTTP Basic Auth via een .htaccess-bestand en een AuthUserFile-instructie. Voeg de bcrypt-vermelding en het gegenereerde Apache-configuratieblok toe om een login te vereisen voor elk pad.
nginx auth_basic
Beveilig een location- of serverblok met auth_basic en auth_basic_user_file. Gebruik het apr1-formaat zodat verificatie betrouwbaar werkt op Alpine, Debian en andere basisimages.
Docker Registry
Een privé Docker Registry accepteert alleen bcrypt-htpasswd-vermeldingen. Genereer een $2y$-regel met htpasswd -Bbn, koppel deze aan de registrycontainer en authenticeer je docker login.
Kubernetes ingress-nginx
Maak een basic-auth-Secret aan op basis van je .htpasswd-bestand en verwijs ernaar met de nginx.ingress.kubernetes.io/auth-type- en auth-secret-annotaties om een ingress-route te beveiligen.
Caddy & Traefik
De basic_auth-instructie van Caddy en de basicauth-middleware van Traefik verwachten beide bcrypt-hashes. Plak de gegenereerde vermelding direct in je Caddyfile of Traefik-labels/dynamische configuratie.
curl & Postman Authorization-header
Sla het bestand over voor snelle tests: kopieer de Authorization: Basic-header om referenties direct te verzenden. Voeg hem toe als curl -H-vlag of als Postman-verzoek om een beveiligd eindpunt te bereiken.

Technische details

bcrypt ($2y$)
Een adaptieve, gezouten hash op basis van het Blowfish-cijfer met een instelbare kostenfactor. Elke vermelding bevat een willekeurig 16-byte salt en de cost, zodat identieke wachtwoorden verschillende hashes produceren. Let op: bcrypt knipt het wachtwoord af na 72 bytes — tekens daarna worden genegeerd.
apr1 (Apache MD5)
Apache's iteratieve, gezouten MD5-variant ($apr1$ + salt van 8 tekens). Het voert 1.000 MD5-rondes uit, wat veel zwakker is dan de adaptieve cost van bcrypt, maar het is native geïmplementeerd door Apache en nginx, waardoor het het meest overdraagbare formaat is op alle platforms en basisimages.
SHA-1 en crypt
SHA-1-vermeldingen ({SHA} + base64-digest) zijn ongezouten, waardoor identieke wachtwoorden identieke hashes opleveren en ze kwetsbaar zijn voor rainbow tables — alleen opgenomen voor achterwaartse compatibiliteit. Traditioneel crypt (DES) is nog zwakker en knipt wachtwoorden stilzwijgend af na 8 tekens.
Salt en iteraties
Salting voorkomt voorberekende (rainbow-table-)aanvallen door elke hash uniek te maken. bcrypt gebruikt een willekeurig 128-bit salt met een instelbare cost; apr1 gebruikt een salt van 8 tekens met 1.000 vaste iteraties. Gebruik Salt opnieuw genereren om een andere geldige hash te maken voor hetzelfde wachtwoord.
Base64 en UTF-8-afhandeling
Wachtwoorden worden gecodeerd als UTF-8-bytes vóór het hashen, zodat niet-ASCII-tekens consistent worden verwerkt. De Authorization: Basic-header is de base64 van de onbewerkte UTF-8-bytes van gebruikersnaam:wachtwoord, overeenkomstig wat servers decoderen aan de ontvangende kant.
Eerlijkheidsnotities en voorbehouden
Gegenereerde hashes worden lokaal berekend en nooit geverifieerd tegen een live server. Gekopieerde vermeldingen en gedownloade .htpasswd-bestanden komen op je klembord en schijf terecht in de vorm van leesbare hash-tekst — behandel ze als geheimen, beperk de bestandsrechten en leeg je klembord na het plakken in productiéconfiguratie.

Aanbevolen werkwijzen

Geef de voorkeur aan bcrypt waar ondersteund
Gebruik bcrypt ($2y$) voor Apache, Docker, Caddy en Traefik — het is gezouten, adaptief en veel sterker dan apr1 of SHA-1. Reserveer apr1 alleen voor nginx wanneer de afhankelijkheid van bcrypt op de systeem-crypt() het onbetrouwbaar maakt.
Sla het bestand op buiten de webroot
Bewaar .htpasswd buiten elke weergegeven map zodat het nooit via HTTP kan worden gedownload. Stel chmod 640 in en maak de webservergebruiker eigenaar, zodat de server het kan lezen maar andere accounts niet.
Serveer altijd via HTTPS
Basic Auth verzendt referenties als reversibele base64 bij elk verzoek. Zonder TLS kan iedereen op het netwerkpad het wachtwoord lezen. Schakel Basic Auth nooit in op gewoon HTTP — beëindig TLS vóór het beveiligde eindpunt.
Gebruik unieke, sterke wachtwoorden
Elk account moet zijn eigen wachtwoord met hoge entropie hebben, nooit hergebruikt voor andere diensten. Genereer er een met onze Willekeurig wachtwoord-generator en sla het op in een wachtwoordbeheerder in plaats van het zelf te bedenken.

Veelgestelde vragen

bcrypt vs apr1 — welke moet ik kiezen?
Gebruik bcrypt voor Apache, Docker Registry, Caddy en Traefik — het is een sterke, gezouten, adaptieve hash en de moderne standaard. Gebruik apr1 (Apache MD5) voor nginx, omdat nginx bcrypt doorgeeft aan de systeem-crypt() en dat mislukt op veel builds, terwijl apr1 intern is geïmplementeerd en overal werkt. Als je de runtime beheerst en weet dat bcrypt wordt ondersteund, is bcrypt altijd de sterkere keuze; apr1 gaat over overdraagbaarheid, niet over beveiliging.
Ondersteunt nginx bcrypt?
Alleen indirect, en niet betrouwbaar. nginx hasht wachtwoorden niet zelf — voor $2y$-vermeldingen delegeert het verificatie aan de crypt()-functie van de C-bibliotheek, dus ondersteuning hangt volledig af van je libc. Alpine's musl en oudere glibc-builds bevatten niet het blowfish (bcrypt)-schema, waardoor authenticatie stilzwijgend mislukt. Gebruik voor portabele nginx-configuraties het apr1-formaat, dat nginx intern op elk platform verifieert.
Hoe los ik de nginx-fout `crypt_r() failed (22: Invalid argument)` op?
Die fout betekent dat nginx probeerde een bcrypt ($2y$)-hash te verifiëren op een libc die het blowfish-schema niet ondersteunt — doorgaans Alpine/musl of een oudere glibc. De oplossing is de vermelding opnieuw genereren als apr1 (Apache MD5) in plaats van bcrypt, wat nginx intern op elk platform verifieert. Je kunt ook overschakelen naar een basisimage waarvan de libc bcrypt-ondersteuning bevat, maar apr1 is de eenvoudigere, portabele oplossing.
Waar moet ik het .htpasswd-bestand opslaan en welke rechten gebruik ik?
Sla het .htpasswd-bestand op buiten de documentroot van de webserver, zodat het nooit als statisch bestand kan worden weergegeven. Een veelgebruikte locatie is /etc/apache2/.htpasswd of /etc/nginx/.htpasswd. Stel de rechten in op 640 (chmod 640) en maak de webservergebruiker eigenaar (bijvoorbeeld www-data of nginx), zodat de server het kan lezen maar andere accounts niet.
Hoe configureer ik Basic Auth in .htaccess of nginx?
Voor Apache genereert dit hulpmiddel een .htaccess-blok met AuthType Basic, AuthName, AuthUserFile verwijzend naar je .htpasswd-pad en Require valid-user. Voor nginx genereert het een location-blok met auth_basic "Restricted"; en auth_basic_user_file /pad/.htpasswd;. Kopieer het configuratieblok dat overeenkomt met je server, pas het bestandspad aan en herlaad — de fragmenten zijn direct te plakken.
Worden mijn wachtwoorden ergens geüpload?
Nee. Elke hash wordt volledig in je browser berekend met JavaScript — geen gebruikersnaam, wachtwoord of gegenereerde hash wordt ooit over het netwerk verzonden. Je kunt dit bevestigen door de Ontwikkelaarstools van je browser te openen (F12 → tabblad Netwerk) tijdens het genereren: er zijn nul uitgaande verzoeken. Niets wordt opgeslagen of geregistreerd op enige server, dus het is veilig om hier echte productiesleutelgegevens te genereren.
Wat is het verschil tussen $2a$, $2b$ en $2y$ bij bcrypt?
Het zijn versieprefixen voor hetzelfde bcrypt-algoritme en produceren equivalente hashes; de verschillen zijn terug te voeren op historische bugfixes in de manier waarop bepaalde implementaties hoge-bit-tekens en tekenreekslengte afhandelden. Apache's htpasswd genereert $2y$. Moderne bcrypt-bibliotheken behandelen $2a$, $2b$ en $2y$ als uitwisselbaar voor verificatie, dus een $2y$-vermelding die hier wordt gegenereerd, valideert correct in Apache, Caddy, Traefik en Docker Registry.
Welke bcrypt-cost moet ik gebruiken?
Cost 12 is de moderne standaard en een goede balans tussen beveiliging en snelheid. De cost is een werkfactor: elke stap verdubbelt de tijd om de hash te berekenen en te verifiëren, wat brute-force-aanvallen vertraagt maar ook latentie toevoegt bij elke aanmelding. Cost 10 is acceptabel voor eindpunten met weinig verkeer of laag risico; 12–14 wordt aanbevolen voor gevoelige toepassingen. Vermijd waarden zo hoog dat legitieme authenticatie merkbaar traag wordt.
htpasswd vs de Authorization: Basic-header — wat is het verschil?
Ze bevinden zich aan tegenovergestelde kanten van dezelfde uitwisseling. Het .htpasswd-bestand bevat de server-side opgeslagen hash — een eenrichtingsdigest die de server gebruikt om referenties te verifiëren. De Authorization: Basic-header is de client-side verzoekreferentie: de letterlijke base64 van gebruikersnaam:wachtwoord die de browser of curl bij elk verzoek verzendt. De server base64-decodeert de header en vergelijkt het wachtwoord daarna met de opgeslagen hash. De een is opslag, de ander is transport.
Ik heb apache2-utils niet geïnstalleerd — hoe genereer ik een htpasswd-vermelding?
Dat heb je niet nodig — dit hulpmiddel genereert geldige bcrypt-, apr1- en SHA-1-vermeldingen volledig in je browser. Als je de opdrachtregel prefereert, is OpenSSL op bijna elk systeem beschikbaar: voer openssl passwd -apr1 uit om een apr1-hash te maken en prefix die met gebruikersnaam: om de regel te vormen. Op Debian/Ubuntu kun je het htpasswd-binaire bestand ook installeren via apt install apache2-utils, of httpd-tools op RHEL/CentOS.
Wat betekenen de htpasswd-vlaggen -B, -Bbn en -bnB?
Elke letter is een onafhankelijke vlag: -B selecteert bcrypt, -n stuurt het resultaat naar stdout in plaats van een bestand te schrijven, en -b neemt het wachtwoord als opdrachtregelargument (in plaats van er om te vragen). De volgorde maakt niet uit, dus -Bbn en -bnB zijn identiek. -Bbn is de gebruikelijke combinatie om een bcrypt-vermelding naar een Docker Registry htpasswd-bestand te sturen.
Waarom vereist Docker Registry bcrypt?
De htpasswd-authenticatie-backend van Docker Registry accepteert alleen bcrypt-vermeldingen; apr1-, SHA-1- en crypt-hashes worden afgewezen en de aanmelding mislukt. Genereer de vermelding met htpasswd -Bbn user password (of gebruik de bcrypt-optie hier), koppel het bestand aan de registrycontainer en verwijs REGISTRY_AUTH_HTPASSWD_PATH ernaar. Combineer dit altijd met TLS, omdat Basic Auth-referenties anders leesbaar zijn tijdens het transport.
Is Basic Auth veilig?
Alleen via HTTPS. HTTP Basic Auth verzendt referenties als base64(gebruikersnaam:wachtwoord) bij elk verzoek, en base64 is reversibele codering — geen versleuteling — dus iedereen die het verkeer kan lezen, kan het wachtwoord direct achterhalen. Via TLS is de header versleuteld tijdens het transport en is Basic Auth acceptabel voor eenvoudige toegangsbeveiliging. Gebruik het nooit op gewoon HTTP en geef de voorkeur aan sterkere schema's voor waardevolle toepassingen.

Gerelateerde tools

Alle tools bekijken →