 |
| Perché anche le password, come la pasta, senza sale vengono male |
Quando si parla di sicurezza delle password, quasi tutti sanno che non vanno mai salvate in chiaro, ma devono essere protette tramite hashing. Tuttavia, c’è un dettaglio fondamentale che troppo spesso viene trascurato o implementato male: il salt.
Questo piccolo ingrediente fa una differenza enorme tra un sistema “accettabile” e uno seriamente vulnerabile.
Vediamo perché il “sale” è così importante, come va gestito correttamente e cosa succede quando non lo si usa.
🔡 Hashing delle password: il punto di partenza
Un hash è il risultato di una funzione crittografica che trasforma un input (la password) in una stringa di lunghezza fissa.
Caratteristiche chiave di un buon algoritmo di hashing:
- È deterministico: la stessa password produce sempre lo stesso hash
- È one-way: dall’hash non si può risalire alla password originale
- Una piccola variazione dell’input produce un hash completamente diverso
Esempio (semplificato):
password123 → ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f
Se però due utenti usano la stessa password, senza salt otterranno lo stesso hash. Ed è qui che iniziano i problemi.
🧂 Cos’è un salt e perché serve davvero
Il salt è una stringa casuale che viene aggiunta alla password prima dell’hashing.
hash = H(password + salt)
Il salt:
- È diverso per ogni utente
- Non deve essere segreto
- Deve essere sufficientemente lungo e casuale
Grazie al salt, due utenti con la stessa password avranno hash completamente diversi.
Senza salt
Utente A: password123 → hash1
Utente B: password123 → hash1
Con salt
Utente A: password123 + X7f$2 → hashA
Utente B: password123 + 9K!pQ → hashB
Stessa password, risultati totalmente diversi.
🏴☠️ Casi reali: quando il sale mancava
LinkedIn (2012)
Nel famoso data breach di LinkedIn, oltre 6 milioni di password furono esposte.
Il problema principale? Password hashate con SHA-1 e senza salt.
Risultato:
- I cracker usarono rainbow table precomputate
- Le password più comuni vennero recuperate in pochissimo tempo
- Milioni di account compromessi
RockYou (2009)
Il leak RockYou conteneva password in chiaro, ma è diventato un riferimento proprio perché ha permesso di creare enormi dizionari e tabelle di attacco che oggi sono ancora usate contro hash non salati.
Attacchi moderni
Anche oggi, database con hash senza salt:
- Permettono attacchi offline rapidissimi
- Rendono inutili password “decenti” ma comuni
- Consentono correlazioni tra utenti con la stessa password
🏴☠️ Salt e rainbow table: il vero nemico
Le rainbow table sono tabelle precomputate che associano password comuni ai rispettivi hash.
Senza salt:
- Una sola tabella può essere usata contro milioni di hash
- L’attacco è velocissimo
Con salt:
- Servirebbe una rainbow table per ogni salt
- Computazionalmente impraticabile
- Di fatto l’attacco perde senso
Questo è uno dei motivi principali per cui un sistema senza salt è considerato insicuro, anche se usa un algoritmo di hashing “forte”.
🧑🎓 Come si gestisce correttamente il salt
Una domanda comune è:
“Se il salt è casuale, come faccio a verificare la password?”
La risposta è semplice: il salt viene salvato insieme all’hash.
Registrazione utente
- L’utente inserisce la password
- Il sistema genera un salt casuale
- Calcola l’hash:
hash = H(password + salt) - Salva nel database:
salthash
Login / verifica credenziali
- L’utente inserisce la password
- Il sistema recupera il salt associato all’utente
- Ricalcola:
hash_verifica = H(password_inserita + salt) - Confronta
hash_verificacon l’hash salvato
Se coincidono, la password è corretta.
👉 Il salt non deve mai cambiare per quell’utente, altrimenti l’hash risultante sarebbe diverso.
♻️ Salt globale vs salt per utente
❌ Salt globale (sconsigliato)
- Un unico salt uguale per tutti gli utenti
- Meglio di niente
- Ma ancora vulnerabile a diversi attacchi
✅ Salt unico per utente (best practice)
- Ogni password è isolata dalle altre
- Nessuna correlazione tra hash
- Massima resistenza ad attacchi offline
ℹ️ Salt ≠ Pepper
Per completezza:
- Salt: casuale, pubblico, salvato nel DB
- Pepper: segreto globale, salvato nel codice o in un vault
Il pepper può aggiungere un ulteriore livello di sicurezza, ma non sostituisce mai il salt.
💣 I rischi concreti di non usare il salt
Non usare il salt espone a rischi molto reali:
- 🔓 Cracking massivo delle password
- ⚡ Attacchi offline estremamente veloci
- 👥 Identificazione di utenti con la stessa password
- 📉 Compromissione totale in caso di breach
- 🧠 Sfruttamento immediato di password comuni
In pratica, se un database viene rubato:
- Senza salt → disastro
- Con salt → danni limitati e costi di attacco molto più alti
🎯 Conclusione
Il salt è uno di quei dettagli che sembrano piccoli, ma che separano una sicurezza professionale da una amatoriale.
Non è un optional, non è una “feature avanzata”: è una necessità assoluta.
Come per la cucina:
- Una buona ricetta senza sale è insipida
- Un sistema di password senza salt è insicuro
E in sicurezza informatica, come in cucina, aggiungere il sale al momento giusto fa tutta la differenza.
Follow me #techelopment
Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment
