Generatore di password in blocco gratuito

Generazione di password in batch

Questo strumento genera più password crittograficamente robuste in un'unica operazione. Perfetto per preparare liste per l'onboarding di un team, la creazione di massa di account o la gestione di inventari di password. Ogni password viene prodotta tramite il generatore casuale integrato del browser.

Livelli di robustezza

• Debole · 8-11 caratteri: protezione di base, da evitare per gli account sensibili
• Discreto · 12-15 caratteri: protezione moderata, accettabile per molti usi
• Buono · 16-19 caratteri: protezione forte, raccomandato per la maggior parte degli account
• Molto forte · 20 caratteri o più: protezione massima, ideale per i sistemi critici

Domande frequenti

Queste password sono davvero casuali?

Sì. Le password sono generate con window.crypto.getRandomValues(), che fornisce valori casuali crittograficamente sicuri, adatti agli usi di sicurezza.

Posso generare più di 100 password?

Lo strumento limita la generazione a 100 alla volta per evitare di rallentare il browser. Genera più lotti separatamente se necessario.

Come archiviare il file scaricato?

Conserva il file .txt in una posizione sicura, preferibilmente cifrata. Non fare mai il commit in un repository di codice né condividerlo tramite canali non sicuri. Eliminalo dopo la distribuzione agli utenti.

Da dove vengono i buoni numeri casuali

Un computer è, per progettazione, deterministico. Dati gli stessi input e lo stesso codice, produce gli stessi output ogni volta. È esattamente la proprietà che vuoi da una CPU che esegue un foglio di calcolo, ed esattamente la proprietà che non vuoi da un generatore di password. Se un attaccante può riprodurre la sequenza di valori emessa dal generatore, può riprodurre ogni password che esso abbia mai prodotto.

