Quando un sito ti dice che la tua password ci metterebbe tre milioni di anni a cadere, sta omettendo la parte importante della frase. La domanda giusta non è quanto ci mette. È quanto ci mette contro cosa.
E la risposta a contro cosa non la decidi tu. L’ha decisa uno sviluppatore del negozio dove nel 2019 hai comprato un paio di scarpe, nel momento in cui ha scelto come salvare la tua password nel suo database. Tu hai scritto la stessa stringa di venti caratteri in entrambi i siti. In uno regge per secoli, nell’altro cade prima di pranzo.
Il numero che manca nell’equazione
Un attacco a forza bruta è aritmetica da quattro soldi: numero di candidati da provare, diviso per i candidati che riesci a provare al secondo. Il primo fattore dipende dalla tua password — la lunghezza, l’alfabeto, se sta o no in un dizionario. Il secondo non ha assolutamente niente a che vedere con te.
Il secondo fattore dipende da due cose: l’hardware di chi attacca e, soprattutto, la funzione con cui il sito ha trasformato la tua password in quel garbuglio di caratteri che tiene nella tabella degli utenti. Quella funzione si chiama hash, e non tutte costano uguale da calcolare.
MD5 e SHA-1 sono state progettate per essere veloci. È un pregio: sono funzioni di hash generiche, pensate per riassumere messaggi e verificare l’integrità, e lì quello che vuoi è macinare un gigabyte senza fare in tempo ad alzarti per il caffè. Quando qualcuno le usa per conservare password, quel pregio diventa il problema. Una funzione che puoi calcolare milioni di volte al secondo è una funzione che anche l’attaccante può calcolare milioni di volte al secondo — e lui ha le schede grafiche e tutto il fine settimana davanti.
bcrypt e Argon2 sono nate con l’obiettivo opposto. Sono lente apposta e — qui sta l’eleganza — con lentezza regolabile. Niels Provos e David Mazières hanno presentato bcrypt nel 1999 con un titolo che dice tutto: A Future-Adaptable Password Scheme. L’idea era che la funzione potesse rincarare negli anni, allo stesso ritmo con cui l’hardware diventava più economico. Argon2, che ha vinto la Password Hashing Competition nel 2015, ha aggiunto un altro giro: non costa solo tempo, costa memoria, che è esattamente la cosa che le GPU hanno sottomano con meno entusiasmo.
Tra un hash veloce e un hash lento ben configurato non c’è una differenza di percentuali. Ci sono ordini di grandezza. Tanti.
I benchmark esistono, e sono pubblici
Niente di tutto questo è speculazione. Hashcat, lo strumento che usa mezzo mondo per rompere password — i buoni compresi —, ha una modalità di benchmark che chiunque può lanciare sulla propria macchina e che misura, algoritmo per algoritmo, quante volte al secondo se ne può calcolare uno. La comunità pubblica quelle tabelle ogni volta che esce una GPU nuova.
La cosa interessante di quelle tabelle non è nessun numero preciso — che oltretutto scade a ogni generazione di hardware — ma la distanza tra le righe. Ordini la lista per velocità e vedi MD5 in cima, su un pianeta tutto suo. Scendi, scendi ancora, e in fondo alla tabella ci sono bcrypt e Argon2, con cifre che non somigliano a niente di quello che hai letto sopra. È la stessa password. È la stessa GPU. L’unica cosa cambiata è come ha deciso di conservarla il sito.
Per questo «tre milioni di anni» senza dire contro quale hash è marketing, non una misura. È come annunciare che la tua auto ci mette sei ore ad arrivare senza dire dove.
Offline e online: due mondi che non si toccano
C’è una seconda distinzione che quasi nessuno spiega e che cambia il risultato in modo altrettanto brutale.
In un attacco online, l’attaccante prova le password contro il modulo di accesso, come farebbe un utente qualsiasi. Il ritmo non lo detta il suo hardware: lo detta il server. Ci può essere un limite di tentativi, un blocco temporaneo, un captcha, un ritardo tra le richieste, un avviso quando arrivano mille errori dallo stesso indirizzo. Contro un sito difeso in modo decente, un attacco online è lento, rumoroso e piuttosto stupido. L’aritmetica è così sfavorevole per l’attaccante che la forza bruta pura quasi non si tenta: si provano le solite quattro password contro milioni di account, che è un altro gioco.
In un attacco offline, l’attaccante ha già il dump del database. Se lo porta a casa. Lì non c’è nessun server, nessun limite di tentativi, nessuno che guarda: ci sono le sue schede grafiche e la sua bolletta della luce. Può provare per mesi senza che nessuno se ne accorga, e capirà da solo di averci azzeccato, confrontando hash. È qui che l’hash decide tutto, perché l’hash è letteralmente l’unica cosa che lo rallenta.
E conviene essere onesti sulle probabilità: lo scenario offline non è esotico. È quello che succede ogni volta che un database finisce in giro. Quando LinkedIn ha perso il suo, nel 2012, l’analisi del dump trapelato ha mostrato che le password erano salvate con SHA-1 senza sale: un hash veloce e privo dell’ingrediente che impedisce di precalcolare le tabelle. Che ne siano cadute così tante e così in fretta non è stato solo perché gli utenti sceglievano male. È stata, soprattutto, una decisione di ingegneria che nessun utente ha mai visto.
Cosa facciamo qui, e perché lo diciamo
Il nostro strumento di controllo assume 10¹² tentativi al secondo, offline, contro un hash veloce. È scritto nella pagina stessa, sotto il risultato, e non per trasparenza decorativa: senza quel dato, il tempo che ti mostra non significa niente.
È deliberatamente lo scenario peggiore. Diamo per scontato che il database sia già trapelato, che l’attaccante abbia hardware serio, che il sito abbia conservato la tua password nel peggior modo ragionevolmente possibile e che per giunta conosca il tuo alfabeto e la tua lunghezza. Se il sito ha usato bcrypt ben configurato, la cifra reale sale di parecchi ordini di grandezza e la tua password regge molto più a lungo di quanto ti diciamo.
Preferiamo sbagliare da questa parte. Un controllo che ti fa i complimenti li sta facendo a se stesso.
La conclusione scomoda
La tua password non ha un tempo di rottura. Ne ha uno per ogni sito in cui l’hai usata, e quel tempo lo fissa gente che non conosci con criteri che non pubblica.
Da cui si deducono due cose, e sono sempre le stesse. La prima: siccome l’hash non lo puoi controllare, controlla l’entropia, che è la metà dell’equazione che sì è tua — per questo il generatore ti mostra i bit e non una percentuale rassicurante. La seconda, e più importante: se ogni sito ha la sua password, quello che l’ha salvata in MD5 può regalare soltanto quella di quel sito.
Perché l’anello debole non è la tua password. È il peggior sito in cui l’hai scritta.
Fonti: benchmark pubblici di hashcat (hashcat -b), consultabili e riproducibili · N. Provos e D. Mazières, «A Future-Adaptable Password Scheme», USENIX, 1999 · Password Hashing Competition, vinta da Argon2 nel 2015 · il modello di minaccia dichiarato nello strumento di controllo di password.es: 10¹² tentativi/s, offline, hash veloce · violazione di LinkedIn del 2012: l’azienda ha confermato la fuga di dati, e l’uso di SHA-1 senza sale è stato accertato analizzando il dump pubblicato.