Password di 8 caratteri: quanto ci mette davvero a cadere

Brute force, wordlist e perché 8 caratteri non bastano: tempi calcolati, differenza tra attacco online e offline e cosa fare per le tue password.

Hai scelto quella password anni fa: otto lettere, niente di particolare, la stessa che usavi per metà dei servizi. Poi arriva la notifica di una violazione di dati e, cercando in rete, trovi la frase che circola ovunque: una password così si indovina in pochi secondi. La frase è vera in un caso preciso e falsa in quasi tutti gli altri. A decidere sono due cose che dall’esterno non vedi: dove avviene l’attacco e come il servizio ha salvato la tua password.

Risposta breve: una password di 8 lettere minuscole si può provare in tutte le combinazioni in circa un secondo, ma solo se l’attaccante possiede già una copia rubata del database e il servizio la protegge con un algoritmo pensato per essere veloce, come MD5. Contro il modulo di accesso di un servizio ben fatto non funziona, perché i tentativi sono limitati. Contro un algoritmo lento come bcrypt o Argon2id i tempi salgono di molti ordini di grandezza. E le password scelte da persone cadono prima di quelle casuali, perché chi attacca parte dalle più probabili.

L’articolo parte dai due scenari di attacco, passa a come si conservano le password e arriva ai numeri, con una tabella nella sezione «Brute force: i numeri». Poi trovi le wordlist, le regole di decisione e cosa fare. Una nota di metodo: i tempi sono calcoli miei su ipotesi dichiarate, non test miei, e la velocità dell’hardware viene da un benchmark di terzi. Non ci sono istruzioni per attaccare un sistema, né link affiliati, né prodotti consigliati.

Attacco online e attacco offline: due problemi diversi

Nell’attacco online chi attacca prova le password una alla volta davanti al servizio: il modulo di accesso, un’app, un’API. Il servizio vede ogni tentativo e può reagire: rallentare, bloccare l’account, chiedere una verifica. La guida NIST SP 800-63B-4 sull’autenticazione digitale (pagina datata agosto 2025) prevede che il servizio limiti i tentativi falliti consecutivi su un account a non più di 100, con la possibilità di imporre soglie più severe.

Cento tentativi contro una password casuale di 8 caratteri scelti fra 95 simboli stampabili hanno una probabilità di successo dell’ordine di una su 66.000 miliardi (calcolo mio: 100 diviso circa 6,6 milioni di miliardi di combinazioni). Contro un servizio con limiti, indovinare a caso non è una strategia.

Cambia tutto se la password non è casuale. Se è tra le più comuni, i primi cento tentativi possono bastare, perché chi attacca prova per prime le password più probabili. È il motivo per cui NIST chiede ai servizi di confrontare ogni nuova password con una blocklist di valori comuni, già trapelati o legati al servizio stesso, e di respingere quelli che ci compaiono.

Nell’attacco offline il servizio non c’è più. L’attaccante ha ottenuto il file con le password conservate, di solito un database sottratto in una violazione, e lavora sul proprio computer: nessun limite ai tentativi, nessun registro degli accessi falliti, nessun blocco. L’unico freno è la velocità con cui il suo hardware calcola l’algoritmo che protegge la password. È in questo scenario che nascono i «pochi secondi».

💡 Consiglio pratico — Come distinguere i due casi
Se tra te e l’attaccante c’è ancora il servizio, contano i limiti ai tentativi e la blocklist. Se il database è già uscito, contano solo due cose: l’algoritmo con cui è protetto e la tua password.

Come un servizio conserva la tua password, e perché cambia tutto

Un servizio ben progettato non conserva la tua password. Conserva il risultato di una funzione di hash: un calcolo a senso unico che trasforma qualunque testo in una stringa di lunghezza fissa e da cui, in pratica, non si risale al testo originale. Quando accedi, il servizio calcola l’hash di ciò che scrivi e lo confronta con quello salvato. Se coincidono, la password è giusta. Se vuoi vedere come funziona un hash, puoi provarlo con lo strumento per confrontare gli hash.

Chi ruba un elenco di hash non può «decifrarli». Può però provare password candidate, calcolarne l’hash e vedere se coincide con uno di quelli rubati. Il brute force offline è questo, niente di più misterioso.

