A meno che tu non abbia mezzi separati per limitare l'accesso al modulo di login stesso, una buona linea di base è non avere un limite rigido . Questo perché è fin troppo facile per qualcuno essere completamente bloccato fuori dal proprio account.

Questo è un male a causa della negazione del servizio, ovviamente, ma è anche un problema di sicurezza in sé. Aumenterà le richieste di supporto da parte di persone che chiedono lo sblocco dei propri account e le persone che effettuano lo sblocco si abitueranno e gli attacchi di ingegneria sociale che iniziano con "ehi, il mio account è bloccato" diventeranno molto più facili.

Estendi invece i timeout - ma non all'infinito; quanto basta per limitare il numero di tentativi a una quantità ragionevole nel tempo, dati i requisiti di complessità della password.

A mio parere, non è possibile rispondere in generale. Dipende dalle tue esigenze in termini di usabilità, sicurezza e altri parametri.

Uno dei fattori principali è l'ampiezza della gamma di possibili password nel tuo scenario specifico. Supponendo che un utente malintenzionato non abbia ulteriori informazioni sulla password e debba forzare la combinazione giusta, ha una probabilità di 1 rispetto al numero di possibili combinazioni di password per indovinare la password specifica.

Ad esempio con una cifra di 4 Numero PIN ci sono 10.000 combinazioni possibili (10 ^ 4). La possibilità di indovinare una combinazione specifica con un tentativo è compresa tra 1 e 10.000 o 0,01%. Consentire due tentativi raddoppia la possibilità di indovinarlo fino allo 0,02%.

Sta a te trovare il giusto compromesso per il tuo scenario specifico. Ma tieni presente che la forzatura bruta non è l'unico attacco metodo che potresti dover considerare. Alcuni aggressori potrebbero avere informazioni aggiuntive sul bersaglio e possono quindi aumentare le possibilità di indovinare provando una combinazione più probabile (ad es. Se una persona presa di mira utilizza informazioni personali all'interno della sua password e l'attaccante ne è a conoscenza).

Il numero considerato "sicuro" è abbastanza arbitrario perché il rischio si basa sul valore dei dati, sul livello di complessità consentito e applicato, sulla lunghezza minima / massima della password e possibilmente su altre misure di sicurezza che potresti aver implementato.

Il numero tipico è compreso tra 3 e 10. Se si implementano intervalli di tempo crescenti tra i tentativi non riusciti, è possibile andare verso l'estremità più alta ma solo se si consente / incoraggia o impone una lunghezza della password relativamente elevata & complessità.

Quello che devi ricordare è che la maggior parte delle persone non crea password casuali. Nel Regno Unito, ad esempio, il pin più comune è il 1966 e un altro comune è il 1066, entrambi famosi della storia. C'è di più tra cui scegliere in una parola, ovviamente, ma le persone spesso finiscono per avere parole comuni. Quindi consentire 4 tentativi su una password breve è più efficace di quanto si possa pensare, specialmente se il sistema consente ulteriori tentativi dopo un timeout.

Ovviamente, su molti siti questo potrebbe non avere molta importanza se il rischio e la sensibilità dei dati è bassa.

Oltre a estendere i timeout, un altro buon modo per migliorare la sicurezza è richiedere un secondo fattore di autenticazione dopo alcuni tentativi falliti. Spesso si invia un codice tramite e-mail o telefono.

È inoltre possibile impedire tentativi di accesso da reti diverse in breve successione e soprattutto da località diverse. È anche una buona idea registrare e controllare i tentativi di accesso non riusciti.

Queste strategie aiutano a evitare alti livelli di chiamate all'assistenza clienti riducendo al minimo i rischi.

Problema

Nota iniziale: sono di parte nei confronti dei server web, ma molto di ciò che viene detto qui si applicherà ad altri tipi di servizi.

Il problema è Denial of Service . Può accadere in due modi: 1) Gli aggressori eseguono la forza bruta in modo tale da saturare il server e ora nessuno può accedere al servizio. 2) Gli utenti (malintenzionati o meno) potrebbero provare troppe volte, determinando il blocco dell'accesso.

Altre considerazioni

1. Dire all'utente se l'errore è nel nome utente o nella password consentirà a un utente malintenzionato di utilizzare nomi utente a forza bruta / dizionario. Anche se questo va contro l'usabilità, dovresti optare per la sicurezza se gli account sono privati ​​o anonimi per impostazione predefinita ※.

