Cos`è il salting nella sicurezza? Spiegazione dell`hashing delle password.

Nel giugno 2012, un hacker ha pubblicato 117 milioni di record di account LinkedIn su un forum russo. L'elenco era un muro di hash SHA-1 non salati. SHA-1 è veloce. Senza un salt per separare le password identiche, lo stesso hash si presentava migliaia di volte accanto allo stesso hash. Nel giro di circa settantadue ore, i ricercatori di sicurezza erano riusciti a decifrare circa il novanta percento del file. Quando la violazione è riemersa nel maggio 2016 come parte di un dataset di 167 milioni di record, quelle credenziali hanno alimentato campagne di credential stuffing per anni.

La strategia difensiva che avrebbe ridotto quella violazione a una semplice nota a piè di pagina – aggiungere "sale" a ogni password memorizzata – esisteva già nel 1979. Si chiama "salting". Non è una novità, non è costosa e non è particolarmente ingegnosa. È ciò che fa la differenza tra una fuga di dati da un database che rimane un incidente circoscritto e un problema di password per tutti che dura per cinque anni.

La maggior parte dei problemi di archiviazione delle password nei sistemi moderni deriva ancora dalla stessa causa principale: qualcuno ha deciso che "usiamo SHA-256" fosse sufficiente. Questo articolo illustra cos'è effettivamente il salting, come funziona nella pratica, da cosa protegge e da cosa non protegge, e quale raccomanda OWASP come impostazione predefinita per il 2026.

Cos'è il salting nella sicurezza e nell'hashing delle password?

Riassumendo l'argomento in una sola frase, "salting" significa aggiungere dati casuali a una password prima che questa venga sottoposta ad hashing. Il valore casuale, ovvero il salt, viene generato una sola volta per account, insieme al nuovo hash della password, memorizzato in chiaro accanto all'hash risultante e letto a ogni accesso. Non è una chiave, non è un segreto, non è un sistema di crittografia. È un modificatore pubblico con un unico scopo: garantire che, quando due utenti hanno la stessa password, non condividano mai la stessa password con hash memorizzata.

L'hashing di per sé è unidirezionale. Elaborando una password con SHA-256 o Argon2id si ottiene un valore a lunghezza fissa che nessun algoritmo può invertire. Il problema è che "nessun algoritmo" esclude una scorciatoia semplice: la ricerca dell'hash in un dizionario precalcolato. L'aggiunta di un salt al processo di hashing crea un hash univoco per ogni utente, anche quando la password di base è identica parola per parola. Password comuni come "password" e "qwerty" non si sovrappongono più nel database. L'aggiunta di un salt garantisce che la perdita di una singola riga non riveli all'attaccante nulla sugli altri utenti.

Tre regole distinguono un salt utilizzabile da uno inutile. Prima regola: ogni password ha il suo salt casuale, generato al momento della registrazione o del ripristino della password. Una password con salt riutilizzata su più account non è molto migliore di una password senza salt: l'attacco di massa funziona allo stesso modo. Seconda regola: il salt può essere pubblico. Conoscere il salt di per sé non offre a un attaccante alcuna scorciatoia per accedere alla funzione hash sottostante. Pertanto, il salt risiede nel database accanto all'hash, e questa posizione è corretta, anzi consigliata. Terza regola: i valori del salt provengono da un generatore di numeri pseudocasuali crittograficamente sicuro. Linux ne espone uno tramite `getrandom(2)`. Node lo chiama `crypto.randomBytes`. La libreria standard di Python lo incapsula in `secrets.token_bytes`. Il metodo non crittografico `Math.random()` non è adatto, anche se compare in codice reale sottoposto a verifica molto più spesso di quanto dovrebbe.

Due persone che scelgono "hunter2" come password dovrebbero ottenere due hash memorizzati completamente diversi. È il salting che rende possibile tutto ciò. Se si omette il salting, il database non solo perde gli hash, ma anche il grafo sociale di chi condivide quale password con chi.

Come funziona il salting delle password?

Il meccanismo si articola in quattro fasi e dieci anni di violazioni dei sistemi di archiviazione delle password dimostrano che quasi ogni errore si verifica perché qualcuno ne ha saltata una.

Il primo passaggio viene eseguito al momento della registrazione. L'applicazione richiede a un CSPRNG da sedici a trentadue byte casuali. Questo è il salt. Le linee guida OWASP 2025 considerano sedici byte (128 bit) come minimo; auth0 e diversi fornitori di gestori di password raccomandano di arrivare a trentadue. Lo standard NIST SP 800-63B-4 stabilisce un minimo di quattro byte, ma avverte che le collisioni legate alla data di nascita iniziano a verificarsi intorno ai sessantacinquemila utenti con tale dimensione, motivo per cui nessuno in realtà utilizza quattro byte.

