Skip to content

Generatore htpasswd — bcrypt, Apache MD5 (apr1) e Basic Auth

Genera voci htpasswd con bcrypt, Apache MD5 (apr1), SHA-1 e altro. Ottieni configurazioni pronte per Apache, nginx e Docker. 100% nel browser — nessun caricamento.

Niente tracciamento Funziona nel browser Gratuito
100% nel tuo browser — le password non lasciano mai il tuo dispositivo.
Server
Costo bcrypt: 12
Voce htpasswd
Intestazione Authorization
 
Verifica un hash esistente
Verificato per la correttezza degli hash e la conformità agli standard Basic Auth — Go Tools Engineering Team · Jun 4, 2026

Cos'è un file htpasswd?

Un file .htpasswd archivia le credenziali utilizzate dall'autenticazione HTTP Basic. Ogni riga è una singola coppia nomeutente:hash, dove l'hash è un digest a senso unico della password — il testo in chiaro non viene mai memorizzato. I server web leggono questo file per decidere chi può accedere a un URL protetto. Su Apache, un file .htaccess (o un blocco <Directory>) fa riferimento al file .htpasswd e chiede al browser nome utente e password prima di servire la pagina.

Il formato dell'hash dipende dall'algoritmo che lo ha prodotto. Lo strumento htpasswd di Apache può generare diversi formati: bcrypt (righe che iniziano con $2y$) è il più robusto ed è consigliato per Apache, Docker Registry e Caddy; apr1 (Apache MD5, che inizia con $apr1$) è il più portabile e il valore predefinito sicuro per nginx; SHA-1 (che inizia con {SHA}) non usa salt ed è considerato non sicuro; crypt (DES tradizionale) è legacy e tronca la password a 8 caratteri; e plain archivia la password in chiaro, il che non dovrebbe mai essere usato in produzione.

Questo generatore funziona interamente nel tuo browser — nessun nome utente, password o hash viene mai caricato. Se hai bisogno di una password robusta per la tua voce, usa il nostro Generatore di Password Casuali. Per costruire manualmente l'intestazione Authorization: Basic, la credenziale è semplicemente base64(utente:password), che puoi produrre con il nostro Codificatore Base64. E una volta protetto il tuo endpoint, testalo dalla riga di comando con il nostro Costruttore di Comandi cURL.

# 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.

Funzionalità Principali

Algoritmi di Hash Multipli

Genera voci bcrypt ($2y$), apr1 / Apache MD5 ($apr1$) e SHA-1 ({SHA}) — più un'opzione plain (testo in chiaro) per i test. Ognuna usa un nuovo salt crittografico dove il formato lo supporta.

Genera e Verifica

Crea nuove voci o verifica quelle esistenti. Incolla una riga user:hash memorizzata e una password candidata per confermare istantaneamente se corrispondono — utile per fare debug di un 401 in produzione.

Scegli per Server

Scegli Apache, nginx, Docker o Caddy e l'algoritmo corretto viene selezionato automaticamente — bcrypt dove è supportato, apr1 per la portabilità nginx — così eviti silenziosi errori crypt().

Blocchi di Configurazione Pronti da Incollare

Ottieni sei snippet di configurazione pronti da copiare — Apache .htaccess, nginx auth_basic, Docker, Kubernetes ingress-nginx, Caddy e Traefik — già collegati alla tua voce .htpasswd generata.

100% Lato Client

Tutto l'hashing avviene localmente nel tuo browser tramite Web Crypto e un'implementazione bcrypt inclusa. Nessun nome utente, password o hash viene mai inviato a un server, quindi puoi generare credenziali di produzione in modo privato.

Esempi

Voce bcrypt (consigliata)

admin:$2y$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

Una voce bcrypt con prefisso $2y$ e costo 10. È il formato più robusto e portabile — usalo per Apache, Docker Registry, Caddy e Traefik.

Voce apr1 (nginx portabile)

admin:$apr1$kl3H9j2.$qN8vY7tLp2mZ0xW5cR4fK1

Apache MD5 (apr1) con un salt di 8 caratteri dopo il marcatore $apr1$. Il valore predefinito sicuro per nginx, dove la verifica bcrypt dipende da un crypt() di sistema inaffidabile.

Voce SHA-1 (legacy)

