Da cosa ti protegge davvero l'hashing di una password

La versione breve

L'hashing di una password protegge gli utenti quando il tuo database delle password viene rubato.

Questo è il suo compito principale. Non l'unico dettaglio, non l'intero modello di sicurezza, ma la ragione centrale per cui applichiamo hash alle password invece di memorizzarle direttamente.

Una password sottoposta correttamente a hash è difficile da invertire. Se un attaccante ottiene una copia della tua tabella utenti, non dovrebbe scoprire immediatamente che la password di Alice è Spring2026!. Ottiene invece un hash memorizzato, che richiede tempo, denaro e hardware per essere verificato contro possibili tentativi.

Questa distinzione è importante. L'hashing delle password non serve a rendere sicuro il login da solo. Non ferma il phishing. Non impedisce a qualcuno di provare password trapelate contro il tuo modulo di accesso. Non protegge un cookie di sessione dopo il login. Compra tempo e riduce il danno dopo un errore molto specifico: l'archivio dei verificatori di password viene esposto.

Se capisci questo confine, prenderai decisioni migliori su algoritmi, fattori di lavoro, reset, logging e risposta agli incidenti.

Che cos'è un hash di password

Un hash di password è l'output di una funzione a senso unico applicata a una password, di solito con un salt unico e un algoritmo di hashing delle password deliberatamente lento.

Quando un utente crea un account, il sistema dovrebbe fare più o meno questo:

1. Ricevere la password tramite HTTPS.
2. Generare un salt casuale e unico.
3. Eseguire password e salt attraverso una funzione di hashing delle password come Argon2id, bcrypt, scrypt o PBKDF2.
4. Memorizzare nome dell'algoritmo, parametri, salt e hash risultante.
5. Scartare la password originale.

Quando l'utente accede in seguito, il sistema ripete lo stesso processo di hashing con la password inviata e i parametri memorizzati. Se l'hash risultante corrisponde all'hash memorizzato, il login riesce.

La parte importante: l'applicazione non deve conoscere la password originale. Deve solo verificare che la password inviata produca il risultato atteso.

Ecco perché memorizzare le password con crittografia reversibile è di solito il modello sbagliato. Se la tua applicazione può decifrare ogni password, allora chiunque rubi la chiave di decifratura può fare lo stesso. Le password dovrebbero normalmente essere non verificabili al contrario, non semplicemente nascoste.

Da cosa ti protegge l'hashing

1. Divulgazione immediata delle password dopo una violazione del database

Se un attaccante ruba un database contenente password in chiaro, il danno è istantaneo. Ogni password è esposta. Gli utenti sono a rischio non solo sul tuo sito, ma ovunque abbiano riutilizzato quella password.

Se il database contiene password con hash ben calcolati, l'attaccante ha più lavoro da fare. Deve indovinare password candidate, calcolare l'hash di ogni tentativo con il salt e i parametri corretti, e confrontare il risultato.

Per password deboli, questo può comunque essere veloce. Per password forti e uniche, può essere impraticabile.

L'hashing trasforma una divulgazione catastrofica in una corsa: gli utenti riusciranno a reimpostare le password e tu riuscirai a contenere l'incidente prima che gli attaccanti ne violino molte?

Non è perfetto. È comunque una violazione. Ma è una modalità di fallimento drasticamente migliore.

2. Attacchi di massa contro l'intera base utenti

I salt sono una parte fondamentale della memorizzazione delle password perché impediscono agli attaccanti di colpire in modo efficiente molti utenti contemporaneamente con tabelle precalcolate.

Un salt non è segreto. È memorizzato insieme all'hash. Il suo compito è garantire unicità.

Se due utenti scelgono la stessa password, salt unici assicurano che gli hash memorizzati siano diversi. Questo impedisce agli attaccanti di vedere a colpo d'occhio che molti utenti condividono la stessa password. Inoltre impedisce i classici attacchi con rainbow table, in cui gli attaccanti usano enormi liste precalcolate di corrispondenze password-hash.

Senza salt, un hash violato può rivelare ogni utente con la stessa password. Con i salt, ogni tentativo di password deve essere verificato separatamente per ogni utente.

3. Tentativi offline veloci

Una volta che gli attaccanti hanno un database delle password, possono fare tentativi offline. Questo significa che rate limit del login, CAPTCHA, blocco IP e monitoraggio non contano più. L'attaccante può provare le ipotesi sul proprio hardware.

È qui che la scelta dell'algoritmo conta.

Hash generici come SHA-256 e SHA-512 sono progettati per essere veloci. Questo è utile per l'integrità dei file e le firme digitali. È negativo per la memorizzazione delle password.

Gli algoritmi di hashing delle password sono progettati per essere lenti, configurabili e talvolta memory-hard. Argon2id, bcrypt, scrypt e PBKDF2 permettono tutti di regolare parametri di costo in modo che ogni tentativo richieda tempo significativo.

