bcrypt vs Argon2: come scegliere le impostazioni di hashing delle password

Quale problema risolve l'hashing delle password

L'hashing delle password permette a un backend di memorizzare una password senza conservare la password stessa. Quando qualcuno si registra, il server applica la password a una funzione unidirezionale e salva il risultato (l'hash). Al login, calcola l'hash della password inserita dall'utente e confronta il risultato con quello salvato.

Un hash non è cifratura. Non esiste un modo per decifrarlo. Questa proprietà unidirezionale è proprio il motivo per cui l'hash viene usato per le password.

Perché non usare un hash normale e veloce come SHA-256? Perché “veloce” è esattamente ciò che gli attaccanti desiderano. Se un database viene rubato, gli attaccanti non indovinano le password provando accessi uno alla volta. Provano offline usando la lista di hash rubati, inviando ipotesi alla massima velocità consentita dall'hardware. Con le GPU, gli hash veloci possono essere testati su scala enorme. Anche con salt unici, un hash veloce è ancora economico da forzare.

Ecco lo scenario realistico di fallimento: una piccola app web perde la tabella utenti in una violazione. L'attaccante ottiene email e hash delle password. Se quegli hash sono stati generati con una funzione veloce, le password comuni e le piccole variazioni cadono rapidamente. Poi l'attaccante prova le stesse password su altri siti (credential stuffing) o le usa per ottenere privilegi più alti all'interno della tua app.

Un buon hash delle password rende costoso l'indovinare. L'obiettivo non è “infrangibile”, ma “troppo lento e costoso per valerne la pena”.

Una configurazione di hashing delle password dovrebbe essere:

• Unidirezionale (verifica, non inversione)
• Lenta per ogni tentativo
• Costosa per hardware parallelo (soprattutto GPU)
• Abbastanza veloce perché i login reali sembrino normali
• Regolabile così puoi aumentare il costo nel tempo

bcrypt e Argon2, in pochi minuti

Quando confronti bcrypt vs Argon2, stai scegliendo come vuoi rallentare l'indovinare le password dopo una fuga di database.

bcrypt è l'opzione più vecchia e ampiamente supportata. È progettato per essere costoso sulla CPU e ha una manopola principale di regolazione: il fattore di costo. È anche “noioso” in modo positivo: facile da trovare nelle librerie, semplice da distribuire e prevedibile.

Argon2 è più recente ed è stato progettato per essere memory-hard. Può forzare ogni tentativo a usare una quantità significativa di RAM, non solo CPU. Questo è importante perché gli attaccanti spesso vincono eseguendo un numero enorme di tentativi in parallelo su GPU o hardware specializzato. La memoria è più difficile e costosa da scalare a quel livello di parallelismo.

Argon2 ha tre varianti:

• Argon2i: enfatizza la resistenza ad alcuni attacchi side-channel
• Argon2d: enfatizza la resistenza alle GPU, con considerazioni diverse sui side-channel
• Argon2id: un mix pratico di entrambi, ed è il default comune per l'hashing delle password

Se il tuo stack supporta Argon2id e puoi regolare la memoria in sicurezza, di solito è la scelta moderna migliore. Se ti serve massima compatibilità con sistemi più vecchi, bcrypt resta una scelta solida se configurato con un fattore di costo sufficientemente alto.

Proprietà di sicurezza che contano di più

La domanda centrale è semplice: se un attaccante ruba il database delle password, quanto è costoso indovinare le password su scala?

Con bcrypt, controlli il costo (work factor). Un costo più alto significa che ogni tentativo richiede più tempo. Questo rallenta gli attaccanti e rallenta anche i tuoi controlli di login, quindi lo si tarerà a un punto che sia fastidioso per gli attaccanti ma ancora accettabile per gli utenti.

Con Argon2id, puoi aggiungere la memory-hardness oltre al costo in tempo. Ogni tentativo richiede tempo CPU e RAM accessibile secondo uno schema specifico. Le GPU sono estremamente veloci in compiti intensivi di calcolo, ma perdono molto del loro vantaggio quando ogni tentativo parallelo necessita di memoria sostanziale.