admin:{SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=

Una voce {SHA} è il base64 di un digest SHA-1 senza salt. Apache e nginx la accettano, ma è priva di salt e non sicura — inclusa solo per compatibilità legacy.

Intestazione Authorization: Basic

Authorization: Basic YWRtaW46czNjcmV0

La credenziale lato client per lo stesso utente: base64('admin:s3cret'). Invia questa intestazione con curl -H o Postman per autenticarsi senza scrivere un file .htpasswd.

File .htpasswd multi-utente

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

Una riga nomeutente:hash per utente. Gli algoritmi possono essere mescolati nello stesso file — qui due voci bcrypt e una voce apr1 coesistono per tre utenti.

Come Usare

  1. 1

    Configura Server e Algoritmo

    Scegli il server di destinazione (Apache, nginx, Docker, Caddy). L'algoritmo corretto viene selezionato automaticamente — bcrypt per Apache/Docker/Caddy, apr1 per nginx portabile — ma puoi sovrascriverlo e regolare il costo bcrypt.

  2. 2

    Genera l'Hash

    Inserisci un nome utente e una password (oppure clicca Password casuale), poi clicca Genera. L'hash viene calcolato localmente con un nuovo salt casuale. Rigenera il salt in qualsiasi momento per creare una nuova voce.

  3. 3

    Copia la Voce

    Copia la riga user:hash per il tuo file .htpasswd, copia il comando echo >> per la shell, oppure copia l'intestazione Authorization: Basic per curl e Postman.

  4. 4

    Distribuisci la Configurazione

    Incolla il blocco di configurazione generato nel tuo .htaccess Apache, nel blocco server nginx, nella configurazione Docker, Kubernetes ingress, Caddy o Traefik, puntalo al tuo file .htpasswd e ricarica il server.

Casi d'Uso Comuni

Protezione di Directory Apache
Proteggi una cartella con HTTP Basic Auth usando un file .htaccess e una direttiva AuthUserFile. Inserisci la voce bcrypt e il blocco di configurazione Apache generato per richiedere un login su qualsiasi percorso.
nginx auth_basic
Proteggi un blocco location o server con auth_basic e auth_basic_user_file. Usa il formato apr1 in modo che la verifica funzioni in modo affidabile su Alpine, Debian e altre immagini base.
Docker Registry
Un Docker Registry privato accetta solo voci htpasswd in formato bcrypt. Genera una riga $2y$ con htpasswd -Bbn, montala nel container registry e autentica il tuo docker login.
Kubernetes ingress-nginx
Crea un Secret basic-auth dal tuo file .htpasswd e fai riferimento ad esso con le annotazioni nginx.ingress.kubernetes.io/auth-type e auth-secret per proteggere una route ingress.
Caddy e Traefik
La direttiva basic_auth di Caddy e il middleware basicauth di Traefik si aspettano entrambi hash bcrypt. Incolla la voce generata direttamente nel tuo Caddyfile o nelle etichette/configurazione dinamica di Traefik.
Intestazione Authorization per curl e Postman
Salta il file per i test rapidi: copia l'intestazione Authorization: Basic per inviare le credenziali direttamente. Inseriscila in un flag curl -H o in una richiesta Postman per raggiungere un endpoint protetto.

Dettagli Tecnici

bcrypt ($2y$)
Un hash adattivo con salt basato sul cifrario Blowfish con un fattore di costo regolabile. Ogni voce incorpora un salt casuale di 16 byte e il costo, quindi password identiche producono hash diversi. Nota: bcrypt tronca la password a 72 byte — i caratteri oltre tale limite vengono ignorati.
apr1 (Apache MD5)
La variante MD5 iterata con salt di Apache ($apr1$ + salt di 8 caratteri). Esegue 1.000 round MD5, che è molto più debole del costo adattivo di bcrypt, ma è implementato nativamente da Apache e nginx, rendendolo il formato più portabile tra piattaforme e immagini base.
SHA-1 e crypt
Le voci SHA-1 ({SHA} + digest base64) non usano salt, quindi password identiche producono hash identici e sono vulnerabili agli attacchi rainbow table — incluse solo per compatibilità legacy. Il crypt tradizionale (DES) è ancora più debole e tronca silenziosamente le password a 8 caratteri.
Salt e Iterazioni
Il salt previene gli attacchi precomputati (rainbow table) rendendo ogni hash unico. bcrypt usa un salt casuale a 128 bit con un costo configurabile; apr1 usa un salt di 8 caratteri con 1.000 iterazioni fisse. Usa Rigenera salt per generare un hash valido diverso per la stessa password.
Gestione di Base64 e UTF-8
Le password vengono codificate come byte UTF-8 prima dell'hashing, in modo che i caratteri non ASCII siano gestiti in modo coerente. L'intestazione Authorization: Basic è il base64 dei byte UTF-8 grezzi di nomeutente:password, corrispondente a ciò che i server decodificano sul lato ricevente.
Note di Onestà e Avvertenze
Gli hash generati vengono calcolati localmente e non vengono mai verificati su un server attivo. Le voci copiate e i file .htpasswd scaricati finiscono negli appunti e sul disco in forma di hash in testo — trattali come segreti, limita i permessi dei file e svuota gli appunti dopo averli incollati nella configurazione di produzione.

Best Practice

Preferisci bcrypt Dove Supportato
Usa bcrypt ($2y$) per Apache, Docker, Caddy e Traefik — è con salt, adattivo e molto più robusto di apr1 o SHA-1. Riserva apr1 solo per nginx quando l'affidamento di bcrypt al crypt() di sistema lo rende inaffidabile.
Archivia il File Fuori dalla Web Root
Tieni .htpasswd fuori da qualsiasi directory servita in modo che non possa mai essere scaricato via HTTP. Imposta chmod 640 e assegnane la proprietà all'utente del server web in modo che il server possa leggerlo mentre gli altri account no.
Usa Sempre HTTPS
Basic Auth trasmette le credenziali come base64 reversibile ad ogni richiesta. Senza TLS, chiunque sul percorso di rete può leggere la password. Non abilitare mai Basic Auth su HTTP semplice — termina TLS davanti all'endpoint protetto.
Usa Password Uniche e Robuste
Ogni account dovrebbe avere la propria password ad alta entropia, mai riutilizzata tra i servizi. Generane una con il nostro Generatore di Password Casuali e archiviala in un gestore di password invece di inventarla a mano.

Domande Frequenti

bcrypt o apr1 — quale devo scegliere?
Usa bcrypt per Apache, Docker Registry, Caddy e Traefik — è un hash robusto, con salt e adattivo ed è lo standard moderno. Usa apr1 (Apache MD5) per nginx, perché nginx affida la verifica bcrypt al crypt() di sistema, che fallisce su molte build, mentre apr1 è implementato internamente e funziona ovunque. Se controlli il runtime e sai che bcrypt è supportato, bcrypt è sempre la scelta più robusta; apr1 riguarda la portabilità, non la sicurezza.
nginx supporta bcrypt?
Solo indirettamente e non in modo affidabile. nginx non esegue l'hashing delle password da solo — per le voci $2y$ delega la verifica alla funzione crypt() della libreria C, quindi il supporto dipende interamente dalla libc. Alpine con musl e build glibc più vecchie non includono lo schema blowfish (bcrypt), quindi l'autenticazione fallisce silenziosamente. Per configurazioni nginx portabili, usa invece il formato apr1, che nginx verifica internamente su ogni piattaforma.
Come risolvo l'errore nginx `crypt_r() failed (22: Invalid argument)`?
Quell'errore significa che nginx ha tentato di verificare un hash bcrypt ($2y$) su una libc che non supporta lo schema blowfish — tipicamente Alpine/musl o una glibc più vecchia. La soluzione è rigenerare la voce come apr1 (Apache MD5) invece di bcrypt, che nginx verifica internamente su qualsiasi piattaforma. In alternativa, passa a un'immagine base la cui libc include il supporto bcrypt, ma apr1 è la soluzione più semplice e portabile.
Dove devo mettere il file .htpasswd e con quali permessi?
Archivia il file .htpasswd fuori dalla document root web in modo che non possa mai essere servito come file statico ed esposto. Una posizione comune è /etc/apache2/.htpasswd o /etc/nginx/.htpasswd. Imposta i permessi a 640 (chmod 640) e assegnane la proprietà all'utente con cui gira il server web (ad esempio www-data o nginx), in modo che il server possa leggerlo ma gli altri account no.
Come configuro Basic Auth in .htaccess / nginx?
Per Apache, questo strumento genera un blocco .htaccess con AuthType Basic, AuthName, AuthUserFile che punta al tuo percorso .htpasswd e Require valid-user. Per nginx, genera un blocco location con auth_basic "Restricted"; e auth_basic_user_file /path/.htpasswd;. Copia il blocco di configurazione che corrisponde al tuo server, regola il percorso del file e ricarica — gli snippet sono pronti da incollare.
Le mie password vengono caricate da qualche parte?
No. Ogni hash viene calcolato interamente nel tuo browser usando JavaScript — nessun nome utente, password o hash generato viene mai inviato sulla rete. Puoi confermarlo aprendo gli Strumenti per sviluppatori del browser (F12 → scheda Rete) durante la generazione: ci sono zero richieste in uscita. Nulla viene archiviato o registrato su alcun server, quindi è sicuro generare qui credenziali di produzione reali.
Qual è la differenza tra $2a$, $2b$ e $2y$ in bcrypt?
Sono prefissi di versione per lo stesso algoritmo bcrypt e producono hash equivalenti; le differenze risalgono a correzioni storiche di bug nel modo in cui alcune implementazioni gestivano caratteri ad alto bit e lunghezza delle stringhe. L'htpasswd di Apache emette $2y$. Le moderne librerie bcrypt trattano $2a$, $2b$ e $2y$ come intercambiabili per la verifica, quindi una voce $2y$ generata qui verrà validata correttamente in Apache, Caddy, Traefik e Docker Registry.
Quale costo bcrypt devo usare?
Il costo 12 è il valore predefinito moderno e un buon equilibrio tra sicurezza e velocità. Il costo è un fattore di lavoro: ogni incremento raddoppia il tempo per calcolare e verificare l'hash, il che rallenta gli attacchi a forza bruta ma aggiunge anche latenza a ogni login. Il costo 10 è accettabile per endpoint a basso traffico o basso rischio; 12–14 è consigliato per tutto ciò che è sensibile. Evita di alzarlo così tanto che l'autenticazione legittima diventi notevolmente lenta.
htpasswd vs intestazione Authorization: Basic — qual è la differenza?
Si trovano ai due estremi dello stesso scambio. Il file .htpasswd contiene l'hash memorizzato lato server — un digest a senso unico che il server usa per verificare le credenziali. L'intestazione Authorization: Basic è la credenziale della richiesta lato client: il base64 letterale di nomeutente:password che il browser o curl invia ad ogni richiesta. Il server decodifica il base64 dall'intestazione, poi confronta la password con l'hash memorizzato. Uno è archiviazione, l'altro è trasporto.
Non ho apache2-utils installato — come genero una voce htpasswd?
Non ne hai bisogno — questo strumento genera voci bcrypt, apr1 e SHA-1 valide interamente nel tuo browser. Se preferisci la riga di comando, OpenSSL è presente su quasi ogni sistema: esegui openssl passwd -apr1 per produrre un hash apr1, poi prefissalo con nomeutente: per formare la riga. Su Debian/Ubuntu puoi anche installare il binario htpasswd tramite apt install apache2-utils, o httpd-tools su RHEL/CentOS.
Cosa significano i flag htpasswd -B, -Bbn, -bnB?
Ogni lettera è un flag indipendente: -B seleziona bcrypt, -n stampa il risultato sullo stdout invece di scrivere un file, e -b prende la password come argomento della riga di comando (invece di chiederla). L'ordine non ha importanza, quindi -Bbn e -bnB sono identici. -Bbn è la combinazione comune per reindirizzare una voce bcrypt in un file htpasswd di Docker Registry.
Perché Docker Registry richiede bcrypt?
Il backend di autenticazione htpasswd di Docker Registry accetta solo voci in formato bcrypt; gli hash apr1, SHA-1 e crypt vengono rifiutati e il login fallirà. Genera la voce con htpasswd -Bbn utente password (oppure usa l'opzione bcrypt qui), monta il file nel container registry e punta REGISTRY_AUTH_HTPASSWD_PATH su di esso. Abbina sempre questo a TLS, poiché le credenziali Basic Auth sono altrimenti leggibili in transito.
Basic Auth è sicuro?
Solo su HTTPS. HTTP Basic Auth invia le credenziali come base64(nomeutente:password) ad ogni richiesta, e base64 è una codifica reversibile — non una cifratura — quindi chiunque possa leggere il traffico può recuperare la password istantaneamente. Su TLS l'intestazione è cifrata in transito e Basic Auth è accettabile per una protezione semplice. Non usarlo mai su HTTP semplice e preferisci schemi più robusti per applicazioni ad alto valore.

Strumenti correlati

Vedi tutti gli strumenti →