Vai al contenuto
Password hashing

Genera e verifica hash password bcrypt e Argon2id, nel browser

Due funzioni in un solo strumento. Genera l'hash di una password con bcrypt (formato $2y$) o Argon2id (formato $argon2id$), scegliendo il cost factor e i parametri memory-hard; oppure verifica se una password corrisponde a un hash esistente. Il salt è generato automaticamente a ogni calcolo e il tutto avviene interamente nel browser: la password non viene mai inviata a un server. Pensato per chi implementa autenticazione in PHP, Laravel, Symfony o WordPress e vuole capire davvero cosa produce password_hash() prima di metterlo in produzione.

Genera un hash

Verifica una password

Inserisci una password e un hash esistente: il tool ricalcola localmente e ti dice se corrispondono. Utile per testare il flusso di login prima di scriverlo nel codice.

Come si usa

  1. 1

    Scegli algoritmo e parametri

    Seleziona bcrypt per la massima compatibilità o Argon2id per l'algoritmo memory-hard raccomandato oggi. Per bcrypt imposta il cost factor (default 12); per Argon2id imposta memoria, iterazioni e parallelismo. I default proposti seguono le raccomandazioni OWASP 2026.

  2. 2

    Genera l'hash

    Digita la password e premi Genera hash. Il salt casuale viene creato automaticamente e incorporato nell'output. Lo stesso testo genera un hash diverso a ogni click, ed è corretto così: il salt cambia ogni volta. Il risultato è pronto da incollare in un campo password del tuo database.

  3. 3

    Verifica una corrispondenza

    Nella seconda scheda incolla un hash esistente e la password in chiaro: il tool ricalcola usando il salt e i parametri letti dall'hash e ti dice se combaciano. È esattamente ciò che fa password_verify() lato server, ma qui puoi provarlo senza scrivere codice.

  4. 4

    Porta il risultato in produzione

    Copia l'hash e confrontalo con quello che genera il tuo backend: devono avere lo stesso prefisso e la stessa struttura. In produzione non copiare hash a mano: usa password_hash() / password_verify() in PHP, Hash::make() in Laravel, la libreria nativa del tuo framework. Questo strumento serve a capire, testare e fare debug, non a sostituire il codice di autenticazione.

Perché bcrypt o Argon2 e non MD5 o SHA

La password non lascia il browser. Hashare una password su un servizio online generico è un controsenso di sicurezza: stai inviando una credenziale in chiaro a un terzo. Qui il calcolo avviene interamente nel tab, in JavaScript e WebAssembly, senza alcuna richiesta di rete. Puoi verificarlo aprendo il pannello Network degli strumenti per sviluppatori: digiti una password, generi l'hash, e non parte nessuna richiesta HTTP. Una volta caricata, la pagina funziona anche offline.

Le password non vanno hashate con funzioni veloci. MD5, SHA-1, SHA-256 sono progettate per essere velocissime: una GPU moderna ne calcola miliardi al secondo. Applicata a una password, questa velocità lavora a favore dell'attaccante che ha rubato il database: con un dizionario e una scheda grafica prova miliardi di candidati al secondo. In più, senza salt, hash uguali rivelano password uguali e permettono l'uso di rainbow table precalcolate. bcrypt e Argon2 fanno l'opposto: sono deliberatamente lente e regolabili, così che ogni tentativo costi tempo (e per Argon2 anche memoria) all'attaccante.

Il salt è già dentro l'hash. Un hash bcrypt come $2y$12$R9h/cIPz0gi.URNNX3kh2O... è un pacchetto autoconsistente: $2y$ è la versione, 12 è il cost factor, i 22 caratteri successivi sono il salt (128 bit casuali) e il resto è il digest vero e proprio (184 bit). Per Argon2id l'output $argon2id$v=19$m=19456,t=2,p=1$salt$hash incorpora versione, parametri di memoria/tempo/parallelismo, salt e digest. Non devi memorizzare il salt in una colonna separata: verificare significa rileggere quei parametri dall'hash e ricalcolare. È il motivo per cui password_verify() vuole solo password e hash, e nient'altro.

bcrypt o Argon2id: quale. Per un nuovo progetto la raccomandazione 2026 è Argon2id, che è memory-hard: costringe l'attaccante a usare molta RAM per ogni tentativo, neutralizzando il vantaggio di GPU e ASIC che invece macinano bene bcrypt. bcrypt resta perfettamente valido, è ovunque (PHP, Laravel, Spring, Node) e non ha dipendenze particolari: il suo limite storico è che tronca la password a 72 byte e non è memory-hard. Se il tuo stack supporta Argon2id, preferiscilo; se devi restare compatibile con un ecosistema che parla bcrypt, un cost factor adeguato è ancora una scelta solida.

Uso pratico nei framework