I salt sono imprescindibili. Un salt unico e casuale per password:

• impedisce che tabelle precalcolate vengano riutilizzate su tutto il database
• garantisce che password identiche non producano hash identici tra utenti

I salt non rendono le password deboli più forti. Proteggono principalmente dopo una fuga di database costringendo gli attaccanti a lavoro reale per ogni utente.

Punti di forza e limiti di bcrypt da conoscere

bcrypt è ancora molto usato, principalmente perché è facile da distribuire ovunque. Si adatta bene quando hai bisogno di ampia interoperabilità, quando il tuo stack ha opzioni crittografiche limitate o quando vuoi una sola leva di regolazione semplice.

Il “colpo” principale è il limite di 72 byte. bcrypt usa solo i primi 72 byte della password e ignora il resto. Questo può sorprendere chi usa frasi password lunghe o gestori di password.

Se scegli bcrypt, rendi esplicito il comportamento sulla lunghezza della password. O imponi una lunghezza massima (in byte, non in caratteri) o gestisci gli input lunghi in modo coerente tra tutti i servizi. L'importante è evitare troncamenti silenziosi che cambiano ciò che l'utente pensa sia la sua password.

bcrypt è anche meno resistente all'hardware moderno di cracking parallelo rispetto alle opzioni memory-hard. La sua difesa resta valida, ma si basa molto sulla scelta di un fattore di costo che mantenga ogni tentativo costoso.

Se stai costruendo un sistema nuovo o hai account ad alto valore (piani a pagamento, ruoli admin), migrare i nuovi hash a Argon2id continuando ad accettare gli hash bcrypt esistenti finché gli utenti non fanno il login è una strada comune e a basso rischio.

Punti di forza e compromessi di Argon2

Argon2 è stato creato appositamente per l'hashing delle password. Argon2id è la variante che la maggior parte dei team sceglie perché bilancia la resistenza alle GPU con una protezione ragionevole contro i side-channel.

Argon2id ti dà tre parametri:

• Memoria (m): quanta RAM usa ogni hash in esecuzione
• Tempo/iterazioni (t): quante passeggiate fa su quella memoria
• Parallelismo (p): quante lane usa (aiuta su CPU multi-core)

La memoria è il vantaggio principale. Se ogni tentativo richiede una quantità significativa di RAM, gli attaccanti non possono eseguire così tanti tentativi in parallelo senza pagare molto per capacità e larghezza di banda della memoria.

Lo svantaggio è operativo: più memoria per hash significa meno login concorrenti prima che i tuoi server risentano. Se imposti troppa memoria, i picchi di login possono causare code, timeout o anche errori out-of-memory. Devi anche pensare all'abuso: molti tentativi di login concorrenti possono diventare un problema di risorse se non limiti il lavoro.

Per mantenere Argon2id sicuro e utilizzabile, taralo come una caratteristica di performance:

• fai benchmark su hardware simile a quello di produzione
• limita il lavoro di hashing concorrente (cap dei worker, code)
• limita il tasso di tentativi e blocca i fallimenti ripetuti
• mantieni parametri coerenti tra i servizi in modo che un endpoint debole non diventi il bersaglio

Costi di prestazioni nei backend web reali

Con l'hashing delle password, “più veloce è meglio” è spesso l'obiettivo sbagliato. Vuoi che ogni tentativo sia costoso per gli attaccanti mentre i login restano rapidi per gli utenti reali.

Un modo pratico per decidere è avere un budget di tempo per la verifica sull'hardware di produzione. Molti team puntano a qualcosa come 100–300 ms per controllo, ma il valore giusto dipende dal traffico e dai server. La differenza tra bcrypt e Argon2 è cosa stai usando: bcrypt usa per lo più CPU, mentre Argon2 può anche consumare memoria.

Scegli un tempo target e misura