Argon2id è ampiamente raccomandato per i nuovi sistemi perché può essere configurato per richiedere sia tempo CPU sia memoria, rendendo più costoso il cracking su larga scala con GPU. bcrypt resta comune e accettabile se configurato bene, anche se ha limitazioni come la gestione della lunghezza delle password. PBKDF2 è ancora usato in alcuni ambienti guidati dalla conformità, soprattutto dove sono richiesti componenti validati FIPS.

Il principio è semplice: rendere i login legittimi abbastanza veloci, rendendo costosi miliardi di tentativi.

Da cosa non ti protegge l'hashing

1. Phishing

Se un utente digita la propria password in una falsa pagina di login, l'hashing sul tuo server non aiuta. L'attaccante riceve la password prima ancora che il tuo sistema la veda.

Le difese qui sono diverse: autenticazione a più fattori, passkey, formazione degli utenti, igiene dei domini, autenticazione resistente al phishing e flussi di reset della password progettati con attenzione.

L'hashing delle password è una rete di sicurezza per segreti memorizzati. Non è una difesa contro utenti ingannati a consegnare quei segreti.

2. Credential stuffing

Il credential stuffing avviene quando gli attaccanti prendono coppie di nome utente e password trapelate da un servizio e le provano su un altro.

I tuoi hash delle password possono essere eccellenti, e il credential stuffing può comunque funzionare se gli utenti riutilizzano le password.

Questo è un attacco online contro il tuo modulo di login, non un attacco offline contro il tuo database. Hai bisogno di rate limiting, rilevamento delle anomalie, controlli su password compromesse, MFA e politiche di blocco sensate che non creino facili opportunità di denial-of-service.

Lo stesso ragionamento pratico si applica a qualsiasi modulo esposto. Se stai rivedendo la tua superficie di autenticazione, vale la pena leggere perché il tuo modulo di contatto è la tua maggiore fonte di rischio spam; i meccanismi sono diversi, ma la lezione è simile: gli input pubblici hanno bisogno di controlli contro gli abusi, non solo di codice backend pulito.

3. Password catturate nei log o negli analytics

L'hashing aiuta solo se la password in chiaro viene scartata rapidamente e non copiata altrove.

Errori comuni includono:

• Registrare nei log l'intero corpo delle richieste durante tentativi di login falliti.
• Inviare password a strumenti di monitoraggio degli errori.
• Catturare campi password in prodotti di session replay.
• Includere credenziali negli URL durante flussi di reset o migrazione progettati male.
• Memorizzare password temporanee in chiaro durante le importazioni.

Questi errori aggirano completamente l'hashing delle password. Se il testo in chiaro finisce in log, backup, data warehouse o strumenti di terze parti, la tua funzione di hash è irrilevante.

Tratta i campi password come dati tossici. Redigili prima del logging. Escludili dagli analytics. Tienili fuori dagli URL. Limita chi può accedere alle tracce di produzione.

4. Cattiva sicurezza delle sessioni

Dopo il login, il browser dell'utente di solito riceve un cookie o un token di sessione. Se quel token viene rubato, l'attaccante potrebbe non aver bisogno della password.

L'hashing delle password non protegge da cross-site scripting, cookie non sicuri, session fixation, generazione debole dei token o durate di sessione eccessivamente lunghe.

I cookie di sessione meritano una revisione propria: HttpOnly, Secure, SameSite appropriato, sessioni ad alto rischio di breve durata e invalidazione lato server al cambio password. Anche il più ampio panorama della privacy e dei browser continua a cambiare, come trattato in cosa è cambiato per i cookie nel 2026.

5. Reset della password e recupero account deboli

Molte compromissioni di account non iniziano con la password. Iniziano con il flusso di reset.

Se i token di reset sono prevedibili, longevi, trapelano tramite header referrer o vengono inviati ad account email compromessi, l'hashing delle password non ti salverà.

Usa token di reset ad alta entropia, finestre di scadenza brevi, uso singolo e notifiche chiare agli utenti. Poiché l'email è spesso il canale di recupero, anche l'autenticazione di base del dominio conta. Se il tuo team tratta i record DNS come una cerimonia misteriosa, inizia con un tour di MX, SPF, DKIM e DMARC pensato per sviluppatori.

La scelta dell'algoritmo: cosa usare ora

Per nuove applicazioni, usa Argon2id se la tua piattaforma lo supporta bene. È il vincitore della Password Hashing Competition ed è progettato per la memorizzazione delle password, inclusa la resistenza al cracking intensivo su GPU.

Una gerarchia moderna ragionevole è questa:

