Non direttamente correlato, ma suggerito da Pwned Passwords Validator, dato che stiamo esaminando una convalida delle password più rigorosa ultimamente.
Discourse non sembra bloccare una password come myusername123 o 4myusername per il nome utente myusername.
Non ho trovato discussioni precedenti su questo tipo specifico di password debole. È stato preso in considerazione in passato?
Sono d’accordo nell’aggiungere un controllo quando gli utenti scelgono una password, in modo che ‘la password non debba contenere username_lower’. Mi sembra ragionevole.
Abbiamo già un test per password = username, ma non mi piacciono molto i test di sottostringa, specialmente per username brevi. Cosa succede se il tuo username è “Ed” e la tua password è una stringa casuale che per caso contiene “ed”…
Utilizzando un punteggio di similarità come la distanza di Levenshtein, fallire se levenshtein(username, password) < 6? O forse qualcosa per catturare anche le permutazioni, come questo:
levenshtein(sort_by_chars(username), sort_by_chars(password)) < 6
Sembra che questo copra gli abusi peggiori, senza impedire a “Ed” di registrarsi con una password lunga e sicura, ed è facile spiegarlo in modo accurato: “il tuo nome utente e la tua password sono troppo simili”. Non ho cercato casi limite indesiderati, ma al momento non riesco a pensarne alcuno.
Tweet correlato di oggi:
Il rovescio della medaglia delle regole “più e più” è che diventa più facile forzare brute force le password.
Chiaramente nessuna password dovrebbe avere la lettera z ripetuta 10 volte se è lunga 15 caratteri o meno.
Chiaramente nessuna password dovrebbe contenere la parola “password”. Se è più corta di 12 caratteri.
Due parole del dizionario una di seguito all’altra, chiaramente sbagliato…
E così via. Quindi lo spazio di ricerca delle password si riduce.
Questa è una buca di coniglio, ho cambiato idea da ieri dopo averci pensato. Sono d’accordo con @codinghorror: non credo che dobbiamo fare nulla in merito.
«È difficile creare buone regole, quindi non dovremmo crearne affatto»?
Questa è la seconda volta in due giorni che vedo membri di alto livello del team di Discourse diffondere gravi idee sbagliate sulla sicurezza. Credo che ci siano alcuni aspetti generali che dovete riesaminare e spero che consideriate questo un feedback costruttivo.
Inoltre, questo suggerimento specifico non nasce dal nulla: abbiamo recentemente avuto un account utente compromesso perché il nome utente era myusername e la password era del tipo myusername46.
Va detto che si trattava di un sito ClassicPress (con la stessa struttura di accesso di WordPress), quindi è molto più un “bersaglio facile” per i bot e simili. Tuttavia, è proprio questo che i bot cercano.
Le regole per le password non possono prevenire ogni tipo di password debole, ma possono fare una grande differenza.
Tecnicamente stiamo seguendo le linee guida di NIST 800-63-B:
Quando si elaborano le richieste per stabilire e modificare segreti memorizzati, i verificatori CONFRONTANO i segreti prospettici con un elenco contenente valori noti come comunemente usati, attesi o compromessi. Ad esempio, l’elenco PUÒ includere, a titolo esemplificativo e non esaustivo:
- Password ottenute da precedenti corpus di violazioni.
- Parole del dizionario.
- Caratteri ripetitivi o sequenziali (ad esempio ‘aaaaaa’, ‘1234abcd’).
- Parole specifiche del contesto, come il nome del servizio, il nome utente e le loro varianti.
Usano esplicitamente la parola PUÒ e non CONFRONTANO. Quindi è a nostra discrezione. Non c’è alcuna raccomandazione per Levenshtein qui. Forse se il nome utente è più lungo di 6 caratteri, non dovrebbe essere incluso nella password; potremmo aggiungere un controllo di entropia oltre all’elenco di 1 milione di password. Non lo so.
Immagino che se sei molto interessato ad avere le tue regole qui, puoi eseguire SSO e applicare le regole che desideri dal tuo lato. Oppure scrivere un plugin.
Probabilmente è questo che faremo. C’è ancora molto da aggiungere, ma le risposte finora ricevute non mi fanno pensare che valga la pena sollevare la questione.
Condividi qui il plugin che hai creato con la community nella categoria #plugin. Non tutti sono d’accordo con ogni decisione che prendiamo; rispetto pienamente la diversità e le diverse opzioni. Forse ad altri interessano regole per le password più rigorose.