PHP nativo. Dal 5.5 la libreria standard offre password_hash($pwd, PASSWORD_BCRYPT, ['cost' => 12]) e, se compilato con Argon2, password_hash($pwd, PASSWORD_ARGON2ID, ['memory_cost' => 19456, 'time_cost' => 2, 'threads' => 1]). La verifica è sempre password_verify($pwd, $hash). Non concatenare mai salt a mano: password_hash() lo genera con una sorgente sicura. Per aggiornare il cost factor nel tempo usa password_needs_rehash($hash, PASSWORD_DEFAULT) al login: se serve, riesegui l'hash con i parametri nuovi e salvalo.

Laravel. Hash::make($pwd) per generare, Hash::check($pwd, $hash) per verificare, Hash::needsRehash($hash) per l'upgrade. L'algoritmo e i parametri si configurano in config/hashing.php (driver bcrypt o argon2id). Symfony espone lo stesso concetto con il componente PasswordHasher e la configurazione security.yaml (algorithm: auto sceglie il migliore disponibile).

WordPress. Per anni WordPress ha usato phpass (prefisso $P$, key stretching su MD5): funzionale ma datato. Da WordPress 6.8 (2025) i nuovi hash usano bcrypt, con migrazione trasparente al primo login degli utenti esistenti. Se lavori su plugin o migrazioni, usa sempre wp_hash_password() e wp_check_password() invece di reimplementare l'algoritmo. La regola universale, in qualsiasi linguaggio, è la stessa: non scrivere tu la funzione di hashing delle password, usa quella nativa e testala. Riferimento: OWASP Password Storage Cheat Sheet.

Glossario

Termini tecnici usati in questa pagina, spiegati in due righe.

bcrypt #
Funzione di hashing delle password basata sul cifrario Blowfish, presentata da Niels Provos e David Mazières nel 1999. Deliberatamente lenta e con cost factor regolabile. L'output di 60 caratteri incorpora versione, costo e salt. Limite noto: tronca la password oltre i 72 byte. Prefissi comuni: $2a$, $2b$, $2y$ (la variante di PHP).
Argon2 #
Vincitrice della Password Hashing Competition (2015) e standard RFC 9106. Tre varianti: Argon2d (resistente a GPU), Argon2i (resistente ad attacchi side-channel), Argon2id (ibrida, quella da usare). È memory-hard: i parametri sono memoria, iterazioni (tempo) e parallelismo. È la raccomandazione di default per i nuovi sistemi.
Salt #
Valore casuale, univoco per ogni password, mescolato all'input prima dell'hashing. Rende diverso l'hash di due password identiche e vanifica le rainbow table precalcolate. In bcrypt e Argon2 il salt è generato automaticamente e incorporato nell'hash: non va conservato a parte.
Cost factor #
In bcrypt, il parametro (tipicamente 10-14) che fissa il numero di iterazioni interne come 2^cost. Ogni incremento di 1 raddoppia il tempo di calcolo. Serve a mantenere l'hashing abbastanza lento da scoraggiare il brute force, ma abbastanza veloce da non degradare il login.
Work factor #
Termine generico per il parametro che rende costosa una funzione di hashing password: il cost di bcrypt, oppure la terna memoria/iterazioni/parallelismo di Argon2 e scrypt. Va calibrato sull'hardware di produzione e alzato nel tempo, man mano che le CPU diventano più veloci.
Memory-hard #
Proprietà di una funzione (Argon2, scrypt) che richiede molta memoria RAM per essere calcolata, oltre al tempo. Toglie all'attaccante il vantaggio di GPU e ASIC, hardware potentissimo nel calcolo ma limitato nella memoria per singolo core. bcrypt non è memory-hard: è questa la differenza chiave con Argon2id.
Rainbow table #
Tabella precalcolata che associa hash a testi in chiaro, per invertire in fretta hash senza salt. Il salt univoco per password la rende inutile: l'attaccante dovrebbe precalcolare una tabella per ogni salt possibile. È uno dei motivi per cui MD5/SHA senza salt sono inadatti alle password.
password_hash() #
Funzione nativa di PHP (dal 5.5) per generare hash di password sicuri. Accetta l'algoritmo (PASSWORD_BCRYPT, PASSWORD_ARGON2ID) e le opzioni di costo, genera un salt sicuro e restituisce una stringa autoconsistente. Va usata insieme a password_verify() e password_needs_rehash().
phpass #
Portable PHP password hashing framework di Solar Designer, usato storicamente da WordPress, Drupal e phpBB. Nella modalità portabile applica key stretching su MD5 (prefisso $P$): meglio di un MD5 nudo, ma superato da bcrypt e Argon2. WordPress è passato a bcrypt dalla versione 6.8.

Domande frequenti