Qui entrano due ingredienti. Il primo è il sale (salt): un valore casuale diverso per ogni password, conservato accanto all’hash e mescolato alla password prima del calcolo. NIST richiede un sale di almeno 32 bit, scelto in modo da evitare che due account finiscano con lo stesso hash. Il secondo è il fattore di costo: una funzione di hash per password è lenta di proposito, così che ogni tentativo costi caro a chi ne deve fare miliardi. NIST indica di tenere il fattore di costo il più alto possibile senza compromettere le prestazioni del servizio, e di aumentarlo nel tempo.

MD5 e SHA-256 nascono per altro, per esempio verificare l’integrità di un file, e sono veloci per progetto. La guida OWASP sulla conservazione delle password indica come algoritmi adatti Argon2id, bcrypt e PBKDF2 e avverte che gli algoritmi veloci come SHA-256 non vanno bene, perché permettono di fare moltissimi tentativi in poco tempo. Lo vedrai nei numeri: sullo stesso hardware, tra un algoritmo veloce e uno lento passano circa sette ordini di grandezza.

Perché il sale non rallenta l’attacco, ma impedisce di lavorare in serie

È un equivoco comune: il sale non rende più lento il calcolo di un singolo tentativo. Cambia un’altra cosa. Senza sale, due utenti con la stessa password hanno lo stesso hash. L’attaccante calcola ogni candidato una sola volta e lo confronta con tutti gli account insieme, oppure riusa tabelle di hash calcolate in anticipo. Con un sale diverso per ciascun account, lo stesso candidato produce un hash diverso per ogni utente, e il lavoro va rifatto account per account. Il sale elimina l’economia di scala; il rallentamento per tentativo lo dà il fattore di costo. Servono entrambi.

NIST raccomanda anche un passaggio in più: un’ulteriore iterazione con una chiave segreta, conservata separatamente dagli hash, in modo che il solo database rubato non basti.

Per te la conseguenza è pratica: non sai quale algoritmo usa un servizio né se la sua configurazione è aggiornata. Per quanto ne so, di solito non lo dichiarano nelle pagine pubbliche. Per questo conviene scegliere la password come se potesse capitare il caso peggiore.

Brute force: i numeri

Brute force significa provare tutte le combinazioni possibili fino a trovare quella giusta. Il numero di combinazioni, lo spazio, è il numero di simboli ammessi elevato alla lunghezza: 26 lettere minuscole su 8 posizioni fanno 26⁸, circa 209 miliardi di combinazioni.

Per sapere quanto ci vuole serve la velocità dell’attaccante. Un benchmark pubblico di hashcat, un programma di recupero password molto usato, su una RTX 5090 (scheda grafica per il mercato consumer) riporta circa 220,6 miliardi di calcoli al secondo per MD5, 28,35 miliardi per SHA-256 e 304,8 mila per bcrypt. L’ultimo valore è misurato con l’impostazione di costo bassa del benchmark (2⁵ iterazioni). Con costo 10, il valore minimo che OWASP indica per i sistemi che usano bcrypt, ogni tentativo richiede 32 volte il lavoro e la velocità scende a circa 9.500 al secondo (stima mia, ottenuta scalando il dato).

Il benchmark è un dato di terzi, pubblicato a febbraio 2025 su GitHub da un contributore del progetto, e i valori dipendono da driver e configurazione: prendili come ordine di grandezza. Le ipotesi del calcolo sono queste: password casuali con tutti i simboli equiprobabili, una sola scheda grafica, esplorazione dell’intero spazio (in media se ne percorre metà, quindi i tempi medi sono la metà) e nessuna ottimizzazione. Sono calcoli, non misure.

Come leggere la tabella: tre cose saltano all’occhio.

La prima è che la stessa password cade in un secondo o in 254 giorni a seconda dell’algoritmo. Il «pochi secondi» è vero nella prima riga e nelle prime due colonne, e vale solo lì.

La seconda è che contro un hash veloce, 8 caratteri scelti fra 95 simboli reggono ore con MD5 e giorni con SHA-256 su una scheda sola. Chi ne ha dieci riduce i tempi grosso modo di dieci volte (ipotesi di scala lineare).

La terza è che la lunghezza pesa più della varietà. 12 lettere minuscole offrono circa 14 volte più combinazioni di 8 caratteri su 95 simboli (9,5 × 10¹⁶ contro 6,6 × 10¹⁵), anche se usano soltanto un alfabeto di 26 simboli.