2. Dire all'utente che l'account è bloccato rendere più facile per gli aggressori causare problemi bloccando molti account (che è una forma di negazione del servizio e probabilmente porterà a molti ticket di supporto). Inoltre, gli account che non esistono non possono essere bloccati, consentendo agli aggressori di scoprire gli account con questo metodo. Puoi prendere in considerazione l'idea di deridere il blocco sugli account falsi.

3. La scoperta degli account non è solo metà dell'attacco di forza bruta / dizionario, ma può anche essere utile nel futuro social engineering.

4. Una variante dell'attacco forza bruta / dizionario è provare la stessa password (di solito statisticamente comune) contro un gran numero di nomi utente.

※: I motori di ricerca saranno in grado di indicizzare i nomi degli utenti? Se lo faranno, optare per l'usabilità (gli aggressori hanno comunque un elenco di nomi utente validi nella cache del motore di ricerca). Evita di consentire ai motori di ricerca di accedere a tali informazioni in siti in cui sapere chi ha un account può essere considerato informazioni sensibili.

Possibili soluzioni

Ci sono alcune cose comuni da provare per risolvere il problema :

• Aggiungi un CAPTCHA
• Aggiungi un'ora per il nuovo tentativo
• Blocca l'account
• Blocca l'origine
• Autenticazione a due fattori

Va ​​notato che solo il blocco dell'IP a livello di firewall o di configurazione del server web avrà un impatto reale sul carico del server. Tuttavia, se stai bloccando l'origine solo quando accoppiato con l'account specificato, la logica sarà nel codice lato server. È anche vero per il resto delle soluzioni che richiedono codice lato server.

Queste soluzioni si basano sul codice lato server e quindi non proteggeranno realmente il server da un attacco flood. Ciò significa che l'applicazione principale di questi metodi è come deterrente .

Vocabolario:

Per il contesto di questo post, queste parole hanno il significato qui menzionato:

• "Blocca": "impedisce l'accesso fino a quando non viene fornita un'ulteriore autenticazione", per fornire ulteriori mezzi di autenticazione per seguire passaggi simili - se non uguali - a quelli forniti agli utenti che hanno dimenticato la password.

• "Origine": l'IP, l'agente utente o altre tecniche che il server può utilizzare per identificare l'origine di una connessione. Se utilizzato, dovrebbe essere menzionato nell'informativa sulla privacy che il server registrerà tali informazioni.

• "Terzo canale": Email, SMS, app dedicata o altro mezzo di riservatezza comunicazione al di fuori del controllo del server.

Va ​​anche notato che in questa definizione il tempo di riprova non è un blocco perché non richiede un'autenticazione aggiuntiva dal utente ma in attesa.

E, poiché non può essere ripetuto abbastanza volte , applica hash e salt le tue password.

CAPTCHA

Va ​​notato che non tutte le soluzioni CAPTCHA sono visive. Alcuni sono uditivi e anche altri sono testuali (ad esempio: "Quanti colori nell'elenco viola, pinguino, blu, bianco e rosso?").

Pro

CAPTCHA è facile da implementare utilizzando soluzioni di terze parti. L'uso di soluzioni di terze parti esternalizza anche il problema per rendere un CAPTCHA abbastanza forte.

Contro

L'utilizzo di un CAPTCHA può diventare un inconveniente per gli utenti legittimi che potrebbero avere problemi a digitare la password. L'attuale reCAPTCHA mitiga questo problema utilizzando l'analisi del comportamento per identificare gli utenti umani.

Un robot può risolvere il CAPTCHA tramite un'intelligenza artificiale intelligente o semplicemente chiedendo all'autore dell'attacco di risolverlo.

Riprova

Pro

Il tempo di riprova ha un vantaggio in quanto fa guadagnare tempo. Quindi, può essere combinato con una notifica su un terzo canale per avvisare il proprietario dell'account.

Quale azione può intraprendere l'utente? Puoi suggerire di utilizzare una password più complessa, ma questo non risolverà davvero il problema.

In alternativa, considera di dare all'utente l'opzione di negare l'accesso dalla macchina attaccante (cioè di bloccare la combinazione di origine e account) ※. Vedi "Bloccare l'origine".

※: Dovrebbe richiedere l'autenticazione e interessare solo l'account corrente. È necessario prestare attenzione nell'evitare qualsiasi difetto che possa portare a un account che blocca un altro account.

Contro

L'uso di un tempo di ripetizione riduce l'usabilità del servizio, in quanto diventa un inconveniente per utenti legittimi che potrebbero avere problemi a digitare la password. Questo è peggio del CAPTCHA in quanto è tempo di inattività cognitiva.