Le password che inserisco restano nel browser?
Sì, e puoi verificarlo. Apri gli strumenti per sviluppatori (F12), vai sul pannello Network e inizia a registrare: genera o verifica un hash e non vedrai partire nessuna richiesta HTTP. Il calcolo di bcrypt e Argon2 gira in JavaScript e WebAssembly dentro il tab. Nessuna password, nessun hash e nessun parametro lasciano il tuo computer. Dopo il caricamento la pagina funziona anche offline.
Perché non posso usare MD5 o SHA-256 per le password?
Perché sono troppo veloci e non pensati per questo scopo. Una GPU moderna calcola miliardi di hash MD5 o SHA al secondo: applicata a un database rubato, questa velocità permette all'attaccante di provare enormi dizionari di password in poco tempo. In più, senza salt, due utenti con la stessa password producono lo stesso hash e diventano vulnerabili alle rainbow table. bcrypt e Argon2 sono progettate all'opposto: lente, regolabili e con salt automatico.
Cosa è il cost factor e come lo scelgo?
In bcrypt il cost factor è l'esponente che determina il numero di iterazioni: 2^cost. Un cost di 12 significa 4096 iterazioni; passare a 13 raddoppia il tempo. L'idea è tenere l'hashing lento per l'attaccante ma tollerabile al login (indicativamente 200-500 ms sull'hardware di produzione). Nel 2026 un buon punto di partenza per bcrypt è 12, con minimo 10 secondo OWASP. Misura sul tuo server e alza il valore nel tempo.
Meglio bcrypt o Argon2id?
Per un nuovo progetto, Argon2id: è memory-hard, quindi costringe l'attaccante a spendere anche RAM per ogni tentativo e neutralizza il vantaggio delle GPU. bcrypt resta valido, universale e semplice da integrare, ma non è memory-hard e tronca la password a 72 byte. In pratica: se il tuo stack supporta Argon2id, usalo; se devi restare compatibile con un ecosistema bcrypt, un cost factor adeguato è ancora una scelta solida e diffusissima.
Cosa è il salt e devo conservarlo separatamente?
Il salt è un valore casuale unico per ogni password, che rende diverso l'hash anche di password identiche e vanifica le rainbow table. Con bcrypt e Argon2 NON devi conservarlo a parte: è già incorporato nell'hash. Nell'output bcrypt sono i 22 caratteri dopo il cost factor; in Argon2id è il segmento tra i parametri e il digest. La verifica lo rilegge da lì automaticamente.
L'hash è reversibile? Posso risalire alla password?
No. bcrypt e Argon2 sono funzioni a senso unico: dall'hash non si torna alla password. Verificare non significa decifrare, ma ricalcolare l'hash della password candidata usando salt e parametri letti dall'hash memorizzato, e confrontare i due digest. È esattamente ciò che fa questo tool nella scheda di verifica e ciò che fa password_verify() lato server.
Posso incollare qui un hash di produzione per verificarlo?
Su questo strumento sì, perché il calcolo è interamente client-side e offline: nessun dato esce dal browser. In generale, però, non incollare mai coppie password+hash di produzione su servizi online di cui non controlli il codice: staresti inviando credenziali reali a terzi. La regola sicura è verificare solo su strumenti locali o su ambienti che sai essere client-side, come questo.
Perché lo stesso testo genera un hash diverso ogni volta?
Perché il salt è casuale e viene rigenerato a ogni calcolo. È il comportamento corretto e voluto: due hash diversi della stessa password restano entrambi verificabili, perché ciascuno porta con sé il proprio salt. Se ti aspettavi un output deterministico stavi pensando a un hash tipo SHA, che per le password è proprio ciò che va evitato.
Quale cost o quali parametri dovrei usare in produzione?
Per bcrypt: cost 12 come default 2026, minimo 10, calibrato per stare sotto i 500 ms sul tuo hardware. Per Argon2id il minimo OWASP è 19 MiB di memoria, 2 iterazioni e parallelismo 1; se il server ha RAM e CPU, puoi salire (ad esempio 46-64 MiB). L'importante è misurare sulla macchina reale di produzione, non su questo browser, e rivedere i parametri periodicamente.
Come integro bcrypt o Argon2 nel mio codice?
Non reimplementare l'algoritmo: usa la libreria nativa. In PHP password_hash() e password_verify(); in Laravel Hash::make() e Hash::check(); in Symfony il componente PasswordHasher; in Node librerie come bcrypt o argon2. Al login controlla password_needs_rehash() (o l'equivalente) per aggiornare gradualmente il cost factor senza costringere gli utenti a cambiare password.

Chi sviluppa questi strumenti?

Maurizio Fonte, consulente IT senior con oltre 20 anni di esperienza in PHP, Laravel, infrastrutture Linux, cybersecurity e integrazione AI/LLM in azienda. Backend di produzione, modernizzazione di codice legacy, audit di sicurezza, agenti AI e MCP server custom: il lavoro che sta dietro a questi strumenti.

Conosci Maurizio Fonte