Lo stesso calcolo vale per le passphrase. Quattro parole scelte a caso da una lista di 7.776 (il formato del metodo Diceware) offrono circa 3,7 × 10¹⁵ combinazioni, simili a 8 caratteri su 95 simboli. Con sei parole si arriva a circa 2,2 × 10²³ combinazioni. La condizione è che le parole le scelga un generatore casuale: se le inventi tu, la tabella non vale più.

Wordlist e regole: perché le password scelte da persone cadono prima

Il brute force puro ha un difetto per chi attacca: tratta tutte le combinazioni come ugualmente probabili, e le persone non scelgono a caso. Per questo si usano le wordlist, elenchi di password da provare per prime. NIST descrive il contenuto di una blocklist con tre famiglie: password uscite in violazioni precedenti, parole di dizionario e parole di contesto, come il nome del servizio, il nome utente e i loro derivati. Per come la vedo, le liste degli attaccanti seguono la stessa logica, ma questa è una mia inferenza.

Alle liste si aggiungono le regole di trasformazione: variazioni prevedibili come una maiuscola iniziale, una cifra o un simbolo in fondo, una lettera sostituita da un numero. Il meccanismo sta qui: applicare in automatico ciò che molte persone fanno per «rendere più forte» una parola.

Il risultato pratico è che lo spazio da esplorare per una password scelta da una persona è molto più piccolo di quello teorico. Non ho un dato verificato su quanto più piccolo: dipende dalla persona, dalla lista e dalle regole usate, e non intendo inventarlo. Posso mostrarti il meccanismo con un esempio ipotetico.

Prendi «Password1!». Rispetta le regole di composizione che molti servizi hanno chiesto per anni: maiuscola, minuscola, cifra, simbolo, almeno otto caratteri. Contro un brute force puro sembra solida, perché è lunga 10 caratteri su un alfabeto di 95 simboli. Contro una lista con regole è una parola di dizionario con maiuscola iniziale, un 1 e un punto esclamativo, una struttura che quel tipo di attacco può coprire fra i primi tentativi.

Secondo me, le regole del tipo «una maiuscola, un numero, un simbolo» hanno spinto molti a scegliere tutti la stessa forma. È un’opinione, non un dato. Il fatto verificato è un altro: nella SP 800-63B-4 NIST vieta ai servizi di imporre altre regole di composizione, oltre alla lunghezza minima e al controllo sulla blocklist.

⚠️ Attenzione — Una password lunga ma già trapelata non serve
Se compare in un elenco di violazioni, nessuna wordlist deve nemmeno indovinarla, perché è già nota. Se un servizio ti avvisa che la tua password è comparsa in una violazione, cambiala su quel servizio e ovunque l’avevi riusata. Per controllare puoi seguire la guida su come sapere se email e password sono compromesse.

Perché 8 caratteri «semplici» non bastano, e quando 8 possono bastare

Ecco tre regole di decisione, ciascuna con il suo motivo.

Se la password protegge un account su un servizio di cui non conosci la conservazione, scegline una lunga. Il minimo che NIST impone ai servizi quando la password è l’unico fattore è 15 caratteri. Il motivo: se il database esce, l’unica difesa è lo spazio delle combinazioni, e dalla tabella si vede che qualche carattere in più pesa più di qualunque simbolo aggiunto.

Se la password protegge qualcosa che si attacca offline per costruzione, scegli la più lunga che riesci a gestire. Sono casi come la password principale di un gestore di password o la chiave di un disco cifrato: se qualcuno ottiene il file, l’attacco è offline per definizione. Come questi prodotti trasformano la password in chiave cambia da prodotto a prodotto, quindi controlla la documentazione del tuo.

Se la password è solo uno dei fattori e il servizio ha limiti ai tentativi, blocklist e secondo fattore, 8 caratteri sono accettabili per NIST. Lo standard ammette password più corte, con un minimo di otto caratteri, quando fanno parte di un’autenticazione a più fattori. È una soglia per chi progetta il servizio, calibrata sul fatto che gli altri controlli ci sono. Non è un obiettivo per chi sceglie la propria password.

L’obiezione più forte è questa: «i siti bloccano dopo pochi tentativi, quindi 8 caratteri bastano». È vera per l’attacco online, ed è il motivo per cui NIST la considera accettabile in quel caso. Lascia scoperte due strade: la fuga del database, dove i limiti non esistono, e il riuso, dove la password è già nota a chi attacca (ne parlo nel pezzo sul credential stuffing). Si aggiunge che le password non sono resistenti al phishing, come ricorda lo stesso NIST: se te la fanno scrivere in un sito falso, non c’è nulla da indovinare.

Cosa fare, in ordine di effetto

1. Una password diversa per ogni servizio. È il passo che pesa di più: dopo la fuga di un servizio, una password riusata altrove è già nota a chi attacca.
2. Lunga e casuale, generata da un gestore di password. NIST osserva che i gestori aumentano la probabilità di scegliere password più forti, soprattutto se includono un generatore, e impone ai servizi di consentirne l’uso e il copia-incolla. Qui non consiglio un prodotto specifico: per il metodo c’è la guida pratica ai password manager, e per generarne una nel browser il generatore di password.
3. Per ciò che devi ricordare a memoria, una passphrase di parole scelte a caso da un generatore. Vale per la password principale del gestore e per lo sblocco del computer. Sei parole, come nella tabella, danno un margine ampio. Evita citazioni, testi di canzoni e frasi che ti riguardano.
4. Un secondo fattore, quando c’è, meglio se resistente al phishing. NIST cita WebAuthn, lo standard su cui si basano le passkey, come esempio di metodo che lega l’autenticazione al dominio del servizio, e indica l’uso della rete telefonica per i codici (SMS e chiamate) come autenticatore soggetto a restrizioni. I passi per attivarlo sono nella checklist per 2FA e passkey.

Limiti di questi numeri

I tempi della tabella descrivono un attaccante con una sola scheda grafica uscita nel 2025 e password casuali. Con più schede, hardware noleggiato o modelli più recenti i tempi calano. Con una wordlist e regole contro una password scelta da una persona possono calare molto di più. Il valore di bcrypt a costo 10 è una mia stima per scalare il dato del benchmark, non una misura. I benchmark di terzi non sono ufficiali: conta l’ordine di grandezza, non il singolo numero.

Non ho dati verificati su quanti servizi usino ancora algoritmi veloci per conservare le password. Sarebbe l’informazione per dire quanto spesso lo scenario «pochi secondi» si verifica davvero. Senza, posso dirti che è possibile, non che sia frequente: anche qui conviene distinguere il rischio teorico da quello osservato.

Ultima verifica dei dati: 14 ottobre 2026 (NIST SP 800-63B-4, benchmark hashcat).

Domande Frequenti (FAQ)

Quanto deve essere lunga una password, secondo NIST?

Almeno 15 caratteri se è l’unico fattore, almeno 8 se fa parte di un’autenticazione a più fattori. Lo standard chiede anche ai servizi di accettare password di almeno 64 caratteri, e questo rende praticabili le passphrase. Sono requisiti per i servizi: per le tue password sono un punto di partenza, non un obiettivo.

Conviene cambiare la password ogni tot mesi?

NIST vieta ai servizi di imporre un cambio periodico e chiede di forzarlo quando c’è evidenza di compromissione. Vale la regola pratica: cambiala quando c’è un motivo, per esempio una violazione o un sospetto di accesso.

Posso usare spazi e lettere accentate?

NIST raccomanda ai servizi di accettare tutti i caratteri ASCII stampabili, lo spazio e i caratteri Unicode, contando ogni carattere come uno. Avverte però che alcuni dispositivi possono rappresentare certi caratteri in modo diverso, e questo può impedirti di accedere da un altro dispositivo. Se usi accenti o simboli rari, prova l’accesso da un secondo dispositivo.

A cosa serve il sale se non rallenta l’attacco?

Impedisce di lavorare in serie: con un sale diverso per ogni account, lo stesso tentativo va ricalcolato utente per utente e le tabelle di hash precalcolate non servono. Il rallentamento per singolo tentativo lo dà invece il fattore di costo dell’algoritmo.

Il mio gestore di password è esposto a questi attacchi?

Dipende da come il prodotto trasforma la password principale in chiave di cifratura e da cosa succede se qualcuno ottiene il tuo archivio. Non ho verificato la documentazione di prodotti specifici per questo pezzo. Cercala sul sito del produttore, nella sezione sulla sicurezza, e valuta la lunghezza della password principale come nella seconda regola.