Quali considerazioni devo tenere a mente quando impone le passphrase?

Non è necessariamente una cattiva idea. L'utente malintenzionato può sapere che la password è in quel formato, considerando che le 4 parole sono abbastanza casuali. Ma ecco la cosa, ci sono altri buoni modi per creare una password strong e memorabile. Limitare i tuoi utenti a quello che ti piace non è molto bello. Ad esempio, utilizzo il gestore delle password con password lunghe veramente casuali, il che è persino migliore di quello che proponi, ma non potrei farlo sul tuo sito.

Ancora più importante, se la ragione per cui vuoi farlo è forzare gli utenti a usare una password complessa, quindi generare la password di 4 parole per loro. È possibile generare tale password avendo un dizionario, quindi scegliendo un numero casuale compreso tra 1 e il numero di parole nel dizionario e prendendo quella parola. Fai questo 4 volte e hai una password. Puoi ottenere l'ispirazione qui . Questo è importante, poiché la maggior parte degli utenti non può scegliere 4 parole veramente casuali, ma 4 parole facilmente ipotizzabili. In tale scenario, questo sarebbe peggio di consentire loro di scegliere qualsiasi password.

Stai alludendo a Principio di Kerckhoff . Quando progettiamo sistemi crittografici, assumiamo che l'attaccante saprà tutto sul tuo sistema eccetto per le parti derivate dall'entropia (chiavi / password / etc, in genere) - questo perché non possiamo garantire che non conoscano i dettagli, ma deve presumere che non conoscono le nostre chiavi generate. Qualsiasi schema di generazione di password segue questo ragionamento: se uno schema di password è considerato sicuro, allora puoi credere che un utente malintenzionato sappia quale schema stai usando non è un problema.

Il motivo per cui non è un problema è dovuto al modo in cui funzionano gli spazi dei nomi delle password. Se si richiede che un utente generi una password basata su un elenco diceware noto, come l'elenco EFF, e si richiede che sia lungo almeno 4 parole, allora è possibile calcolare la complessità dello spazio dei nomi.

Per prima cosa, scopriremo lo spazio dei nomi di una singola parola: nella lista diceware di EFF, tiri cinque dadi a sei facce e scegli il risultato che emerge. Dato che ci sono cinque posizioni con sei opzioni, possiamo calcolare 6 ^ 5, che ci dà 7776 - questo significa semplicemente che ci sono 7776 parole possibili diverse per ogni luogo.

Ora possiamo calcolare la complessità minima dello spazio dei nomi di quattro di queste parole. Questo è fatto semplicemente prendendo il numero di parole possibili e aumentandolo alla potenza del numero di parole nella password - 7776 ^ 4. Questo ci dà 3656158440062976 (3,6 quadrilioni) possibili password diverse di quattro parole diceware di EFF.

Ora, per indovinare quanto tempo ci vorrà, dobbiamo fare alcune ipotesi -

1. Stai utilizzando un buon algoritmo di hashing: scrypt, bcrypt, PBKDF2, ecc.

2. L'hacker ha hardware di livello consumer. - Vedremo alcuni benchmark per una serie di 801 1080 TI, che sono al top della linea al momento della scrittura, ma non dovrebbero essere presi come il tasso massimo di hash: la NSA, ecc. Probabilmente ha hardware speciale solo per hashing password il più velocemente possibile.

Possiamo vedere da questo benchmark che in OpenCL, un utente malintenzionato con 8x 1080 Ti può attaccare buoni algoritmi al seguente tariffe:

1. scrypt ad una velocità di ~ 6.4 milioni di hash al secondo.
2. bcrypt ad un tasso di 184 mila hash al secondo.
3. PBKDF2-SHA256 ad una velocità di 775 mila hash al secondo.
4. SHA1 (solo per il confronto, non usare questo per le password) ad una velocità di 101 miliardi di hash al secondo.

Quindi, per il nostro spazio dei nomi di 3,6 quadrilioni di possibili password, possiamo calcolare i seguenti tempi attesi per craccare. Tieni presente che in media il 50% dello spazio dei nomi deve essere esaurito, non al 100%.

1. scrpyt - 571274756.25984 secondi (~ 9 anni)
2. bcrypt - 19870426304.690086956521739130435 secondi (~ 315 anni)
3. PBKDF2 - 4717623793.6296464516129032258065 secondi (~ 75 anni)
4. SHA1 - 36199.588515475009900990099009901 secondi (~ .2 giorni)

Quindi, possiamo vedere che è necessario implementare anche un buon algoritmo di hashing.

Da questo algoritmo mancano due cose: in primo luogo, non abbiamo omesso parole più corte di 4 caratteri. L'elenco diceware di EFF ha molte parole lunghe 3 caratteri. Se aumenti la lunghezza minima della parola, riduci lo spazio dei nomi. Penso che la lista EFF abbia ~ 500 parole di 3 caratteri, ma questa è una supposizione. Quindi, lo spazio dei nomi è leggermente meno complesso.

In secondo luogo, abbiamo trattato queste password in modo casuale. Perché invece volevi delle frasi, dobbiamo tenere a mente che le frasi non sono casuali. Se vuoi che le frasi abbiano un senso, allora ci sono degli attacchi che puoi eseguire contro di loro: puoi usare le catene di Markov e altre cose divertenti per generare frasi probabili piuttosto che brute forzare la password. Non ho statistiche su quanto sia più facile questo rispetto al forzante bruto, quindi vado avanti e dico che dovresti assumere che fa una grande differenza ed è molto più debole.

Non stai danneggiando la sicurezza delle password dicendo all'autore dell'attacco che la password ha una lunghezza di almeno 16 caratteri e comprende 4 o più parole. È come dire che la password deve avere almeno 10 caratteri, avere almeno una lettera maiuscola, un numero e un simbolo. Giusto?

Con 4 parole, il costo di una forza bruta è maggiore di 10 caratteri casuali. Se chiedi all'utente di utilizzare almeno una lettera maiuscola, il costo aumenta ancora di più.

Secondo il dizionario di Oxford, l'inglese ha un po 'meno di 175k parole. Vi sono 8,64 × 10 ²⁰ combinazioni possibili. Usando tutti i 95 caratteri su una tastiera inglese, hai 5.98 × 10 ¹⁹ combinazioni possibili.

Memorabilità. Una password di 4 parole sarà sicuramente più facile da ricordare rispetto a una password casuale, ma ciò non significa che l'utente medio lo ricorderà in realtà senza scriverlo o utilizzare un gestore di password comunque (ci sono troppe password diverse da ricordare oggigiorno). Quindi la memorizzazione è utile ed è ottima, ma potrebbe non essere così utile come credi.

Sicurezza. Una password di 4 parole sarà più sicura della password media solo se le parole vengono scelte casualmente da un insieme di parole sufficientemente ampio. Secondo l'articolo che ho trovato, l'entropia della password utilizzata da un utente medio dovrebbe essere di circa 21 bit (2 ²¹ = 2.1 × 10 ⁶ ), che è preoccupantemente basso. Se scegli 4 parole in modo casuale da un elenco delle 1000 parole inglesi più comuni, avresti 1000 ⁴ = 10 ¹² possibilità, quindi password che è 1 milione di volte più difficile a bruteforce rispetto alla password media.

Quindi, in generale, la tua idea non è male, purché tu non permetta ai tuoi utenti di scegliere le proprie parole, o finiranno per scegliere password come "pass pass pass pass" o "1 2 3 4 ", ecc. E, naturalmente, questo è tutto in generale, perché ci sono sicuramente casi specifici in cui il tuo metodo ridurrebbe effettivamente la sicurezza della password. Ad esempio, il tuo metodo ridurrebbe la sicurezza della mia password perché di solito tendo ad usare password casuali lunghe, quindi se mi costringi ad usare il tuo metodo sulla tua applicazione, utilizzerei una password meno sicura del solito. Lo stesso è probabilmente vero per comunità come questa, dove spero che l'entropia della password media sia di gran lunga maggiore di 21 bit e probabilmente maggiore delle password di 4 parole.

Non puoi costringere gli utenti a usare password che siano sicure e memorabili.

Questa risposta a una domanda correlata riassume il fumetto sottolineando che l'aspetto umano delle politiche sulle password, non aspetto del computer, "dovrebbe spesso essere la preoccupazione dominante".

@ La risposta di Adonalsium copre bene l'aspetto del computer. L'utilizzo di diceware è relativamente buono per l'aspetto umano senza essere negativo per l'aspetto del computer, quindi è un modo accettabile per generare password.

Ma se vuoi memorabilità, non puoi dettare agli utenti come generare password. Né puoi richiedere che utilizzino password generate per loro.

Ci sono alcune cose ovvie da evitare, come limitare le lunghezze delle password a qualcosa di irragionevolmente breve, richiedendo caratteri da una lista particolare (come cifre o segni di punteggiatura) o proibendo caratteri da una lista particolare (come spazi o virgolette). Quindi, come puoi evitare quelli, ma richiedono comunque password sicure?

È necessario stimare un limite inferiore all'entropia della password inserita e impostare la politica in modo che accetti solo password con una stima superiore a un minimo (possibilmente basato sul tempo minimo minimo richiesto). L'unico strumento di stima di cui sono a conoscenza è zxcvbn (che purtroppo non rifiuta "graffetta corretta della batteria del cavallo").

Ciò consentirà l'uso di password relativamente brevi generate casualmente e di password diceware relativamente lunghe, senza richiedere né l'uno né l'altro di essere inadeguate. L'utente può scegliere il metodo migliore per loro e puoi richiedere il livello di resistenza alla rottura di cui hai bisogno.

Generare e raccomandare le password del diceware potrebbe essere utile, e penso che sia una buona idea, ma dovrei assicurarmi che quel processo non introduca nuove vulnerabilità prima di usarlo io stesso. (Un'altra cosa per fornire link su, se lo fai.)

(Sarei anche incline ad avere una scimmia del caos per la sicurezza delle password che tenta costantemente di violare le password degli utenti e forzare un reset ogni volta che ci riesce.) Ma non sono sicuro che ciò avvenga su password deboli più spesso di password sfortunate).

Il mio consiglio è non . Non discuterò nemmeno se applicherà la sicurezza password (hai già un commento su 32 caratteri casuali password generata da un gestore di password), ma più l'effetto sulla sicurezza globale.

Stai aggiungendo un vincolo per gli utenti finali. Alcuni (non istruiti) usano sempre la stessa password. Lo ricordavano a malapena e non vogliono essere disturbati da uno nuovo, quindi non useranno la tua app web, se possibile. Altri diranno: questa è una bella idea, ma non potrò ricordarla per molto tempo ... scriviamola su quel foglio! Quelli che sono abituati a un buon gestore di password diranno quanto è stupido che non possa usare il mio generatore casuale! e di nuovo eviteremo l'app, se possibile.

L'unico caso d'uso in cui posso accettare le regole della password è per la password principale in un ambiente aziendale. I dipendenti dovrebbero usarlo tutti i giorni (ogni giorno lavorativo ...) e solo uno è normalmente necessario, grazie alle soluzioni Single Sign On, quindi ricordarlo non dovrebbe essere un problema. Per tutti gli altri casi di utilizzo, si presume che l'utente finale sia responsabile dei propri dati e la mia opinione è che qualsiasi cosa al di sopra di una lunghezza minima sia un vincolo fastidioso , e cercherò di non usare quel sito.

Non penso che tu possa avere un'utile applicazione della password per questo. La forza del metodo XKCD del diceware AKA dipende dalle parole della frase che sono casuali. Quattro parole scelte, in particolare quattro parole scelte che rendono una frase una passphrase molto debole e non c'è modo di verificare se le parole che inseriscono sono casuali o scelte.

Non farlo, ma fornisci un avvertimento all'utente che sta tentando di impostare una password completamente non sicura e fagli confermare che vogliono davvero impostarlo.

Costringere le persone a impostare una password che sia al di sopra di ciò che possono memorizzare non solo le farà scrivere, ma scriverlo a caso e in un posto insicuro.

Inoltre, in alcune organizzazioni, è auspicabile la possibilità di utilizzare una passphrase sicura (per complessità) ma condivisa (tra un team autorizzato) e / o predocumentata (sotto chiave e chiave) - le linee guida della password che rifiutano alcune password ragionevolmente sicure possono diventare un vero fastidio qui. Scenario di utilizzo: "Impostare la passphrase complessa utilizzata da questo team per tutti i fornitori di tipo XYZ, in modo che non ci siano problemi nel caso in cui un altro membro di questo team abbia bisogno di accedervi urgentemente in caso di assenza".

What better ways are there to force passwords that are more secure and memorable at the same time ?

Due cose che mi vengono in mente (entrambe legate all'incremento della password "alfabeto"):

1) Nel tuo post non è chiaro se siano consentiti caratteri numerici e speciali. Supponendo che non lo sia, ti lascerebbero un alfabeto di soli 32 personaggi diversi. Includerei e motiverei attivamente i tuoi utenti a usarli.

2) Supponendo che useresti solo parole inglesi, un attaccante ha due attacchi diretti. (A) forza bruta ogni singolo carattere o (B) forza bruta ogni singolo 4 parole basate su un dizionario inglese. Considerando che gran parte della popolazione mondiale ha l'inglese come seconda lingua, motiva i tuoi utenti a mescolare le lingue.