# Cosa succede davvero quando la tua password finisce in un data breach > Una fuga di dati non finisce il giorno in cui arriva sui giornali: è lì che comincia. Si craccano gli hash, si incrociano le liste, si rivende tutto. E funziona per un motivo solo — perché riusiamo le password. 2026-04-16 · David Carrero · password.es Original: https://password.es/it/blog/cosa-succede-davvero-quando-la-tua-password-finisce-in-un-data-breach/ --- Quando a qualcuno trapela la password, se la immagina come un incidente isolato: un servizio ha avuto una brutta giornata, la notizia è uscita sui giornali, tu l'hai cambiata e fine della storia. **Non è finita niente.** Il giorno della fuga non è la fine di nulla: è il primo giorno di una catena di montaggio che durerà anni, e nella quale tu non comparirai mai col tuo nome. Vale la pena raccontarla per intero, perché quasi nessuno la vede. ## Primo passo: qualcuno porta via il database L'inizio non ha niente di spettacolare. Qualcuno trova una SQL injection, un backup lasciato aperto, un pannello di amministrazione con le credenziali di default. E si porta via una tabella. Quella tabella, se va bene, contiene la tua email e un hash della tua password. Se va meno bene, contiene la tua email e la tua password. In chiaro. Esattamente come l'hai scritta. ## 2009: trentadue milioni di password in chiaro Nel dicembre del 2009 un'azienda di widget per social network chiamata **RockYou** subì una SQL injection. Furono portate via circa **32 milioni di password**, e non c'era nessun hash da rompere: le teneva in chiaro. Fu un disastro per RockYou e un regalo per tutti gli altri. Per la prima volta esisteva un corpus enorme di password **vere**, scritte da gente che non immaginava che qualcuno le avrebbe lette. Non uno studio sul fenomeno: il fenomeno stesso. Quel file diventò `rockyou.txt`, che ancora oggi è il dizionario di riferimento con cui si testano gli attacchi. Il suo valore non sta nel contenere la tua password: sta nel contenere **il modo in cui la gente scrive le password**. Un nome e un anno, la parola e il `123`, il `!` in fondo. RockYou non ha fatto trapelare 32 milioni di segreti. Ha fatto trapelare lo schema. E lo schema non scade. ## Secondo passo: si cracca quel che si può, con tutta calma È qui che l'intuito sbaglia. Quando qualcuno prova a indovinare la tua password sulla schermata di login di un servizio, il servizio lo ferma: tre tentativi, un CAPTCHA, un blocco. Contro un server, indovinare è lento e rumoroso. Contro un file di hash che è già sul tuo disco non c'è nessun server. **Non c'è nessuno dall'altra parte che dica di no.** Si prova in locale, con le GPU, senza limite di tentativi e con tutto il tempo del mondo. Se il servizio ha fatto l'hash male — algoritmo veloce, senza sale — la differenza rispetto al testo in chiaro è una questione di comodità, non di sicurezza. E non si prova a caso: prima `rockyou.txt`, poi le regole derivate da lì. Sostituisci la `a` con `@`. Aggiungi un anno alla fine. Ogni trucchetto che a te è sembrato geniale sta scritto da più di dieci anni dentro un file di configurazione. Da lì esce una parte del dump trasformata in password leggibili. Il resto — quello lungo, quello casuale, quello che non sta in nessun dizionario — resta rumore. È la linea che traccia il [controllo password](/it/controllo/): non ti sgrida, ti dice da che parte della linea sei finito. ## Terzo passo: si incrocia, ed è lì che vali dei soldi Un dump da solo vale poco. La cosa preziosa è l'**aggregazione**: prendere dieci fughe di dati da siti diversi, incrociarle per email e tenersi le coppie `email:password` già in chiaro. Il risultato si chiama *combolist*, e non è più il database di nessuno. È un elenco di persone. ## 2013: l'inventario viene alla luce Nel dicembre del 2013 **Troy Hunt** mise in piedi **Have I Been Pwned**: un database pubblico di indirizzi email comparsi nelle fughe di dati, perché chiunque potesse chiedere se c'era dentro anche il suo. L'idea di fondo è semplice e scomoda: **se gli attaccanti hanno già l'inventario, negarlo alle vittime non protegge nessuno**. Anni dopo è arrivato *Pwned Passwords*, che fa lo stesso con le password e permette di consultarle senza inviarle: si manda un frammento dell'hash e il server restituisce un lotto di candidati, senza sapere quale fosse il tuo. ## 2017: il NIST smette di chiedere simboli e comincia a chiedere liste Quando il NIST pubblicò lo **SP 800-63B**, buttò a mare quasi tutta l'ortodossia dei moduli di registrazione e al suo posto mise un requisito che in pochi si aspettavano: al momento di impostare una password, il sistema deve **confrontarla con un elenco di valori compromessi noti** e rifiutarla se compare. È un cambio di teoria, non di dettaglio. La domanda non è più se la tua password *sembri* forte, ma se **sia già stata pubblicata**. Per questo il [generatore](/it/) fa l'unica cosa ragionevole: tirarla fuori da un posto dove non è mai stata. ## 2019: la fuga di dati che era già un riciclo di altre Nel gennaio del 2019 circolò un pacchetto che divenne famoso come **Collection #1**. Hunt lo analizzò e contò cosa c'era dentro: circa **773 milioni di indirizzi email unici** e circa **21 milioni di password uniche** in chiaro, aggregate da migliaia di fonti. L'importante non fu la dimensione. Fu **da dove veniva**: in buona parte era il riciclo di fughe precedenti, già craccate e messe in un formato comodo — anche se Hunt trovò pure materiale che fino a quel momento non aveva schedato. Il prodotto non era l'intrusione. Era l'inventario. E un inventario così ha un uso solo. ## Credential stuffing: non stanno attaccando te **Nessuno sta attaccando te.** È la parte più difficile da mandare giù. Nessuno si mette a pensare al tuo account. Qualcuno prende una combolist da centinaia di milioni di righe, la infila in uno strumento che le prova contro il form di login di una banca o di una webmail, distribuisce i tentativi su tanti indirizzi IP diversi per non far scattare i blocchi, e aspetta. La stragrande maggioranza fallisce. Poco importa: costano quasi zero. Questo è il *credential stuffing*, e non è indovinare. È **verificare**. La password ce l'hanno già; l'unica cosa che scoprono è dove altro l'hai messa. La tua password di quel forum non era importante. Nemmeno il forum lo era. Quel che conta è che la stessa stringa di caratteri apre la tua email, e la tua email apre tutto il resto tramite «ho dimenticato la password». **Il peccato originale non è che fosse debole: è che era la stessa.** Una password di trenta caratteri, casuale e perfetta, riusata su due siti vale quanto il peggiore dei due. E tu non decidi come fa l'hash il peggiore dei due. ## Cosa se ne ricava - **Cambiare la password trapelata non basta se l'hai ripetuta.** L'urgenza non è il sito finito sui giornali. Sono gli altri. - **Una password per sito, e che ti sia indifferente dimenticarla.** Se riesci a ricordare tutte le tue password, o ne hai pochissime o sono pessime. - **Il secondo fattore spezza la catena.** Il *credential stuffing* prova `email:password`. Se quello non basta per entrare, l'inventario smette di valere. La tua password trapelata non è nelle mani di un nemico. È in una riga di un file, in mezzo ad altre centinaia di milioni, in attesa che a qualcuno convenga provarla su un sito in più. E l'unica cosa che decide se funzionerà l'hai decisa tu anni fa, quando hai scritto la stessa parola per la seconda volta. --- *Fonti: la fuga di dati di RockYou (dicembre 2009) e il successivo utilizzo di `rockyou.txt` come dizionario d'attacco · Have I Been Pwned e Pwned Passwords, di Troy Hunt · NIST SP 800-63B, sulla verifica delle password contro liste di valori compromessi · l'analisi di Troy Hunt su Collection #1 (gennaio 2019) e le cifre che ha pubblicato · definizione di credential stuffing di OWASP.*