Il generatore giusto, linguaggio giusto. Non tutti i generatori di password si equivalgono, e il linguaggio in cui è scritto il tuo vault non è un dettaglio da ingegneri. Analizziamo entropia, modalità di generazione e perché Rust si impone sotto il cofano. Quando un gestore "genera una password forte", emergono due domande: è davvero imprevedibile? (la qualità della casualità) e che cosa le succede in memoria dopo essere stata mostrata? La prima riguarda le modalità di generazione. La seconda, il linguaggio che fa girare l’applicazione. Questo articolo copre entrambe. ~100 bits password casuale di 16 caratteri (molto forte) ~77 bits passphrase Diceware di 6 parole (EFF) 12,9 bits di entropia aggiunti per parola Diceware (lista da 7 776 parole) Entropia: l’unica misura che conta La forza di una password non si misura dalla sua "complessità" percepita, ma dalla sua entropia : il numero di bit di incertezza per un attaccante. Più combinazioni possibili esistono, più il costo di un attacco brute force esplode. Una password di 16 caratteri scelti dall’intero alfabeto ASCII raggiunge circa 100 bits, cioè il territorio del "molto forte". Un punto cruciale spesso dimenticato: l’entropia vale solo se la fonte di casualità è un CSPRNG (generatore pseudo-casuale crittograficamente sicuro). Un classico Math.random() è prevedibile e invalida tutto il resto. Le buone implementazioni leggono l’entropia dal sistema operativo: /dev/urandom o getrandom(2) su Unix, CNG su Windows. Quattro famiglie di generatori Un buon gestore non offre "un" generatore, ma più modalità adatte all’uso. La regola è: la memorizzabilità si paga in lunghezza . Ecco le quattro famiglie, dalla più densa alla più umana. Il riflesso giusto: adattare l’entropia all’uso Per un account web protetto da una pagina di login con limite di tentativi, l’attaccante è frenato a poche centinaia di prove al secondo: anche 50 bits reggono per tempi geologici. L’entropia in eccesso ha senso solo per segreti offline (chiave di cifratura, seed di un wallet crypto), dove l’attacco può essere parallelizzato su vasta scala. Per questi segreti di altissimo valore, tirare veri dadi fisici (Diceware in senso proprio) resta l’opzione definitiva: elimina ogni dipendenza dalla qualità del CSPRNG o da un browser compromesso. Perché Rust cambia le regole Generare una buona password è metà del lavoro. L’altra metà: non lasciarla in giro . Una volta mostrata o decifrata, la tua password vive nella memoria RAM, ed è lì che il linguaggio dell’applicazione diventa determinante. Microsoft ha riportato che il 70 % delle vulnerabilità di sicurezza che incontra sono bug di memoria (buffer overflow, use-after-free, ecc.). Google ha osservato la stessa proporzione su Chrome e Android. Sono esattamente queste classi di falle che Rust elimina in compilazione , tramite il suo modello di proprietà ( ownership ) e prestito ( borrowing ), senza garbage collector. I numeri di Google sono eloquenti: le vulnerabilità di memoria di Android sono scese da 223 nel 2019 a meno di 50 nel 2024 , passando per la prima volta sotto il 20 % del totale. Il nuovo codice Rust mostra una densità di falle di memoria fino a 1000× inferiore rispetto al codice C/C++ storico, con in più 4× meno rollback e il 25 % di tempo di revisione in meno. 1. Sicurezza della memoria senza garbage collector. Linguaggi come Java o Python sono memory-safe, ma il loro garbage collector libera la memoria in modo non deterministico: un segreto può sopravvivere lì indefinitamente, esposto a un memory dump o a un attacco cold-boot. Rust libera la memoria in modo deterministico, appena il dato non viene più usato. 2. Cancellazione esplicita con zeroize . Rust non garantisce che la memoria liberata venga sovrascritta. La crate zeroize colma questa lacuna: avvolgendo un segreto in Zeroizing , se ne garantisce la sovrascrittura con zeri, tramite una scrittura volatile che il compilatore non può ottimizzare, nel momento esatto in cui esce dallo scope. 3. Un sistema di tipi che impone il buon uso della crittografia. Il sistema di tipi rigoroso di Rust permette di circoscrivere come un dato sensibile può essere usato, e quante volte. Si può, per esempio, modellare una chiave utilizzabile una sola volta, con il compilatore che rifiuta qualsiasi riutilizzo. Onestà tecnica: Rust non è una bacchetta magica Il codice unsafe e le dipendenze di terze parti restano superfici di attacco: Google ha infatti corretto una falla (CVE-2025-48530) in un blocco unsafe di un parser Rust prima di qualsiasi messa in produzione. La sicurezza della memoria è uno strato , non un fine in sé: si combina con una difesa in profondità (KDF robusta come Argon2id, architettura zero-knowledge, blocco automatico, MFA). Cosa pretendere da un gestore Quando scegli, o valuti, un gestore di password, ci sono quattro domande concrete: 1. Il generatore si basa su un CSPRNG di sistema e mostra l’entropia in bits? 2. Offre una modalità passphrase Diceware/EFF per la password principale? 3. La generazione è locale (client-side) , senza transito da un server? 4. Il nucleo sensibile è scritto in un linguaggio memory-safe con cancellazione esplicita dei segreti? Generazione sicura. Un vault progettato per durare. Password ad alta entropia, passphrases memorizzabili e un nucleo pensato per la sicurezza della memoria. Contenuto informativo a scopo educativo. Le statistiche citate (Google/Android, Microsoft, Diceware/EFF) provengono dalle fonti elencate sopra. Gli esempi di codice Rust sono illustrativi e semplificati.