Quindi il generatore raccoglie «entropia» (segnale fisico imprevedibile proveniente dall'esterno del programma) e la usa per inizializzare un algoritmo chiamato CSPRNG (generatore di numeri pseudocasuali crittograficamente sicuro). Il «pseudo» è onesto: i bit sono prodotti da un algoritmo, non dalla fisica. Il «crittograficamente sicuro» significa che persino un attaccante che vede una lunga serie di output passati non può prevedere il byte successivo meglio del caso. Theodore Ts'o implementò /dev/random nel kernel Linux nel 1994, e macOS, i BSD, Solaris e Windows (con BCryptGenRandom) adottarono tutti interfacce equivalenti. Sotto il cofano questi mescolano ogni plausibile sorgente di jitter fisico (la temporizzazione della ricerca su disco, gli arrivi dei pacchetti di rete, l'input da tastiera e mouse, gli interrupt hardware, RDRAND sulle CPU Intel che ce l'hanno) attraverso un hash crittografico, poi reinizializzano continuamente.

Nel browser, la Web Cryptography API del W3C la espone tramite window.crypto.getRandomValues(typedArray): passale un array tipizzato e il browser lo riempie di byte casuali crittograficamente robusti. Il massimo per chiamata è 65.536 byte (questo strumento resta ben al di sotto). L'API è supportata di base su Chrome, Firefox, Safari ed Edge da luglio 2015: non c'è alcuna possibilità realistica che un utente arrivi su questo strumento con un browser che ne sia privo.

L'entropia delle password, la matematica vera

La «forza» di una password, nel senso crittografico formale, si misura in bit di entropia. La formula standard per una password generata casualmente è:

Entropia = L × log₂(R)

dove L è la lunghezza in caratteri e R è la dimensione dell'insieme di caratteri. Entropia per carattere in base al set di caratteri:

• Solo cifre (0-9): 10 caratteri → 3,32 bit/carattere
• Solo minuscole (a-z): 26 → 4,70 bit/carattere
• Minuscole + maiuscole (A-Za-z): 52 → 5,70 bit/carattere
• Minuscole + maiuscole + cifre (alfanumerico): 62 → 5,95 bit/carattere
• Tutto l'ASCII stampabile escluso lo spazio: 94 → 6,55 bit/carattere

Vale la pena fissare il numero 94: i codici ASCII da 32 a 126 sono i caratteri stampabili (95 in totale); escludendo lo spazio restano 94 glifi visibili diversi dallo spazio (26 minuscole + 26 maiuscole + 10 cifre + 32 segni di punteggiatura/simboli). Inserendo numeri concreti nella formula:

• 8 caratteri × 6,55 ≈ 52,4 bit: rapida da forzare con la forza bruta su hardware moderno
• 12 caratteri × 6,55 ≈ 78,6 bit: al limite, appena sotto la soglia degli 80 bit
• 16 caratteri × 6,55 ≈ 104,8 bit: sopra i 100, nel territorio accettabile per l'ANSSI
• 20 caratteri × 6,55 ≈ 131,0 bit: oltre la soglia equivalente ad AES-128
• 32 caratteri × 6,55 ≈ 209,6 bit: esagerata per qualsiasi avversario concepibile

La comunità crittografica si è assestata su tre soglie: 80 bit come minimo assoluto (la base raccomandata dal NIST fino al 2014), raggiunti a ~13 caratteri con il set completo di 94 caratteri; 100 bit richiesti dall'ANSSI (l'equivalente francese dell'NSA) per le password che proteggono i sistemi di cifratura, raggiunti a ~16 caratteri; e 128 bit corrispondenti alla forza della chiave simmetrica di AES-128, raccomandati per le password principali dei vault, raggiunti a ~20 caratteri.

L'enorme avvertenza: questa matematica vale solo per le password casuali. Se la password l'ha scelta un essere umano, l'entropia effettiva è molto, molto più bassa. L'attaccante non enumera le stringhe R^L in ordine alfabetico: esegue un programma di tentativi inizializzato con elenchi di password trapelate, parole di dizionario, sostituzioni comuni (a→@, o→0, s→$), sequenze di tasti e modelli statistici di come gli esseri umani costruiscono stringhe memorizzabili. Lo studio del 2012 di Joseph Bonneau su un corpus anonimizzato di 70 milioni di password Yahoo (IEEE Symposium on Security and Privacy) ha rilevato che le password scelte dagli utenti offrono «meno di 10 bit di sicurezza contro un attacco di setacciamento online e solo circa 20 bit contro un attacco offline ottimale a dizionario.» Venti bit sono un milione di tentativi. Una GPU moderna lo fa in microsecondi.

NIST SP 800-63B, cosa è cambiato nel 2017 e di nuovo nel 2025

Per circa trent'anni, la politica di sicurezza nordamericana sulle password è discesa da una pubblicazione NIST del 1985 che raccomandava la rotazione periodica forzata, classi di caratteri miste e lunghezze minime brevi. Bill Burr, autore del seguito del 2003 che codificò la regola «maiuscola + minuscola + cifra + simbolo, cambiala ogni 90 giorni», la ritrattò pubblicamente nel 2017, dichiarando al Wall Street Journal che «molto di ciò che ho fatto, ora me ne pento.» Il NIST formalizzò il dietrofront lo stesso anno.

NIST SP 800-63B Rev 3 (giugno 2017) introdusse due cambiamenti generazionali. La Sezione 5.1.1.2 recita: «I verificatori NON DOVREBBERO richiedere che i segreti memorizzati vengano cambiati in modo arbitrario (ad es. periodicamente)», perché le rotazioni forzate inducono gli utenti a scegliere password più deboli e prevedibili. La stessa sezione: «I verificatori NON DOVREBBERO imporre altre regole di composizione (ad es. richiedere combinazioni di tipi di caratteri diversi) per i segreti memorizzati», perché obbligare a una cifra e un simbolo spinge gli utenti verso Password1! anziché verso una passphrase più lunga. La Rev 3 fissò la lunghezza minima scelta dall'abbonato a 8 caratteri, impose ai verificatori di accettarne fino a 64, rese obbligatorio il controllo delle nuove password rispetto a blocklist di violazioni e richiese esplicitamente che fossero consentiti i gestori di password e gli incolla dagli appunti.

NIST SP 800-63B Rev 4 (finalizzata il 31 luglio 2025) ha alzato l'asticella: le password a fattore singolo ora richiedono un minimo di 15 caratteri («I verificatori e i CSP DEVONO richiedere che le password usate come meccanismo di autenticazione a fattore singolo abbiano una lunghezza minima di 15 caratteri»). Le password multifattore restano a 8 caratteri perché il secondo fattore porta il peso della sicurezza. Le regole di composizione sono ancora vietate, e la formulazione è passata dal «SHOULD NOT» della Rev 3 al «SHALL NOT» della Rev 4, rendendola un requisito vincolante anziché una raccomandazione. La rotazione è ancora sconsigliata a meno che non vi siano prove di compromissione.

Lo strumento di Absolutool usa per impostazione predefinita 16 caratteri con tutte e quattro le classi di caratteri, dando all'incirca 104 bit di entropia e superando comodamente sia il minimo di 15 caratteri della Rev 4 sia la soglia di equivalenza simmetrica di 80 bit. Il massimo dello strumento, 128 caratteri, è esattamente il doppio della lunghezza massima che il NIST impone ai verificatori di accettare: non c'è alcun caso realistico in cui una password generata risulti troppo lunga perché un server la accetti.

RockYou, il disastro che ancora perseguita il 2026

Nel dicembre 2009, l'azienda di giochi social RockYou subì una violazione tramite una SQL injection da manuale. La violazione espose oltre 32 milioni di account utente, comprese le password di quegli account in chiaro: RockYou le aveva memorizzate non cifrate. La policy delle password dell'azienda all'epoca richiedeva solo cinque caratteri e vietava i caratteri speciali, il che aveva aggravato la vulnerabilità.

Il file violato, presto soprannominato rockyou.txt, fu pubblicato apertamente e resta la wordlist di password più citata al mondo. È incluso per impostazione predefinita in Kali Linux per i penetration tester; ogni strumento di attacco a dizionario del pianeta vi si confronta; i servizi commerciali di credential stuffing lo mantengono come riferimento di base. A sedici anni di distanza, gli attaccanti catturano ancora account attivi che usano password comparse per la prima volta nella fuga del 2009. Le lezioni che si sono diffuse: i server non dovrebbero mai vedere le password in chiaro (questo strumento genera lato client, quindi il server non le vede affatto); le password memorizzate dovrebbero essere sottoposte a hashing con una funzione lenta, con sale e memory-hard come Argon2id o bcrypt, non con un hash veloce come MD5 o SHA-1 senza sale; password uniche per ogni sito sono l'unica difesa contro l'attacco di replay con credenziali rubate che ha dominato l'ultimo decennio di violazioni.

Have I Been Pwned e il corpus delle violazioni

Have I Been Pwned (HIBP), gestito dal Microsoft Regional Director Troy Hunt, è diventato la fonte autorevole standard per «questa password è comparsa in una violazione?» Hunt lanciò HIBP nel 2013 come indice ricercabile di indirizzi e-mail violati; in seguito aggiunse il corpus Pwned Passwords, un elenco scaricabile di ogni password vista in una violazione pubblica, indicizzato per hash SHA-1. Pwned Passwords V2 fu lanciato il 22 febbraio 2018 e introdusse l'API a k-anonimato del dataset (realizzata con Cloudflare): un client invia solo i primi cinque caratteri dell'hash SHA-1; il server restituisce ogni hash completo che inizia con quei cinque caratteri insieme al numero di volte che è stato osservato; il client confronta localmente. La password (e persino il suo hash completo) non lascia mai il dispositivo dell'utente.

Per un generatore in blocco, la rilevanza è duplice. Qualsiasi password già presente in HIBP non è, per definizione, una nuova password utile: sarà la prima cosa che proverà qualsiasi attaccante di credential stuffing. E poiché questo strumento genera con piena casualità CSPRNG da un alfabeto di 94 caratteri, la probabilità che una password di 16 caratteri appena generata sia già in HIBP è, a fini pratici, nulla. (Il numero totale di password di 16 caratteri con simboli ASCII è 94^16 ≈ 3,7 × 10³¹; HIBP contiene all'incirca 10⁹ password note; probabilità di collisione ≈ 10⁻²².)

Cosa significano davvero gli «X bit di entropia» in tempo di violazione effettivo

Il numero che dà un significato concreto ai bit di entropia è «quanto tempo servirebbe a un attaccante moderno?», e la risposta dipende interamente dall'algoritmo di hash. Il benchmark pubblicato dalla community per hashcat v6.2.6 su una singola Nvidia RTX 4090 registra all'incirca 300 GH/s per gli hash NTLM (il vecchio hash Windows di Microsoft) e 200 kH/s per bcrypt. Il divario di quattro ordini di grandezza tra i due è il fatto portante: NTLM è stato progettato per la velocità, bcrypt è stato progettato per essere lento.

Le ampiamente citate tabelle delle password di Hive Systems trasformano i benchmark in numeri di tempo di violazione. La versione 2025 calcolata sugli hash MD5 (quasi veloci quanto NTLM) dà ~59 minuti su una RTX 4090 per forzare con la forza bruta una password di 8 caratteri dal set di caratteri completo. La stessa password di 8 caratteri contro un hash bcrypt richiede ~99 anni sullo stesso hardware. Quel divario di quattro ordini di grandezza è la differenza tra «trapelata ieri, violata entro pranzo» e «trapelata ieri, ti sopravvivrà.»

L'utente finale controlla la lunghezza e il set di caratteri della password. Non controlla l'algoritmo di hash che il server usa per memorizzarla. La maggior parte dei servizi moderni ben gestiti usa bcrypt, scrypt o Argon2id, tutti deliberatamente lenti. I servizi più vecchi e i servizi violati hanno usato spesso MD5 o SHA-1 senza sale, ed è per questo che i vecchi corpus di violazioni possono essere violati alle velocità citate sopra. Per una password generata da questo strumento: una password casuale di 16 caratteri è al sicuro da bcrypt essenzialmente per sempre e abbastanza al sicuro da MD5 per ora; una password di 20 caratteri è esagerata contro entrambi. Non esiste un modello di minaccia realistico in cui 20+ caratteri di output CSPRNG siano l'anello debole.

FIDO2, WebAuthn e la transizione alle passkey

La previsione più longeva del settore della sicurezza è che le password stiano scomparendo. Dal 2019 ha finalmente un sostituto credibile: le passkey, il nome di marketing per il consumatore delle credenziali emesse secondo gli standard FIDO2 / WebAuthn. WebAuthn Level 1 è diventato una W3C Recommendation il 4 marzo 2019; il Level 2 è seguito l'8 aprile 2021. Il modello crittografico è asimmetrico: quando un utente si registra, l'autenticatore genera una coppia di chiavi pubblica/privata, invia la chiave pubblica al server e memorizza la chiave privata in hardware locale sicuro. L'autenticazione usa una sfida-risposta firmata con la chiave privata. Il server non vede mai il segreto, il che significa che una violazione lato server non può esporre le credenziali di accesso.

Il lancio sulle principali piattaforme procedette di pari passo nel 2022-2023: Apple presentò le passkey al WWDC il 6 giugno 2022 e le distribuì pubblicamente con iOS 16, iPadOS 16 e macOS Ventura a settembre 2022, con sincronizzazione tramite il Portachiavi iCloud cifrato end-to-end. Google annunciò il supporto alle passkey per Android e Chrome il 12 ottobre 2022; il supporto stabile in Chrome arrivò con Chrome 108 a dicembre 2022, con sincronizzazione tramite Google Password Manager. Microsoft annunciò la gestione delle passkey per Windows 11 il 21 settembre 2023, integrata con Windows Hello.

Le passkey risolvono le classi più dolorose di fallimento delle password (phishing, credential stuffing, violazione del server), ma non hanno eliminato le password perché: molti siti e la maggior parte dei sistemi legacy ne richiedono ancora una; le passkey sono legate a un dispositivo o a un ecosistema di sincronizzazione (gli utenti senza un account Apple, Google o Microsoft hanno bisogno di un'alternativa); i sistemi headless (dispositivi IoT, account di servizio lato server, scenari di onboarding in blocco) non possono affidarsi a un autenticatore biometrico nella fase di registrazione; e molte policy aziendali sulle password, sistemi bancari e portali governativi impongono ancora le password. La generazione di password in blocco rientra in pieno nella seconda e terza categoria: un amministratore di sistema che predispone 50 nuovi account non può chiedere a ogni futuro utente di registrare una passkey prima che l'account esista.

Perché la generazione lato client conta in modo specifico

Immagina uno strumento concorrente che invia con POST la richiesta dell'utente a un server, il server esegue il generatore casuale e restituisce l'elenco come JSON. Anche se tutto funziona come pubblicizzato, i seguenti soggetti possono vedere le password generate in chiaro: la memoria di processo del server mentre la richiesta viene gestita; i log delle richieste del server (se il logging è ingenuo); qualsiasi servizio di APM o di tracciamento degli errori a cui il server è collegato; il reverse proxy che termina il TLS (Cloudflare, il bilanciatore di carico AWS, nginx); qualsiasi strumento di debug in esecuzione sul server; qualsiasi futuro attaccante che ottenga l'accesso a uno qualunque di quei log. Si applica il modello RockYou, con tutte le sue conseguenze.

Quando la generazione avviene tramite window.crypto.getRandomValues() nel browser dell'utente, niente di tutto ciò si applica. I byte sono prodotti all'interno del processo del browser, sulla macchina dell'utente, da codice che l'utente può verificare (il sorgente della pagina è consultabile). Non attraversano mai la rete. Il server di Absolutool non li vede mai, non li registra mai e non può farli trapelare in una futura violazione perché non li ha mai avuti. Gli unici soggetti che vedono le password generate sono l'utente, chiunque abbia accesso alla sessione del browser dell'utente (di norma solo l'utente) e qualsiasi estensione del browser in esecuzione sulla pagina. Questo è lo stesso modello di sicurezza del generatore locale di un gestore di password, e più robusto del modello di qualsiasi servizio web che restituisce password generate da un server.

Mirai 2016, l'esempio negativo per le impostazioni predefinite dell'IoT

L'esempio negativo da manuale di «usiamo semplicemente la stessa password predefinita su ogni unità» è la botnet Mirai. Mirai sfruttò un elenco hardcoded di circa 62 combinazioni di nome utente/password predefinite dei produttori (admin/admin, root/root, root/xc3511, root/vizxv) per infettare centinaia di migliaia di telecamere IP, DVR e router domestici alla fine del 2016, poi le usò il 21 ottobre 2016 per mettere fuori uso il grande provider DNS Dyn, mettendo brevemente KO Twitter, Reddit, Netflix e GitHub. Un generatore di password in blocco è esattamente la primitiva giusta per l'alternativa: produrre una password predefinita robusta e unica per ogni unità sulla linea di produzione, stamparla su un adesivo, spedirla dentro la scatola.

Altre domande

Perché il NIST raccomanda la lunghezza rispetto alla complessità?

Perché obbligare alla complessità (una cifra, un simbolo, una lettera maiuscola) spinge gli utenti verso schemi prevedibili che l'attaccante ha già modellato. Password1! ha matematicamente più entropia di password, ma in pratica la wordlist di ogni attaccante parte da lì. Una stringa di 20 caratteri tutta minuscola da un CSPRNG ha ~94 bit di entropia e non può essere indovinata da alcuna wordlist perché non corrisponde a una wordlist. La NIST SP 800-63B Rev 4 (luglio 2025) rende il divieto delle regole di composizione un requisito vincolante SHALL NOT.

Dovrei usare invece le passphrase?

Per le password che devi memorizzare, sì, è ciò che sosteneva xkcd #936 (10 agosto 2011). Il metodo Diceware (Arnold Reinhold, 1995) dà 12,9 bit per parola da un elenco di 7.776 parole; sei parole ≈ 77,5 bit è la raccomandazione moderna. L'EFF ha pubblicato elenchi di parole compatibili con Diceware aggiornati a luglio 2016. Ma per il caso d'uso di provisioning in blocco che questo strumento serve (token temporanei che vengono cambiati al primo accesso) l'ASCII casuale è la primitiva giusta perché l'utente non deve mai digitarlo.

Escludere i caratteri ambigui è un compromesso per la sicurezza?

Sì, tecnicamente, eliminare i, l, 1, L, O, 0, o riduce l'alfabeto da 94 a 87, abbassando l'entropia per carattere da 6,55 bit a 6,44 bit. A 16 caratteri sono 103,0 bit invece di 104,8 bit, del tutto irrilevante. Il compromesso conviene quando gli esseri umani devono leggere la password ad alta voce o trascriverla da un foglio stampato, che è esattamente lo scenario di distribuzione in blocco che questo strumento serve.

Qual è il modo più sicuro di distribuire un elenco generato?

Tratta l'elenco generato come un artefatto monouso. Distribuiscilo tramite un canale concordato in anticipo (e-mail cifrata con PGP/GPG, trasferimento sicuro di file, importazione in un gestore di password, consegna a mano per i contesti ad alto rischio). Configura i sistemi in modo da richiedere un cambio di password al primo accesso. Elimina il file dopo la distribuzione. Non inviare mai per e-mail elenchi in chiaro, non metterli mai sotto controllo di versione, non incollarli mai in chat. Le password generate sono pensate come token monouso: il valore sta nella casualità crittografica per la consegna iniziale, non nella conservazione a lungo termine.

Strumenti correlati