1. Argon2id per nuovi sistemi dove disponibile.
2. bcrypt quando Argon2id non è pratico e il supporto a bcrypt è maturo.
3. scrypt quando la configurazione memory-hard è ben supportata.
4. PBKDF2 dove richiesto dalla piattaforma o da vincoli di conformità.

Evita SHA-256, SHA-512, MD5 semplici, o combinazioni artigianali come sha256(password + salt). Gli hash veloci non sono funzioni di memorizzazione delle password. Le costruzioni personalizzate ingegnose tendono a essere peggiori di quelle standard e noiose.

Evita anche di inventare una tua policy password basata su dettagli dell'algoritmo. Gli utenti non traggono beneficio da una checklist di composizione con 12 regole se li spinge verso schemi prevedibili. Password più lunghe e uniche, password manager, screening delle password compromesse e MFA di solito contano di più.

I fattori di costo non si impostano una volta per tutte

L'hashing delle password ha parametri. Argon2id ha memoria, iterazioni e parallelismo. bcrypt ha un fattore di costo. PBKDF2 ha un numero di iterazioni.

Questi valori dovrebbero essere scelti in base al tuo ambiente di produzione. Troppo bassi, e gli attaccanti fanno tentativi a basso costo. Troppo alti, e il tuo sistema di login diventa lento o vulnerabile a denial-of-service.

Un obiettivo pratico è spesso nell'intervallo da decine a poche centinaia di millisecondi per verifica password sui tuoi server reali, a seconda di traffico e rischio. I sistemi ad alta sicurezza possono scegliere di più. I sistemi consumer su larga scala possono richiedere un'attenta pianificazione della capacità.

Non copiare un fattore di costo da un post di blog di cinque anni fa. L'hardware cambia. Le librerie cambiano. Il tuo traffico cambia.

Rivedi periodicamente i parametri e pianifica il rehashing. Uno schema comune è memorizzare algoritmo e parametri con ogni hash. Al login riuscito, se i parametri memorizzati sono obsoleti, ricalcola l'hash della password inviata con la configurazione più recente e aggiorna il record.

Pepper: utili, ma non un sostituto

Un pepper è un valore segreto aggiunto al processo di hashing della password e memorizzato separatamente dal database, spesso in un secrets manager o in un hardware security module.

A differenza di un salt, un pepper deve restare segreto.

I pepper possono ridurre il danno se il database trapela ma i segreti applicativi no. Sono più utili in ambienti maturi con una buona gestione delle chiavi. Sono meno utili se lo stesso attaccante può rubare sia il database sia la configurazione dell'applicazione.

Se usi un pepper, pianifica con attenzione la rotazione. Ruotarlo può richiedere agli utenti di accedere di nuovo o reimpostare le password, a seconda del progetto. Un pepper è un livello aggiuntivo, non un motivo per indebolire le impostazioni dell'hash sottostante.

La checklist operativa

Se sei responsabile di un sistema reale, la checklist pratica è breve:

• Memorizza le password solo con un algoritmo standard di hashing delle password.
• Usa un salt casuale unico per ogni password.
• Preferisci Argon2id per nuovi progetti.
• Regola i parametri di costo su hardware simile alla produzione.
• Memorizza algoritmo e parametri con ogni hash.
• Riesegui l'hash al login quando i parametri diventano obsoleti.
• Non registrare mai password nei log e non inviarle a strumenti di analytics.
• Usa TLS ovunque vengano inviate credenziali.
• Aggiungi MFA o passkey dove il rischio lo giustifica.
• Proteggi i flussi di reset con la stessa serietà dei flussi di login.
• Prepara un piano di incidente per reset forzati e notifica agli utenti.

L'hashing delle password non è affascinante. È impiantistica. Ma è il tipo di impiantistica che determina se una violazione diventa un incidente doloroso o un disastro per tutti gli utenti.

<!-- tool-cta:start -->

💡 Prova questo: Scopri come lo stesso input viene mappato su algoritmi diversi con il Hash Generator, che rende concreta la differenza tra hash veloci e hash adatti alle password.

<!-- tool-cta:end -->

Il modello mentale onesto

Il modo migliore di pensare all'hashing delle password è questo:

L'hashing non protegge la password mentre l'utente la sta digitando. Non protegge l'account dopo che l'utente ha effettuato l'accesso. Non protegge gli utenti che riutilizzano password sul web.

Protegge il verificatore memorizzato.

Sembra limitato, ma è estremamente importante. I database trapelano. I backup trapelano. I sistemi di staging vengono copiati. I fornitori ottengono accessi che non dovrebbero avere. Vecchie esportazioni restano nello storage a oggetti più a lungo di quanto chiunque ricordi.

Quando questo accade, il design della memorizzazione delle password diventa la differenza tra attaccanti che ricevono password e attaccanti che ricevono un costoso problema di guessing.

Questo è ciò da cui ti protegge davvero l'hashing di una password.