Come posso impedire agli utenti di utilizzare password errate nella mia applicazione web?

Istruzione, minacce e strumenti.

La prima soluzione per i problemi di sicurezza è l'arruolamento degli utenti. Non puoi ottenere comunque una buona sicurezza senza la consapevolezza, quindi potresti anche chiedere il loro aiuto. Pubblica le linee guida su come scegliere una password.

Per rafforzare il punto precedente, pressurizzali un po '(solo un pochino). Pronuncia la parola fatidica: "responsabile". Essendo umani esseri umani, alcuni avranno bisogno di un ulteriore incentivo; in particolare, prestando attenzione a esplicitamente che spieghi quali saranno i guasti, sottolineerà la gravità del problema. Le persone non crederanno nell'importanza dei problemi di sicurezza se tu, come manutentore del server, non fai i compiti. Queste piccole minacce sottilmente velate spingono gli utenti nella zona leggermente scomoda dove sono alert . Non esagerare! Desideri utenti che si conformano , non utenti che combattono il tuo sistema .

A quel punto, aiuta gli utenti. Il fatto fondamentale della generazione di password è che gli umani non sono bravi in caso di casualità . Ma la casualità è ciò che è necessario per una password. Poiché si tratta di una webapp, si ha un server Web attendibile - "affidabile" nel senso che la password è per garantire la sicurezza di quel server, quindi il server stesso non può essere un nemico (sarebbe non ha senso). Quindi, usa quel server: includi un generatore di password . Qualcosa che produrrà buone password, accessibili con un clic.

I due aspetti della generazione della password sono che la password non deve essere ipotizzabile, ma deve essere comunque memorizzata. Dando regole per la password generazione , si presume che mnemonici con cui l'utente ricorda la password corrisponderà esattamente alla procedura con la quale la password è stata creata . Questa è una restrizione artificiale. Prendi in considerazione il famoso generatore di password XKCD : il il generatore è non sulla scelta di quattro parole che "hanno senso" insieme; invece, si tratta di selezionare quattro parole a caso e quindi, solo allora, trovare un "significato" per esso (come il mammifero ungulato che riflette i dispositivi di accumulo di elettricità). Questo evidenzia come vengono prodotte password complesse: usa la casualità , quindi allena il cervello per far fronte al risultato.

Uno schema di generazione di password a cui sono piuttosto affezionato va così: genera due lettere, poi due cifre, poi due lettere, poi due cifre. Per compiacere interfacce applicative inflessibili, creare le prime due lettere in minuscolo e le altre due in maiuscolo. L'entropia di questo processo di generazione è 10 ⁴ * 26 ⁴ , cioè un po 'sopra 2 ³² . 32 bit di entropia non sono male: ci vorranno in media più di due miliardi di tentativi per rompere una password di quel tipo. Questo è sufficiente per la sicurezza online (ci vorrebbe troppo tempo perché il tuo server "provi" molte password). D'altra parte, trovo che queste password casuali siano facili da ricordare . Provalo ! Ricorda già i numeri di telefono, che sono solo numerici; le lettere sono grandi "ancore" per la mente e rendono la memorizzazione solo più facile. Ecco cinque password di questo tipo, appena generate (non le ho scelte):

sf57HD04
sd82PI16
ny21BF75
xv53AQ36
jz91EQ92

Per ognuno di loro, dichiaro che stai già trovando un modo semplice per "ricostruirlo" nel tuo cervello, come se lo avessi creato in modo arguto. Ma dal momento che sono stati generati con reale casualità, la loro entropia è intatta.

Ci sono alcuni modi in cui posso pensare.

Richiedi determinate combinazioni di caratteri

Questa è una tecnica comunemente usata. Richiede agli utenti di inserire una determinata combinazione di caratteri come un mix di parole in maiuscolo, parole non capitalizzate, numeri e simboli. Imponi una lunghezza minima della password. Non essere eccessivamente restrittivo, poiché potrebbe costringere gli utenti a mescolare le combinazioni in modo non sicuro.

Password1234 non è più sicuro di password .

Questa tecnica potrebbe anche limitare le passphrase forti. Vedi: XKCD # 936: password complessa breve o lunga passphrase del dizionario?

Rifiuta le password comuni utilizzando una blacklist

