Perché bcrypt è limitato a 72 caratteri?

Dettagli storici dell'implementazione del codice Blowfish sottostante. Gli input più lunghi vengono troncati. La maggior parte degli utenti non se ne accorge; una passphrase casuale di 16 caratteri è molto al di sotto del limite. Per i sistemi che richiedono una lunghezza della password illimitata, Argon2 non prevede tale restrizione.

Dovrei salare e pepare le mie password?

Salt è necessario (e qualsiasi libreria rispettabile lo fa automaticamente). Pepper è facoltativo ma prezioso per i sistemi ad alta sicurezza. Il compromesso: gestire il peperoncino come segreto a lungo termine al di fuori del database aggiunge complessità operativa. La maggior parte delle app memorizza salt + hash; quelli più grandi immagazzinano sale + hashish + hashish derivato dal pepe.

Argon2 è sempre migliore di bcrypt?

Per i nuovi sistemi, sì. Argon2 è memory-hard (resistente a GPU/ASIC), non ha un limite di 72 caratteri e ha vinto il concorso Password Hashing per buone ragioni. bcrypt è ancora accettabile quando Argon2 non è disponibile o i vincoli organizzativi preferiscono lo standard precedente. Per i sistemi legacy che utilizzano bcrypt con costo ≥ 10, l'urgenza di migrare è bassa.

Quanto tempo dovrebbe essere necessario per eseguire l'hashing di una password?

OWASP suggerisce circa 100-500 ms sull'hardware del server. Più veloce significa più debole contro gli aggressori; più lento inizia a influenzare l'esperienza di accesso legittima. Il numero giusto dipende dal tuo traffico: i servizi ad alto volume scelgono un costo inferiore; i servizi ad alta sicurezza con tassi di accesso bassi possono scegliere valori più alti.

Posso archiviare le password crittografate anziché con hash?

Non. La crittografia è reversibile, il che significa che la chiave di crittografia deve esistere in un punto a cui l'applicazione può accedere. Se il database viene violato, spesso lo è anche la chiave e hai effettivamente archiviato testo in chiaro. Il punto è l'irreversibilità dell'hashing: anche la tua stessa applicazione non può recuperare la password, che è la proprietà di sicurezza.

Spiegazione dell'hashing della password: perché bcrypt, scrypt e Argon2 sono importanti

Memorizzare le password degli utenti è una delle peggiori cose che puoi fare in testo normale e uno degli errori di sicurezza più comuni. La soluzione esiste da decenni (hashing delle password con algoritmi lenti e che richiedono molta memoria), ma la differenza tra implementazioni buone e cattive è enorme e la maggior parte delle violazioni dei dati rivela scelte sbagliate.

Il corpo completo dell'articolo è fornito in inglese di seguito.

Hashing della password è la pratica di archiviare una trasformazione unidirezionale della password di un utente anziché la password stessa. Quando l'utente accede, la stessa trasformazione viene applicata al suo input e confrontata con il valore memorizzato. Se il database archiviato viene violato, l'aggressore dispone di hash, non di password, e il ripristino degli originali dovrebbe essere computazionalmente impossibile.

LQuesta è la teoria. La pratica spazia da "funziona come pubblicizzato" a "potrebbe anche essere stato testo in chiaro", a seconda dell'algoritmo e dei parametri scelti.

Di cosa ha bisogno un buon hash della password

A senso unico. Conoscere l'hash non dovrebbe rivelare nulla di utile sulla password.
Salted. Ogni utente ha un sale casuale unico mescolato nell'hashish. Impedisce le tabelle arcobaleno precalcolate e garantisce che password identiche producano hash diversi.
Slow. Un singolo calcolo hash dovrebbe richiedere una frazione significativa di secondo sull'hardware dell'utente malintenzionato. La forza bruta a miliardi al secondo è ciò che sconfigge gli hash veloci.
Memory-hard. Ogni hash dovrebbe richiedere una RAM significativa, sconfiggendo la parallelizzazione di GPU e ASIC che prospera su una piccola memoria per istanza.
Parametri a prova di futuro. I fattori di costo dovrebbero essere regolabili verso l'alto man mano che l'hardware diventa più veloce.

Le scelte sbagliate

Algoritmi da non utilizzare mai per l'archiviazione delle password:

MD5. Crittografia non corretta dal 2004. Forza bruta con decine di miliardi di hash al secondo sul consumatore hardware.
SHA-1, SHA-256. Hash crittografici veloci progettati per il controllo dell'integrità, non per l'archiviazione delle password. Forza bruta a miliardi al secondo sulle GPU.
Password crittografate. Se riesci a decrittografarle e riportarle in testo normale, può farlo anche un utente malintenzionato che ruba la chiave. L'hashing è la risposta; la crittografia non lo è.
Plaintext. Succede ancora nel 2026. Ogni violazione della password di testo in chiaro è un'ingegneria prevenibile.

Le scelte giuste

LI tre moderni consigliati algoritmi:

