Vietare le password specifiche?

La teoria è che ti piacerebbe eseguire gli stessi strumenti dell'attaccante. L'utente malintenzionato eseguirà un elenco di "password probabili" in base a ciò che conosce o suppone della psicologia degli utenti. John the Ripper è un noto software di cracking delle password che include molte "solite password" e regole comunemente utilizzate dagli utenti per derivare password spiritose.

Il tuo vantaggio è che il codice server ha accesso alla password stessa quando l'utente si è registrato. Contrariamente all'attaccante che deve eseguire ogni tentativo attraverso un processo di hashing potenzialmente costoso (e può essere pesante se fai girare il bcrypt l'iterazione conta alla massima potenza), il tuo codice può lavorare sulle cose reali e fare alcune ottimizzazioni come, come suggerisci, la normalizzazione in lettere minuscole.

Tuttavia penso che questa non sia una buona idea su base generale. L'autore dell'attacco non è limitato al software disponibile apertamente; egli può adattare il suo elenco di potenziali password al target effettivo (ad esempio utilizzando più derivazioni attorno ai nomi dei figli di un utente specifico la cui password è sotto il fuoco dell'attaccante). Anche tenere il passo con l'elenco delle "password deboli comuni" è probabile che sia un processo faticoso. Inoltre, l'utente stesso entrerà nel gioco: dal momento che le restrizioni delle password sono percepite come un fastidioso ostacolo da parte degli utenti, useranno tutta la loro creatività per trovare regole di generazione di password ancora più intelligenti che sfuggono ai test.

Applicare complesse regole di esclusione password sul server sta combattendo in qualche modo l'attaccante sul suo campo di battaglia e porterà l'utente alla festa; l'utente può sfortunatamente (e involontariamente) aiutare l'aggressore.

Pertanto, vorrei raccomandare contro tali regole. Ciò di cui hai bisogno è la collaborazione dell'utente, e lo avrai con trasparente sulle regole che usi; l'utente deve essere in grado di trovare una password che "supera il test" senza entrare in un processo trial-and-error. Niente è più fastidioso della scelta di dieci password successive fino a quando non viene finalmente accettato da un server rigido. Non si vuole infastidire l'utente, perché un utente infastidito aiuterà gli aggressori (non ci penserà in questo modo, ma questo è l'effetto netto). Le regole esplicite ("almeno 8 caratteri, almeno 1 cifra") sono molto meglio per la pedagogia.

E, naturalmente, niente batte l'educazione e la formazione degli utenti sui pericoli delle password non casuali.

Sembra buono oltre ad altre pratiche sensate (ad esempio, bcrypt).

Utilizzerei la più grande lista nera di password possibile. Se la tua password è in un elenco divulgato di 100000 password (o solo diversa da una password in tale elenco di uno o due caratteri), è una password errata e le GPU possono probabilmente sconfiggerla. È anche possibile che qualcuno stia riutilizzando quella password. L'unica buona ragione per rilassare questo criterio è se non si vuole frustrare i propri utenti che potrebbero rivolgersi a un concorrente che consente password deboli. (Anche per dichiarare l'ovvio, non usare le password dei propri sistemi per creare questo elenco di password nella lista nera - che sta memorizzando la password in chiaro un grande no.)

Inoltre, potresti voler creare una funzione di suggeritore della password che generi sempre una password che superi i tuoi criteri e che compaia quando la password fallisce. (Anche se è ancora necessario che l'utente lo digiti due volte.)

Mi assicurerei inoltre che il tuo schema non impedisca inavvertitamente passphrase forti. Ad esempio, fork scorn loss cope endow yin è una passphrase diceware grande creata casualmente e non dovrebbe essere vietata se una delle comuni password in blacklist è ridotta a fork (e la forcella è contenuta nella passphrase).

In realtà, Jeff Atwood sostiene questa pratica esatta nel suo post sul blog: link

Nel suo ruolo con Discourse, ha raccomandato di applicare una lunghezza minima di 10 caratteri e quindi di cercare le corrispondenze con le 10.000 password più popolari più lunghe di 10 caratteri.

Vedi il post del blog per altri buoni consigli.