Mantenere una lista nera di password comunemente incrinate e non consentire agli utenti di registrarsi utilizzando tali password. Questo potrebbe rivelarsi una quantità considerevole di lavoro da mantenere.

Vorrei anche aggiungere che le password deboli possono essere mitigate in modo significativo se ci sono buone restrizioni sui tentativi di accesso. Non ti proteggerà se il tuo file hash viene perso e non rilevato, ma a quel punto è più un problema di amministratore. La più grande preoccupazione per questioni di maggiore sicurezza sarebbe che le password potrebbero essere riutilizzate da altri siti che potrebbero essere compromessi. Creare un nome utente che non sia direttamente associabile a un utente è un modo decente per aggirare questo problema. Anche se so che Bob Worker usa BobW0rker12345 per la sua password di Facebook, se non conosco le credenziali di accesso di Bob Worker, non mi può aiutare l'accesso alla sua password di Facebook.

I requisiti di complessità della password possono anche aiutare ad assicurarci che non possa essere facilmente indovinato, ma arrivano anche con una serie di stupidi avvertimenti da parte di utenti come persone che scrivono password o diventano direttamente frustrati dal sistema e cercano di combattere direttamente il tuo sistema perché sta rendendo la vita difficile, quindi dovresti sempre ponderare il rischio e la ricompensa per i requisiti di complessità della password. A volte è veramente necessario e, in tal caso, passa al terzo e più importante punto di formazione per gli utenti.

I tuoi utenti devono capire perché il livello di sicurezza è necessario e essere i partecipanti disposti. In definitiva, i tuoi utenti sono collettivamente molto più creativi di te e faranno cose che non ti aspetti di compromettere la sicurezza a meno che non comprendano l'importanza e siano investiti in essa.

La risposta dovrebbe dipendere dallo scopo della password.

È qualcosa come un forum? Quindi non infastidire gli utenti costringendoli a sostituire la o nella propria password predefinita con uno 0. Questo è il massimo che faranno prima di abbandonare semplicemente il tuo sito. Sentiti libero di avvisare che la loro password fa schifo e che non ti assumerai alcuna responsabilità, ma non costringerli a usare l'unica password complessa che possono ricordare - quella al loro conto PayPal ...

È qualcosa come un negozio? Quindi avvisa gli utenti della debolezza della loro password e forse li fa confermare due volte, incluso "Sono consapevole che la mia password è più probabile che sia incrinata rispetto ad altri e non verrò da te piangendo per quando ciò accade "affermazione. Ma non costringerli a usare una password che non riescono a ricordare - direi che un gestore di password dovrebbe essere standard, ma non lo è, e gli utenti non dovrebbero considerare la funzione di reimpostazione della password come il modo predefinito per registrare in. Considerare l'offerta di Autenticazione a due fattori o OpenID invece.

In realtà è l'interfaccia web per lanciare un'arma nucleare o attivare i sistemi di supporto vitale dell'ISS? In tal caso, l'utilizzo di una semplice autenticazione tramite password è un grave difetto di per sé, sebbene non sia così grave come in realtà collegare queste cose a Internet.

Calcolo dell'entropia.

Una parola del dizionario, un nome proprio o un altro membro della lingua inglese moderna ha, in media, circa 1,5 bit di entropia per lettera. A questo, è possibile aggiungere un bit per ogni lettera maiuscola, un bit per ogni sostituzione "leet" (0 per o, 1 per i, 2 per q, 3 per e, 4 o @ per a, ecc.), 3 bit per ogni cifra numerica in un prefisso o suffisso che non è in ordine sequenziale e 4 bit per ciascun segno di punteggiatura non usati come sostituzione.

Per calcolare l'entropia automaticamente in base a una password inserita, spoglio tutti i numeri / simboli iniziali e finali, dividi le lettere maiuscole e esegui ciò che è rimasto attraverso un correttore ortografico per ottenere le parole effettive.

Prendi la somma di tutti i bit di entropia e alza 2 a quella potenza. Questo è il numero di forze brute che ci vorrebbe per provare tutte le possibilità usando un cracker basato sul dizionario. La velocità con cui può accadere dipende dalla velocità con cui la porta principale può elaborare i tentativi di accesso; Raccomando la verifica della password basata su un hash lento (bcrypt) sul lato server abbinato a un numero massimo di tentativi di accesso, oltre a qualsiasi meccanismo che utilizzi per proteggere la trasmissione della password dal client al server.