Scegli un tempo target per l'hash e testalo in condizioni che somiglino alla produzione. Misura sia l'hashing al momento del signup/change password sia la verifica al login, ma considera il login come il percorso caldo.

Un piano di misura leggero:

• testa 1, 10 e 50 verifiche di login concorrenti e registra latenza p50 e p95
• ripeti le prove per ridurre il rumore da caching e boost della CPU
• misura la chiamata al database separatamente così sai quanto costa davvero l'hash
• testa con lo stesso container e limiti CPU che distribuirai

I picchi contano più delle medie

La maggior parte dei sistemi fallisce durante i picchi. Se una newsletter invia una ondata di utenti alla pagina di login, le impostazioni di hashing decidono se il sistema resta reattivo.

Se una verifica richiede 250 ms e il tuo server può gestirne 40 in parallelo prima che si formino code, un picco di 500 tentativi può trasformarsi in attese di molti secondi. In quella situazione, una piccola riduzione del costo combinata a forti rate limit può migliorare la sicurezza reale più che spingere i parametri fino a rendere l'endpoint di login fragile.

Mantieni il login interattivo prevedibile

Non tutte le operazioni sulle password hanno la stessa urgenza. Mantieni il costo del login interattivo stabile e sposta il lavoro pesante fuori dal percorso critico. Un pattern comune è il rehash-on-login (aggiorna l'hash dell'utente subito dopo un login riuscito) o job in background per migrazioni e import.

Come scegliere i parametri passo dopo passo

La taratura dei parametri serve ad aumentare il costo per gli attaccanti senza rendere le autenticazioni lente o destabilizzare i server.

1. Scegli un algoritmo ben supportato nel tuo stack. Se Argon2id è disponibile e ben supportato, di solito è la scelta predefinita. Se hai bisogno di ampia compatibilità, bcrypt va ancora bene.

2. Imposta un tempo target per hash su hardware simile alla produzione. Scegli qualcosa che mantenga i login fluidi durante i picchi.

3. Regola per raggiungere quel tempo. Con bcrypt, modifica il fattore di costo. Con Argon2id, bilancia memoria, iterazioni e parallelismo. La memoria è la leva che cambia di più l'economia per l'attaccante.

4. Memorizza algoritmo e impostazioni con l'hash. Molti formati standard di hash incorporano questi dettagli. Assicurati anche che il campo del database sia sufficientemente lungo in modo che gli hash non vengano mai troncati.

5. Pianifica gli upgrade con rehash-on-login. Quando un utente effettua il login, se il suo hash memorizzato usa impostazioni più deboli della policy attuale, ricalcolalo e sostituiscilo.

Un punto di partenza pratico

Se ti serve un baseline prima di misurare, parti conservativo e aggiusta in base al timing.

• Per bcrypt, molti team iniziano intorno al costo 12 e poi si muovono in base a misurazioni reali.
• Per Argon2id, un baseline comune è memoria nell'ordine delle decine a qualche centinaio di MB, costo tempo 2–4 e parallelismo 1–2.

Considera questi numeri come punti di partenza, non regole fisse. I parametri giusti sono quelli che si adattano al tuo traffico, hardware e ai picchi di login.

Errori comuni che indeboliscono la memorizzazione delle password

La maggior parte dei fallimenti nella memorizzazione delle password deriva da lacune di configurazione, non da algoritmi sbagliati.

Gli errori sui salt sono frequenti. Ogni password deve avere il suo salt unico memorizzato con l'hash. Riutilizzare i salt, o usare un salt globale per tutti gli utenti, facilita il riuso del lavoro da parte degli attaccanti e il confronto tra account.

La negligenza del costo è un altro errore. I team spesso pubblicano con un costo basso perché il login sembra più veloce, poi non lo rivedono mai. L'hardware migliora, gli attaccanti scalano e le impostazioni una volta adeguate diventano economiche.

L'over-tuning di Argon2 è comune: impostare la memoria estremamente alta può sembrare una buona idea sulla carta, ma poi causa login lenti, code di richieste o errori out-of-memory durante i picchi reali.