Il secondo passaggio combina il salt con la password scelta dall'utente. La concatenazione è la forma più comune, con il salt posizionato prima o dopo la stringa della password. Alcuni sistemi utilizzano invece HMAC, trattando il salt come chiave HMAC, il che evita alcuni problemi di estensione della lunghezza tipici della concatenazione diretta.

Il terzo passaggio elabora l'input combinato tramite un algoritmo di hashing delle password, ovvero quella che i manuali di crittografia chiamano funzione di derivazione della chiave, o KDF. È in questa fase che la maggior parte dei team commetteva errori, spesso ricorrendo a un algoritmo di hash generico e considerando il lavoro concluso. Il semplice SHA-256 non è adatto come metodo per memorizzare le password. Una GPU consumer del 2026 elabora oltre cento miliardi di hash SHA-256 al secondo, quindi anche con un salt il costo per tentativo nell'hashing crittografico rimane irrisorio. L'aggiunta di un salt neutralizza i vettori di attacco basati sulle tabelle arcobaleno. Tuttavia, non rallenta di per sé la decifrazione delle password tramite forza bruta. Lo strumento giusto in questo caso è una funzione deliberatamente lenta e che richiede molta memoria: Argon2id è l'algoritmo predefinito preferito da OWASP, con scrypt e bcrypt accettabili, e PBKDF2 con un numero molto elevato di iterazioni consentite laddove la conformità FIPS-140 imponga tale scelta.

Il quarto passaggio memorizza sia l'hash che il salt. Le librerie moderne gestiscono il formato di memorizzazione, quindi non è necessario gestire manualmente il salt memorizzato. L'output di bcrypt ha un aspetto simile a `$2b$12$9f4c8a7b...kQR8YZpL9`: questa singola stringa contiene l'identificativo dell'algoritmo, il fattore di costo, il salt e il valore hash. Argon2id utilizza un formato di stringa PHC analogo, `$argon2id$v=19$m=19456,t=2,p=1$$`. È sufficiente scrivere questa stringa in una colonna del database e il gioco è fatto. La libreria ha già fatto tutto il necessario per memorizzare le password in modo sicuro: ha generato dati casuali per il salt, ha elaborato la password con un algoritmo di hash lento e ha raggruppato il risultato per il recupero.

Il processo di login segue la stessa pipeline in senso inverso. L'applicazione recupera il salt dell'utente e l'hash memorizzato, elabora la password inviata con lo stesso algoritmo e lo stesso salt, e confronta il risultato con l'hash memorizzato utilizzando un confronto a tempo costante. Il tempo costante è fondamentale: un semplice `==` rivela informazioni sul numero di byte corrispondenti, il che ha generato vulnerabilità reali agli attacchi di tipo time-lapse. Utilizza `hmac.compare_digest`, `crypto.timingSafeEqual` o l'equivalente del tuo framework.

Perché la salatura è importante: il problema della tavola arcobaleno

Le rainbow table sono l'attacco specifico per cui è stato inventato il salting. Immaginate una tabella di ricerca precalcolata che associa ogni password plausibile (ogni parola del dizionario, variante comune, voce di una lista trapelata) al suo hash SHA-256. Queste tabelle esistono, vengono vendute sui forum di cracking e raggiungono dimensioni di terabyte. Una volta che un hacker si impossessa di un dump di database di hash non salati, la ricerca di un hash in una rainbow table diventa una semplice query di database, non un'operazione di cracking. L'attacco a LinkedIn del 2012 è avvenuto esattamente in questo modo: 117 milioni di hash SHA-1 non salati contro una rainbow table, il novanta percento dei quali è stato decifrato in circa tre giorni.

Aggiungendo un salt per utente, le tabelle rainbow smettono di funzionare. L'attaccante avrebbe bisogno di una tabella precalcolata separata per ogni valore di salt univoco. Con un salt casuale di sedici byte, ciò significa 117 milioni di tabelle diverse per 117 milioni di utenti, e ogni tabella avrebbe comunque una dimensione di terabyte. I soli costi di archiviazione rendono questa operazione impraticabile. L'attacco viene quindi escluso dal modello di minaccia.