Ad ogni modo, una volta che hai un punteggio e sai cosa significa in termini di lunghezza di un attacco (onestamente, se vedi tentativi di login falliti ripetuti anche per 3 ore, ci dovrebbero essere campane d'allarme), tu può impostare soglie per "debole", "normale", "strong" ecc. e non accettare una password "debole". Comprendi che a causa della legge di Moore, la password sicura di oggi è la password debole di domani, e ciò che richiede anni cracker basati su GPU potrebbe richiedere una botnet o un'agenzia di intelligence.

• La protezione con password di per sé è intrinsecamente insicura

• Non è possibile rispondere facilmente alla domanda senza un contesto aggiuntivo. Quanto deve essere strong una password dipende dal valore della risorsa che protegge. Pertanto, fino a che punto un'applicazione deve fare qualcosa sulla forza di una password dipende da cosa protegge (anche se c'è un problema di persone che usano la stessa password su più siti - vedi il prossimo punto).

• L'educazione e la consapevolezza degli utenti sono fondamentali. La mancanza di istruzione e consapevolezza creerà risentimento tra i tuoi utenti se li imponi di usare password che consideri molto forti e che considerano difficili da creare o ricordare. Allo stesso modo, uno squilibrio tra forza applicata e valore percepito di ciò che viene protetto causerà risentimento.

• Considera la minaccia e come potrebbe essere realizzata. Gli attacchi di forza bruta raramente si verificano tramite un'interfaccia dell'applicazione. Più spesso, vengono applicate a un gruppo di password che sono state rubate dal repository di backend dell'applicazione. Non ha senso obbligare gli utenti a inserire password sicure se memorizzano e gestiscono tali password significa che qualcuno è in grado di ottenerle. Dato il tempo, un numero sufficiente di CPU e memoria e algoritmi di crittografia scadenti, la forza della password diventa irrilevante.

A parte questo, penso che sia ragionevole ridurre la tua esposizione imponendo password forti. Non esagererei. Imponi una lunghezza minima della password, una combinazione di lettere maiuscole / minuscole e l'inclusione di caratteri numerici e di punteggiatura, ma accetta che gli utenti trovino / facciano cose che comprometteranno ancora i tuoi tentativi. Riconoscere che le password sono intrinsecamente insicure se usate come unico metodo di autenticazione e di peso rispetto al valore di ciò che viene protetto. Se il rischio è ancora troppo elevato, considera meccanismi aggiuntivi, come l'autenticazione dei due fattori.

Questa roba non è misurata in termini assoluti. Non esiste una taglia adatta a tutte le soluzioni e la forza della password non è l'unico pezzo del puzzle che devi considerare. Guarda come archiviare e gestire le password, valutare la provenienza di un attacco, come verrai avvisato di un simile attacco, come convincere i tuoi utenti ad adottare buone pratiche, come bilanciare valore e disagio di qualsiasi misura di sicurezza, ecc. e ricorda che questo non è un processo di fare e dimenticare. Questo è qualcosa che deve essere rivisto e aggiornato su base regolare come tecnologia, tecniche e cambiamenti di comportamento.

Una domanda migliore potrebbe essere: Perché la mia applicazione web richiede le password in primo luogo?

Non ho alcuna password per nessuno dei miei account StackExchange!

A seconda dell'applicazione, legarla con un altro servizio di autenticazione o generare una password pseudo-casuale per impostazione predefinita, potrebbe essere l'approccio migliore.

Se generi una password pseudo-casuale, potresti volerlo abbastanza casuale, ma facile da ricordare.

Esistono numerosi strumenti che generano password con le consonanti intercambiate con le vocali , potenzialmente intercambiate con un paio di numeri; tali password sono intrinsecamente valide per le applicazioni web (dal momento che non è possibile forzare brute-force un'applicazione Web non rilevata), ma sono abbastanza facili da ricordare, poiché in realtà non sembrano totalmente casuali, ma assomigliano a una parola strana o nome.

Un esempio di un buon strumento che genera password così facili da ricordare, leggibili e pronunciabili è uno strumento console chiamato pwgen.

link
link