bcrypt (1999). Fattore di costo regolabile (cicli di calcolo). Limitato a password da 72 byte. Non richiede molta memoria, quindi le GPU possono attaccarlo in modo efficiente, ma un fattore di costo ragionevole rende comunque gli attacchi costosi. Ampia distribuzione, semplice da usare correttamente.
scrypt (2009). Difficile per la memoria. Costo della memoria, parallelismo e costo della CPU configurabili. Più complesso di bcrypt; a volte configurato in modo errato.
Argon2 (vincitore del concorso Password Hashing 2015). Tre varianti: Argon2d (dipendente dai dati, resistente agli attacchi GPU ma vulnerabile ai canali laterali), Argon2i (indipendente dai dati, resistente ai canali laterali), Argon2id (ibrido: l'impostazione predefinita consigliata). Moderno, ben controllato, la scelta giusta per i nuovi sistemi.

OWASP attualmente consiglia Argon2id con almeno 19 MB di memoria, conteggio iterazioni pari a 2 e parallelismo pari a 1. Per i sistemi in cui Argon2 non è disponibile, bcrypt con costo ≥ 10 o scrypt con parametri appropriati sono fallback accettabili.

Cosa significa "lento" in pratica

Il fattore di costo pari a 10 in bcrypt significa circa 100 ms per hash su hardware moderno. Per un utente legittimo che effettua l'accesso, questo è impercettibile. Per un utente malintenzionato che tenta di forzare 100 milioni di password da un database trapelato, sono 100 milioni × 100 ms = 116 giorni di tempo GPU per passaggio attraverso un elenco di parole ragionevole. In combinazione con un salt univoco per utente, le tabelle arcobaleno di grandi dimensioni sono inutili.

Per un hash veloce come SHA-256 non salato, la stessa operazione richiede alcuni minuti sullo stesso hardware.

Gestione del sale

Salt è per utente, generato da un CSPRNG alla creazione dell'utente
16 byte sono sufficienti (128 bit di casualità)
Salt è memorizzato insieme all'hash, non è segreto: il suo compito è essere univoco, non nascosto
La maggior parte delle librerie di hashing moderne (bcrypt, output Argon2 in formato stringa PHC) raggruppano algoritmo, parametri, salt e hash in un'unica stringa

Pepper: opzionale extra

A pepper è un valore segreto a livello di sito aggiunto all'input hash, archiviato separatamente dal database (in un HSM, un insieme di credenziali delle chiavi o una configurazione dell'app). Se il database viene scaricato ma il pepper no, gli hash sono irrecuperabili anche con l'utente salt, perché l'attaccante non ha il pepper. Pepper è un'utile aggiunta di cintura e bretelle per sistemi di alto valore.

Aggiornamento sicuro degli hash

Quando si modificano i parametri o si esegue la migrazione degli algoritmi, non è possibile eseguire nuovamente l'hash senza la password originale. L'approccio standard:

Ogni record utente memorizza l'algoritmo hash corrente, i parametri, il salt e l'hash.
All'accesso, verifica rispetto all'hash memorizzato con i suoi parametri originali.
Se la verifica ha esito positivo e i parametri non sono aggiornati, esegui nuovamente l'hash con i parametri correnti e aggiorna il record.

Entro pochi mesi dagli utenti attivi, il transizioni del database a nuovi parametri senza forzare la reimpostazione della password.

Cosa significa per gli utenti

Per gli utenti finali, l'effetto pratico: anche quando un database viene violato, una password univoca e complessa (gestita da un password manager) più un buon hashing sul server significano che la password rimane effettivamente segreta. Le password deboli vengono violate anche da database ben sottoposti ad hashing; l'utente è la variabile che uno sviluppatore non può controllare.

Domande frequenti

Perché bcrypt è limitato a 72 caratteri?: Dettagli storici dell'implementazione del codice Blowfish sottostante. Gli input più lunghi vengono troncati. La maggior parte degli utenti non se ne accorge; una passphrase casuale di 16 caratteri è molto al di sotto del limite. Per i sistemi che richiedono una lunghezza della password illimitata, Argon2 non prevede tale restrizione.
Dovrei salare e pepare le mie password?: Salt è necessario (e qualsiasi libreria rispettabile lo fa automaticamente). Pepper è facoltativo ma prezioso per i sistemi ad alta sicurezza. Il compromesso: gestire il peperoncino come segreto a lungo termine al di fuori del database aggiunge complessità operativa. La maggior parte delle app memorizza salt + hash; quelli più grandi immagazzinano sale + hashish + hashish derivato dal pepe.
Argon2 è sempre migliore di bcrypt?: Per i nuovi sistemi, sì. Argon2 è memory-hard (resistente a GPU/ASIC), non ha un limite di 72 caratteri e ha vinto il concorso Password Hashing per buone ragioni. bcrypt è ancora accettabile quando Argon2 non è disponibile o i vincoli organizzativi preferiscono lo standard precedente. Per i sistemi legacy che utilizzano bcrypt con costo ≥ 10, l'urgenza di migrare è bassa.
Quanto tempo dovrebbe essere necessario per eseguire l'hashing di una password?: OWASP suggerisce circa 100-500 ms sull'hardware del server. Più veloce significa più debole contro gli aggressori; più lento inizia a influenzare l'esperienza di accesso legittima. Il numero giusto dipende dal tuo traffico: i servizi ad alto volume scelgono un costo inferiore; i servizi ad alta sicurezza con tassi di accesso bassi possono scegliere valori più alti.
Posso archiviare le password crittografate anziché con hash?: Non. La crittografia è reversibile, il che significa che la chiave di crittografia deve esistere in un punto a cui l'applicazione può accedere. Se il database viene violato, spesso lo è anche la chiave e hai effettivamente archiviato testo in chiaro. Il punto è l'irreversibilità dell'hashing: anche la tua stessa applicazione non può recuperare la password, che è la proprietà di sicurezza.