Questo è il compito principale di un salt. È volutamente limitato. L'aggiunta di salt non rallenta un tentativo di attacco a forza bruta mirato contro un utente specifico. L'aggiunta di salt non impedisce il credential stuffing a seguito di una precedente fuga di dati. L'aggiunta di salt non è utile se la password è "123456": l'attaccante proverà la combinazione più ovvia, e il salt verrà ricalcolato per ogni tentativo, ma il costo per tentativo non cambierà in modo significativo.

Ciò che il salting mitiga in modo affidabile: le rainbow table e la fuga di informazioni sul riutilizzo delle password tra utenti nello stesso database. Ciò che l'hashing lento mitiga: il costo per tentativo. Ciò che il pepper mitiga: il furto di dati solo dal database. Ciò che l'autenticazione a più fattori (MFA) mitiga: il credential stuffing. Il salting è un livello di sicurezza in una pila: aggiungere un salt per decifrare le password in modo più difficile non è la stessa cosa che rendere ogni singola password difficile da indovinare. L'obiettivo del salting è ottenere un hash diverso per ogni utente; rendere costoso ogni tentativo è un problema separato.

Hashing vs crittografia vs salting

Tre termini che vengono spesso confusi, soprattutto negli scritti di non specialisti. Non sono intercambiabili.

La crittografia protegge i dati che si desidera recuperare in seguito. Il destinatario detiene la chiave, la applica e legge l'originale. L'hashing è unidirezionale: una volta che una password diventa un hash, nessun algoritmo può invertirlo. Il salting è un modificatore che si applica all'input di una funzione hash; di per sé non ha alcun significato.

La violazione dei dati di Adobe del 2013 è un esempio emblematico. Adobe memorizzava 153 milioni di record utente crittografando le password con 3DES in modalità ECB sotto un'unica chiave valida per tutto il sito. Questa scelta si è rivelata un triplice errore. La crittografia non è la soluzione ideale per la memorizzazione delle password. La modalità ECB genera errori di input identici in output identici. Riutilizzare la stessa chiave per l'intero database significava che decodificando la chiave una sola volta si decodificavano tutti i 153 milioni di record. Schneier l'ha definita una delle peggiori violazioni di password della storia. La soluzione, adottata a ogni livello, è stata quella di passare all'hashing lento e con salt.

Sale contro pepe: la difesa a due strati

Il "pepper" è il cugino meno conosciuto del "salt". Il concetto: un valore segreto aggiuntivo, applicato a ogni password elaborata dall'applicazione, ma memorizzato al di fuori del database. Può essere una variabile d'ambiente, una voce del servizio di gestione delle chiavi o una chiave residente nell'HSM. Il "salt" risiede accanto all'hash in chiaro, il "pepper" no.

Il modello di minaccia si basa sul furto del solo database. Se un attaccante ruba solo il database, tramite SQL injection, un backup configurato in modo errato o una fuga di dati, dispone di salt e hash, ma non del pepper. Senza il pepper, non può nemmeno iniziare un attacco di forza bruta perché a ogni tentativo di hashing manca il modificatore segreto globale.

Un'implementazione tipica esegue `argon2id(salt + password + pepper)` o, più accuratamente, calcola prima `HMAC(pepper, password + salt)` e passa il risultato ad Argon2id. OWASP raccomanda l'utilizzo del pepper per i sistemi ad alto valore, ma riconosce il compromesso: la rotazione del pepper è complessa dal punto di vista operativo. Ruotarlo significa ricalcolare l'hash della password di ogni utente al successivo accesso e, se il pepper viene perso senza un backup, ogni account diventa irraggiungibile. La maggior parte delle applicazioni consumer non utilizza il pepper. Le applicazioni per banche, enti governativi e strutture sanitarie, invece, solitamente lo fanno.

Hashing delle password moderno nel 2026

Le linee guida OWASP 2025 sulla memorizzazione delle password classificano quattro algoritmi in ordine di preferenza. Il salt è integrato in tutti e quattro, quindi non è necessario generarlo manualmente.

Argon2id è un algoritmo che richiede molta memoria, il che significa che ogni tentativo non costa solo cicli di CPU, ma anche una porzione definita di RAM. Il requisito minimo OWASP di 19 MiB per hash implica che un attaccante che costruisce un ASIC personalizzato debba anche dotarsi di molta memoria veloce, e la memoria è la componente più costosa di qualsiasi sistema. La variante "id" combina Argon2i (resistente agli attacchi a canale laterale) e Argon2d (resistente alle GPU) eseguendo Argon2i nella prima metà e Argon2d nella seconda.

