Generatore Bcrypt Online — Gratuito, 100% Lato Client, Senza Registrazione
Genera e verifica hash bcrypt interamente nel browser — nessun server coinvolto, nessun dato registrato. Tutto il processing avviene localmente con bcryptjs, un'implementazione bcrypt in JavaScript puro. Apri DevTools, osserva la scheda Network completamente vuota e verificalo tu stesso: la tua password non lascia mai il tuo computer.
Questo strumento va oltre il semplice flusso genera-e-verifica. Misura il tempo di hashing reale sul tuo hardware per ogni fattore di costo, analizza qualsiasi hash bcrypt esistente per comprenderne la struttura, e copia codice pronto all'uso per otto linguaggi di programmazione.
Come Usare il Generatore Bcrypt
Ottenere un hash bcrypt da una password richiede meno di cinque secondi:
- Incolla o digita la tua password nel campo "Input Password" — il badge "CLIENT-SIDE SECURE" conferma che non verrà effettuata alcuna richiesta di rete.
- Regola il fattore di costo con lo slider (4–18). Il costo 12 è il valore predefinito raccomandato da OWASP; valori più alti aumentano la sicurezza ma anche il tempo di hashing.
- Clicca su "Generate Bcrypt Hash" — l'hash appare immediatamente, insieme al tempo esatto impiegato sul tuo dispositivo attuale.
- Copia l'hash con il pulsante di copia o premi
Shift+Inviofuori dai campi di input.
Per verificare una password contro un hash esistente, passa alla scheda Verify Hash, inserisci entrambi i valori e clicca su "Verify Match".
Esempi di Hash Bcrypt
Bcrypt produce sempre una stringa di esattamente 60 caratteri. A causa del salt casuale, la stessa password hasheata due volte produrrà sempre hash diversi — ma entrambi verificheranno correttamente la password originale.
Esempio — fattore di costo 12 (default OWASP):
Input: lamiapasswordsegreta
Output: $2b$12$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa
Esempio — stessa password, hash diversi:
Input: lamiapasswordsegreta (hasheata due volte con costo 12)
Hash 1: $2b$12$nOUIs5kJ7naTuTFkBy1veu...
Hash 2: $2b$12$aBcDeFgHiJkLmNoPqRsTuv... ← salt diverso, entrambi validi
Caso limite — il limite di 72 byte:
Input 1: [72 caratteri 'a']
Input 2: [100 caratteri 'a']
Risultato: entrambi producono hash equivalenti — i byte oltre il 72° vengono ignorati silenziosamente
Formato dell'Hash Bcrypt — Il Significato di Ogni Parte
Ogni hash bcrypt ha esattamente la stessa struttura. Per $2b$12$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa:
| Segmento | Valore | Significato |
|---|---|---|
| Versione | $2b$ |
Versione dell'algoritmo — usa sempre $2b$ nelle nuove implementazioni |
| Costo | 12 |
2¹² = 4.096 iterazioni |
| Salt | nOUIs5kJ7naTuTFkBy1veu |
22 char, salt casuale da 128 bit codificato in base64 |
| Hash | K0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa |
31 char, il checksum effettivo dell'input |
I prefissi di versione: $2a$ è la spec originale con un bug nei caratteri a 8 bit; $2b$ è lo standard corretto attuale; $2y$ è la variante PHP equivalente a $2b$. Usa sempre $2b$ nel codice nuovo.
Cos'è Bcrypt e Perché È Importante?
Bcrypt è una funzione di hashing delle password progettata da Niels Provos e David Mazières nel 1999, basata sul cifrario Blowfish. A differenza di MD5 o SHA-256 — che sono funzioni veloci di uso generale — bcrypt è intenzionalmente lento. Il suo fattore di costo è regolabile, il che significa che è possibile aumentare il lavoro computazionale man mano che l'hardware migliora, mantenendo gli attacchi di forza bruta economicamente non redditizi.
Bcrypt genera e incorpora automaticamente un salt casuale unico in ogni hash. Questo previene gli attacchi con rainbow table, dove gli attaccanti usano tabelle precompute per invertire hash comuni. Anche se due utenti hanno password identiche, i loro hash bcrypt saranno diversi.
Casi d'Uso Comuni
- Sistemi di autenticazione utenti: Hash delle password prima di archiviarle nel database. Al login,
bcrypt.compare()esegue lo stesso algoritmo con il salt memorizzato e conferma la corrispondenza in tempo costante, prevenendo gli attacchi di timing. - Migrazione da algoritmi più deboli: Re-hash progressivo delle password da MD5/SHA-1 a bcrypt. Al login riuscito con il vecchio hash, verificare la password e sostituire immediatamente l'hash memorizzato con uno bcrypt.
- Calibrazione del fattore di costo: Eseguire il benchmark locale sull'hardware del server di produzione per trovare il fattore di costo più alto che mantiene la latenza di login sotto la soglia UX (tipicamente 300ms–1s).
- Audit di sicurezza: Incollare un hash esistente nel parser per verificare che usi
$2b$, confermare che il fattore di costo soddisfi i minimi OWASP, e controllare le lunghezze corrette di salt e hash.
Errori Comuni con Bcrypt
- Usare costo 4–8 in produzione: Questi valori completano in meno di 1ms e non offrono resistenza significativa alla forza bruta. Il costo 4 esiste solo per i test unitari. Usa costo 10 come minimo assoluto, costo 12 come valore predefinito.
- Hashare hash già hashati: Eseguire bcrypt su un hash bcrypt produce una stringa doppiamente codificata che non potrà mai essere verificata. Hashare sempre solo il testo in chiaro originale.
- Ignorare il limite di 72 byte: Bcrypt elabora solo i primi 72 byte di qualsiasi input. Se la tua applicazione consente password più lunghe di ~72 caratteri ASCII, considera il pre-hashing con SHA-256 prima di bcrypt, o passa ad Argon2id che non ha questo limite.
- Memorizzare il salt separatamente: Bcrypt incorpora il salt nella stringa di 60 caratteri. Non è necessaria una colonna
saltseparata. Memorizza solo l'hash bcrypt completo.
Domande Frequenti
Quale fattore di costo usare per bcrypt?
OWASP raccomanda il fattore di costo 12 come punto di partenza, mirando a circa 250ms per hash su hardware moderno. Il valore corretto dipende dal tuo server specifico — usa il benchmark locale su questa pagina per misurare il tempo reale, poi scegli il fattore più alto che mantiene la latenza di autenticazione sotto la tua soglia UX (tipicamente 300ms–1s).
Un hash bcrypt può essere invertito o decifrato?
No. Bcrypt è una funzione unidirezionale — non esiste un metodo matematico per derivare la password originale da un hash. L'unico approccio è la forza bruta: indovinare password, hasharne ognuna con il salt memorizzato e confrontare. L'elevato numero di iterazioni rende questo computazionalmente costoso.
Qual è la differenza tra i prefissi $2a$ e $2b$ di bcrypt?
$2a$ è la specifica originale del 1999. Alcune implementazioni avevano un bug nei casi limite con password contenenti caratteri sopra l'intervallo a 8 bit. $2b$ corregge quel bug ed è lo standard attuale. $2y$ è una variante PHP matematicamente equivalente a $2b$. Per qualsiasi nuova implementazione, usa $2b$.
Bcrypt supporta password più lunghe di 72 caratteri?
Bcrypt elabora solo i primi 72 byte di qualsiasi input. I caratteri oltre i 72 byte vengono ignorati silenziosamente. Se gli utenti possono creare password più lunghe di ~70 caratteri, considera il pre-hashing con SHA-256 prima di bcrypt, o passa ad Argon2id che non ha limiti di lunghezza.
Dovrei usare bcrypt o Argon2id per un nuovo progetto?
OWASP ora raccomanda Argon2id come prima scelta per i nuovi sistemi — è memory-hard (più resistente agli attacchi GPU e ASIC), non ha limiti di lunghezza della password, e ha vinto il Password Hashing Competition nel 2015. Bcrypt rimane una scelta solida e consolidata per i sistemi che già lo utilizzano, con fattore di costo 12 o superiore.
Risorse
- OWASP Password Storage Cheat Sheet — Guida autorevole sugli algoritmi raccomandati, fattori di costo e strategie di migrazione.
- bcryptjs su GitHub — La libreria JavaScript pura che alimenta questo strumento — nessuna dipendenza nativa, funziona in qualsiasi browser.