Gli attacchi di forza bruta / dizionario sono ancora possibili se l'aggressore esegue un tentativo una volta ogni ora circa. Le alternative per affrontare questo problema includono politiche di sicurezza per cambiare frequentemente la password (che l'utente potrebbe rendere inefficace scegliendo password simili) e IDS o altre analisi per rilevare gli aggressori (che potrebbero essere aggirati distribuendo l'attacco da più fonti - si spera che sia abbastanza costoso da essere esso stesso un deterrente).

Blocca l'account

Pro

È resistente contro la diffusione di un attacco nel tempo o origini multiple.

Svantaggi

Il blocco dell'account può comportare il blocco dell'account di un utente legittimo a causa del numero di tentativi falliti.

Inoltre, i tentativi falliti di un utente malintenzionato in una terza posizione bloccheranno l'utente legittimo. La combinazione del blocco dell'origine con il blocco dell'account consentirebbe un controllo più granulare. In questo caso, l'account verrebbe bloccato solo per l'origine da cui si sta tentando di accedere.

Gli attacchi possono comunque interessare il sistema inducendo utenti legittimi bloccati a contattare l'assistenza o a trovare un servizio alternativo.

Blocca l'origine

Pro

Bloccare un'origine, indipendentemente dall'account ha il vantaggio di consentire di fermare gli aggressori invece di punire gli account.

Contro

In richiederebbe al server di tracciare l'origine delle richieste e distinguere i tentativi falliti da quelli riusciti.

L'origine di un attacco può essere condivisa tra molti utenti (ad esempio in Internet cafè) e bloccare un'origine può significare bloccare gli utenti legittimi.

La combinazione del blocco dell'origine con il blocco dell'account consentirebbe un controllo più granulare. In questo caso, all'inizio l'origine sarebbe bloccata solo per l'account a cui sta tentando di accedere, tuttavia un'origine bloccata per molti account può essere bloccata a livello globale.

Autenticazione a due fattori

Tutte le varianti dell'autenticazione a due fattori sono forti deterrenti per la forza bruta / dizionario. Esistono due varianti principali:

• Invia un codice tramite un terzo canale per consentire l'autenticazione. Non dovrebbe richiedere misure aggiuntive per prevenire la forza bruta di quel codice, perché è pensato per essere monouso e di breve durata.

• Richiedi un codice da hardware / software dedicato chiave per l'autenticazione. La chiave deve fornire un codice monouso che autorizzi l'autenticazione.

Pro

L'autenticazione a due fattori è l'unica soluzione che può effettivamente rendere bruta- attacco forzato / dizionario inefficace. Ciò si ottiene richiedendo un codice monouso, che essendo monouso non sarà indovinato tentando più volte.

Contro

L'autenticazione a due fattori è spesso più costosa da implementare.

Cosa usare?

Ha senso aggiungere una protezione aggiuntiva per scoraggiare gli attacchi di forza bruta / dizionario. La necessità di queste misure aumenta nei sistemi in cui lo spazio della password è troppo piccolo ※, o se la forza minima delle password è troppo bassa (ad esempio i pin a quattro cifre comuni nelle banche).

※: È bene mettere un limite superiore alla dimensione della password. In questo modo il server non verrà bloccato mentre crea un costoso hash sulla password. E dovresti usare un hash costoso perché scoraggerà gli attacchi forzati contro i codici hash rubati .

CAPTCHA dovrebbe essere la prima opzione, poiché è molto facile ed economico da implementare ( utilizzando soluzioni consolidate come reCAPTCHA).

Tra il tempo di ripetizione e i blocchi, considera che l'implementazione minima possibile è simile: per bloccare un account aggiungi un campo all'oggetto / record dell'account contrassegnandolo come bloccato e quindi controlla che durante l'autenticazione ... per inserire un tempo di nuovo tentativo, fai la stessa cosa, tranne che ciò che memorizzi è l'ora in cui l'autenticazione è di nuovo valida.

Ha senso mitigare l'inconveniente aggiungendo queste misure una volta falliti alcuni tentativi. In tal caso, applica prima il CAPTCHA poiché non crea tempi di inattività cognitivi per l'utente.

Tra le opzioni di blocco, abbiamo visto che la combinazione di origine e account è un'alternativa migliore (ma anche più complesso) di uno solo. L'implementazione richiederà log e analisi.

Infine, le autenticazioni a due fattori hanno vantaggi che superano le soluzioni di cui sopra. Tuttavia è il più costoso da implementare in quanto richiede la connessione a un servizio di terze parti (server di posta elettronica, servizio SMS, app dedicata, hardware dedicato, ecc.).

Suggerirei di implementare la registrazione e l'analisi e in base a questi decidi se vuoi implementare il blocco o se vuoi implementare l'autenticazione a due fattori.

Quanti tentativi?

Ci saranno:

• n ₁ tentativi finché non viene visualizzato catpcha.
• n ₂ tentativi fino a quando non viene visualizzata l'ora del nuovo tentativo.
• n ₃ tentativi fino all'applicazione del blocco.

Nota: se utilizzi l'autenticazione a due fattori, la utilizzi fin dal primo tentativo.

I valori di queste variabili possono essere modificati in futuro in base alle tue analisi. Tuttavia, per impostazioni predefinite ragionevoli, considera:

• n ₁ dovrebbe essere una stima del numero di tentativi che una persona può fare se ha problemi a digitare la password . 2 tentativi sarebbero il minimo n ₁ perché ciò spiega l'errore di base dei limiti. Nota: Gmail mi consente 20 tentativi prima di utilizzare CAPTCHA.

• n ₂ dovrebbe essere una stima del numero di tentativi che una persona farebbe prima di andare a accesso al meccanismo di recupero. Non esiste un minimo rigido, infatti può essere applicato non appena si applica CAPTCHA e avere intervalli di tempo crescenti per l'attesa. A mio parere n ₂ = 3 * n ₁ è un buon punto di partenza.

• n _{3 sub> dovrebbe essere una stima del numero di tentativi in ​​cui è più probabile che venga effettuato un attacco. Considera che CATPCHA e il tempo di ripetizione dovrebbero scoraggiare qualsiasi attacco manuale, quindi n 3 non deve essere molto più alto. A mio parere, n 3 = 2 * n 2 è un buon punto di partenza.}

Nota sul tempo di nuovo tentativo : L'intervallo che l'utente deve attendere può essere aumentato a ogni tentativo. Ciò ti consente di utilizzare un intervallo iniziale molto piccolo (ad esempio 1 secondo) e di aumentare da lì fino a un limite massimo (ad esempio 1 giorno).

Nota sul conteggio dei tentativi: dovresti evitare un overflow nel i tentativi contano. Se si memorizza il numero di tentativi nell'oggetto / record dell'account, gestire l'overflow. Se stai eseguendo una query sui log per ottenere il numero di tentativi falliti dall'ultimo riuscito, considera l'aggiunta di un intervallo di tempo (che limiterà anche il tempo della query).

Quello che uso generalmente è una formula di tempo X in Y. 3 tentativi al secondo sono un blocco, ma 3 tentativi in ​​60 secondi vanno bene. 60 tentativi in ​​60 secondi vanno male, ma 60 tentativi in ​​un giorno vanno bene.

Molto dipenderà da ciò che stai cercando di proteggere. Inoltre, se ci sono regole esterne che devono essere seguite come la politica aziendale, HIPAA, ecc.

L'idea generale è che il processo dovrebbe durare abbastanza a lungo che il "cattivo" si arrende e avanza. Detto questo, è importante non legare i tentativi a un accesso, ma anche a un IP e a un intervallo IP.

Molto dipende anche dal processo di "ripristino dell'accesso". Supponiamo che tu esegua un'API che consente ai clienti di ottenere lo stato della spedizione. In caso di blocco, devono chiamare l'assistenza e verificare. In questo caso probabilmente consentirei qualcosa come 120 tentativi ogni due minuetti e qualcosa come 400 tentativi in ​​un periodo di 24 ore. Può sembrare alto, ma con la politica di "ripristino", l'attività dei tuoi clienti potrebbe non funzionare per ore o giorni, se uno dei loro script va in tilt.

L'idea generale è quella di fermare o allungare gli attacchi di forza bruta, ma non di intralciare gli utenti normali, anche quando gli utenti normali utilizzano credenziali errate.

Mi piace il limite di 3 (all'ora e forse 6-9 fallimenti al giorno, 12-18 per quindici giorni), ma i tentativi duplicati con lo stesso codice (in 3 gruppi) non dovrebbero essere conteggiati. Se hai effettivamente dimenticato la password, probabilmente non accedi spesso, quindi può aspettare. È meglio che qualcuno provi troppi tentativi al giorno per indovinarlo.

Ma in base a questo, se ti capita di essere già bloccato, l'utente saprà che qualcuno ha provato a indovinarlo, e quindi noi hai bisogno di una strategia su come gestirlo, specialmente quando vuoi accedere.