Vai al contenuto principale
Bethemesh
GuidaBuone pratiche

Password: generazione, robustezza e politiche utili

Costruisci una policy basata su lunghezza, unicità e rischi reali invece che su regole di complessità arbitrarie.

Pubblicato 29 agosto 2026Lettura : 3 minDi Team Bethemesh
Intermedio
Mostra indice
  1. La lunghezza conta molto
  2. Un indicatore di robustezza resta una stima
  3. Evitare regole che peggiorano il comportamento
  4. Lunghezza, imprevedibilità ed entropia
  5. La password deve soprattutto essere unica
  6. MFA e passkey modificano il modello di rischio
  7. Lato server: mai password in chiaro
  8. Politiche utente spiegabili
  9. Dopo una compromissione

Una buona politica delle password non consiste nell’imporre il maggior numero possibile di regole. Deve soprattutto rendere i segreti difficili da indovinare, unici e praticabili per gli utenti.

La lunghezza conta molto

Una passphrase lunga e imprevedibile può essere migliore di una stringa breve piena di sostituzioni prevedibili. Quando la password non deve essere memorizzata, un generatore casuale è spesso la soluzione più semplice e robusta.

Un indicatore di robustezza resta una stima

Un controllo di robustezza può valutare lunghezza e composizione, ma nessun punteggio locale conosce tutti i dizionari, tutte le fughe di credenziali o il contesto di un attaccante.

Una password apparentemente forte ma già compromessa o riutilizzata su più servizi rimane pericolosa.

Evitare regole che peggiorano il comportamento

Imporre cambi molto frequenti senza incidente può incoraggiare varianti prevedibili. Richiedere sempre maiuscola, numero e simbolo non garantisce una forte entropia. Una policy moderna privilegia generalmente una lunghezza sufficiente, il blocco di password comuni o compromesse e l’autenticazione multifattore quando il rischio lo giustifica.

Le regole devono poter essere spiegate agli utenti e adattate al livello di rischio dell’applicazione.

Lunghezza, imprevedibilità ed entropia

La robustezza dipende soprattutto dallo spazio di ricerca che un attaccante deve esplorare. Aggiungere un carattere realmente casuale aumenta questo spazio; aggiungere sistematicamente 1! a una parola comune molto meno.

Per un segreto generato e conservato in un password manager, una stringa lunga e casuale è ideale. Per un segreto memorizzato, una passphrase lunga può offrire un buon compromesso tra sicurezza e usabilità.

La password deve soprattutto essere unica

Il riutilizzo trasforma la compromissione di un servizio in un rischio per molti altri. Una policy utile incoraggia quindi l’uso di password manager e, quando l’infrastruttura lo permette, il blocco di password note come compromesse.

Nessun punteggio di robustezza può compensare il riutilizzo dello stesso segreto ovunque.

MFA e passkey modificano il modello di rischio

L’autenticazione multifattore aggiunge una barriera quando la password viene compromessa. Non tutti i metodi MFA resistono allo stesso modo al phishing, ma una seconda prova ben progettata riduce molti scenari di attacco.

Le passkey utilizzano chiavi crittografiche invece di un segreto condiviso memorizzato. Possono ridurre phishing e riutilizzo, anche se le password rimangono ancora necessarie in molte applicazioni.

Lato server: mai password in chiaro

Un server non dovrebbe aver bisogno di recuperare la password originale. Deve conservarne il risultato tramite una funzione di derivazione specifica per password e un salt unico.

Funzioni come Argon2id, scrypt o bcrypt sono progettate per rendere costosi i tentativi massivi. Un hash rapido generico come SHA-256 usato da solo non è un sostituto adeguato.

Il salt non deve essere segreto: evita, tra le altre cose, che due utenti con la stessa password abbiano automaticamente la stessa impronta. Un eventuale pepper può aggiungere un segreto server, ma non sostituisce una funzione di derivazione corretta.

Politiche utente spiegabili

Una base moderna consiste nel definire una lunghezza minima ragionevole, accettare password lunghe, evitare scadenze periodiche senza motivo, bloccare segreti evidentemente deboli o compromessi e permettere il copia-incolla per non ostacolare i password manager.

Un’area amministrativa sensibile non richiede necessariamente la stessa policy di un servizio privo di dati importanti: la politica deve riflettere il rischio reale.

Dopo una compromissione

Se una password o un database di credenziali è sospettato di compromissione, non basta aumentare il requisito di complessità. Occorre invalidare gli accessi interessati, rinnovare i segreti, verificare le sessioni attive e comprendere la causa dell’incidente.

Una policy sulle password è quindi una componente della sicurezza Web complessiva, non una soluzione isolata.

Strumenti correlati

Sicurezza e privacy

Generatore di password

Genera una password casuale in base alla lunghezza e ai tipi di caratteri che preferisci.

100% localeIn evidenza
Usa questo strumento
Sicurezza e privacy

Generatore di policy per password

Genera una policy per password chiara a partire dalle regole di sicurezza che scegli.

100% locale
Usa questo strumento

Raccolta

Mettere in sicurezza un sito web

  1. 01Sicurezza Web: comprendere le protezioni essenziali di un sito
  2. 02Content Security Policy (CSP): ridurre i rischi XSS e i caricamenti indesiderati
  3. 03Header HTTP di sicurezza: quali attivare e perché
  4. 04Subresource Integrity (SRI): verificare l'integrità delle risorse esterne
  5. 05JWT: comprendere struttura, firma, scadenza ed errori comuni
  6. 06Password: generazione, robustezza e politiche utili
  7. 07Hash, integrità e confronto delle impronte: cosa può davvero provare un hash

Questo articolo ti è stato utile?