La gestione della lunghezza della password è importante, soprattutto con il comportamento dei 72 byte di bcrypt. Se permetti password lunghe ma le tronchi silenziosamente, crei comportamenti confusi e riduci la sicurezza.

Alcune pratiche semplici prevengono la maggior parte di questi problemi:

• usa salt unici per password (lascia che sia la libreria a generarli)
• fai load test e rivedi le impostazioni periodicamente
• regola la memoria di Argon2 pensando ai picchi, non solo ai test singoli
• rendi espliciti e coerenti i limiti di lunghezza della password
• metti limiti di concorrenza e monitoraggio sull'endpoint di login

Checklist rapida per una configurazione più sicura

Tieni questa lista a portata di mano quando rilasci e quando cambi infrastruttura:

• Salt unico per password, generato casualmente e salvato con l'hash
• Costo di hashing che sopporta il traffico di picco, verificato con test di carico su hardware simile a quello di produzione
• Parametri memorizzati con l'hash, così puoi verificare account vecchi e aumentare il costo in seguito
• Controlli per attacchi online, inclusi rate limit e brevi lockout per ripetuti fallimenti
• Un percorso di upgrade, di solito rehash-on-login

Un semplice controllo di sanità: esegui un test di staging che includa un picco di logins (riusciti e falliti) e osserva latenza end-to-end oltre a CPU e RAM. Se il percorso di login soffre, regola il costo e rinforza i rate limit. Non “risolvere” tagliando elementi essenziali come i salt.

Un esempio realistico: tarare per una piccola web app

Immagina una piccola app SaaS con poche migliaia di utenti. La maggior parte del giorno è stabile, ma vedi brevi picchi di login dopo una newsletter o all'inizio della giornata lavorativa. Qui la scelta diventa pianificazione della capacità.

Scegli Argon2id per aumentare il costo del cracking offline. Scegli un tempo target di verifica sul tuo hardware reale (ad esempio 100–250 ms), poi regola i parametri per raggiungerlo monitorando la RAM, perché le impostazioni di memoria possono limitare quanti login puoi gestire contemporaneamente.

Un ciclo pratico di taratura:

• parti con iterazioni e parallelismo modesti
• aumenta la memoria finché la concorrenza non diventa scomoda
• regola le iterazioni per aggiustare il costo in tempo
• retesta con burst simulati, non solo singole richieste

Se hai già hash più vecchi con impostazioni più deboli, continua a verificarli ma aggiornali silenziosamente. Dopo un login riuscito, ricalcola l'hash con le impostazioni correnti e salva il nuovo valore. Col tempo, gli utenti attivi migrano a hash più forti senza reset forzati.

Dopo il rilascio, monitora il login come qualsiasi altro endpoint critico: osserva latenza (p95/p99), CPU e RAM durante i picchi, picchi di login falliti e quanto velocemente gli hash vecchi vengono sostituiti.

Prossimi passi: rilascia in sicurezza e migliora continuamente

Scrivi la tua policy e trattala come una impostazione vivente. Per esempio: “Argon2id con X memoria, Y iterazioni, Z parallelismo” o “bcrypt fattore di costo N”, con la data di scelta e quando la rivedrai (ogni 6–12 mesi è un buon intervallo).

Mantieni un percorso di upgrade così non resti bloccato con hash vecchi. Il rehash-on-login è semplice e funziona bene nella maggior parte dei sistemi.

Un hash forte aiuta, ma non sostituisce i controlli contro gli abusi online. Rate limit, lockout e flussi di reset password curati contano tanto quanto l'hashing per la sicurezza reale.

Se costruisci il backend con una piattaforma no-code come AppMaster, vale la pena verificare che il modulo di autenticazione usi di default hashing forti e che il costo sia tarato sullo stesso tipo di infrastruttura su cui distribuirai. Quel piccolo test iniziale spesso fa la differenza tra “sicuro e fluido” e “sicuro ma inutilizzabile sotto carico”.