scrypt è precedente ad Argon2id e funziona secondo lo stesso principio di "difficoltà di memoria". bcrypt è ancora più vecchio, più semplice e ha un limite rigido di input di 72 byte che a volte crea problemi alle applicazioni che utilizzano passphrase lunghe: se sono necessari input più lunghi, è consigliabile utilizzare l'hashing preliminare con SHA-256 e la codifica in base64. PBKDF2 è la scelta più lenta ma conforme a FIPS; OWASP ha aumentato il numero di iterazioni per SHA-256 a 600.000 nel 2023, rispetto alle 310.000 precedenti.

Ciò che non deve essere incluso in questo elenco: SHA-256 semplice, SHA-512 semplice, MD5, SHA-1 e qualsiasi funzione personalizzata che termina con "+ salt". La velocità è il criterio di esclusione. SHA-256 è stato progettato per essere veloce su hardware standard. Questo è l'opposto di ciò che serve per la memorizzazione delle password.

Errori comuni di "salting" che emergono nelle verifiche reali

Le segnalazioni di violazioni reali continuano a evidenziare sempre gli stessi pochi errori.

Riutilizzare lo stesso salt per ogni utente vanifica l'intero meccanismo: il problema della tabella arcobaleno si ripresenta, con un solo passaggio in più. Usare il nome utente come salt è peggio, perché i nomi utente si ripetono tra i sistemi e le tabelle arcobaleno possono essere precalcolate per quelli più comuni. Con salt di lunghezza inferiore a sedici byte, si iniziano a verificare collisioni su larga scala, soprattutto con basi di utenti numerose. Generare il salt con una funzione casuale non crittografica — `Math.random()`, `time(0)` mod qualcosa, il generatore di numeri casuali predefinito del linguaggio — produce valori prevedibili che annullano i vantaggi del salting.

Un errore più subdolo è quello di memorizzare il salt su un server diverso "per motivi di sicurezza". Il salt non è un segreto. Suddividerlo tra sistemi diversi aggiunge complessità operativa senza rafforzare la sicurezza crittografica. Memorizzatelo nella stessa riga dell'hash. Le moderne stringhe PHC lo fanno automaticamente.

Il problema più grande, riscontrato nei controlli del 2026, è l'hashing con SHA-256 semplice, salt e shipping. Il salt impedisce le rainbow table, ma non risolve il problema di un cluster di GPU che esegue dieci miliardi di tentativi al secondo su un singolo account. La soluzione non è aggiungere un secondo salt, bensì passare a una KDF lenta come Argon2id.

Infine: hash legacy non salati. La migrazione non è facoltativa. La procedura standard prevede la verifica dell'hash legacy al successivo accesso, il ricalcolo dell'hash con l'algoritmo moderno e la sovrascrittura. Per gli utenti che non effettuano più l'accesso, è necessario forzare il ripristino della password a intervalli di tempo prestabiliti.

Perché la sola salatura non basta

Il salting è uno strato protettivo, non una fortezza. Neutralizza un attacco specifico, quello delle tabelle precalcolate, e non rivela nulla sulla robustezza della password sottostante. Gli attacchi di forza bruta funzionano ancora contro le password deboli. Il credential stuffing funziona ancora contro le password riutilizzate. Il phishing funziona ancora contro qualsiasi password.

Nel 2026, la vera sicurezza delle password si basa su quattro livelli di difesa. Argon2id, con un salt di sedici byte per utente, gestisce l'archiviazione. Un "pepper", opzionale ma utile per i sistemi sensibili, blocca i furti di dati che avvengono solo tramite database. L'autenticazione a più fattori blocca il credential stuffing e la maggior parte dei tentativi di phishing. Il monitoraggio continuo delle violazioni, tramite servizi come Have I Been Pwned e la sua API, individua il momento in cui le credenziali di un utente vengono compromesse, consentendo di forzarne il reimpostazione.

Saltando anche solo uno di questi livelli, un attaccante finirà per trovare la falla. Il solo utilizzo del salting, o di una qualsiasi altra difesa, è esattamente ciò che ogni analisi post-violazione degli ultimi dieci anni ha identificato come il punto debole.

Jordan Morris

Jordan Morris is an AI expert with over a decade of experience and the author of a widely-read blog focused on artificial intelligence. His content spans a range of topics—from the ethics of machine learning to real-world applications of neural networks in business. Known for his clear writing and deep insights, Jordan has become a trusted voice in the AI community, appealing to both newcomers and seasoned professionals alike.