In quali casi è necessario bloccare un utente dopo un certo numero di tentativi falliti?

Devi proteggere per la maggiore minaccia. Hai 2 scenari:

1. Utente / troll dannoso che sta tentando di negare il servizio a un altro utente. Questa è una preoccupazione relativamente comune, ma è raro vederla in pratica
2. Gli utenti di attacchi di forza bruta: anche se il tuo sito potrebbe non avere dati utili per un utente malintenzionato le stesse credenziali sono altrettanti utenti che riutilizzano le password

Lo scenario 2 è, per la maggior parte dei siti, molto più probabile e per questo motivo avere una politica di blocco è una buona cosa. Captcha (se implementato correttamente) sarebbe utile per impedire ai robot di effettuare ulteriori tentativi di accesso nello scenario 2, dopo il numero x di tentativi che genererebbe uno schermo captcha, sconfiggendo un bot ma gli umani potrebbero sbloccarlo. L'impostazione di avvisi per guasti ripetuti di accesso è un'idea intelligente in modo da poter tenere traccia di questo tipo di cose, così come avvisare gli utenti via email quando accade, in modo che un utente possa dirti se sta agendo o meno.

Se ritieni che lo scenario 1 sia relativamente probabile per il tuo sito, è quindi possibile filtrare l'accesso da un particolare set di indirizzi IP. La maggior parte degli utenti malintenzionati non ha una botnet al loro comando che userebbe solo per tenere un utente bloccato, quindi probabilmente vedrai un pattern. Sarebbe più difficile usare questo metodo contro un aggressore sofisticato, ma usare solo TOR sarebbe sufficiente per sconfiggere il tuo filtraggio. Un buon elemento di protezione che puoi utilizzare per lo scenario 1 è nella progettazione dei dettagli di accesso, non consentendo l'accesso ai nomi utente e l'utilizzo di indirizzi email. In questo modo, se a un troll non piace SmarterPerson1887, dovrebbero conoscere l'indirizzo email dell'utente, che è molto meno probabile.

Come richiesto, preparerò la mia risposta.

If a malicious user B want to block the user A he could try to log with A username's 4 times every 5 minutes. Then A couldn't log to the app.

Questo è il problema quando si bloccano gli account: non si sa se l'utente è effettivamente legittimo fino a quando non ha superato la schermata di accesso. Quindi non puoi supporre che l'utente A stia cercando di accedere all'account A. Se non è un problema per i siti web classici, può essere molto problematico per i webgames (posso bloccare un altro account prima di attaccarli, in modo che non possano difendersi da soli). / p>

Di solito, il motivo per cui il webmaster desidera bloccare gli account è:

I want to avoid a brute force

Ma se il tuo database viene violato, puoi eseguire un attacco offline e bypassare l'approccio anti-brute force per bloccare i conti.

Inoltre, secondo la mia esperienza, gli aggressori raramente forza brutale un account direttamente. Perché? Perché richiede un po 'di tempo per ottenere la password corretta (se è stata scelta bene). In questo modo, gli hacker procedono in un altro modo: elencano tutti gli account sul server e provano le password più utilizzate su ognuno di questi account per account. In qualche modo, invece di provare tutte le password su un account, provano una password su tutti gli account. Pertanto, il tuo sistema anti-brute-force è inefficiente.

IMO, un modo migliore per evitare la forza bruta è semplicemente effettuare il controllo dell'hashing più a lungo (1secondo) , utilizzando iterazioni sufficienti in modo che impieghi 1 secondo (o così) per controllo. In questo modo:

• Se un utente malintenzionato prende di mira un account, avrà bisogno di miliardi di miliardi di anni per violarlo se la password è stata scelta correttamente. Se fanno un attacco parallelo hudge, avranno ancora bisogno di miliardi di anni
• Dovresti già avere un po 'di attenuazione DDoS, quindi nel caso in cui un attacco richieda troppe risorse sul tuo server, allora sarai al sicuro (è un altro campo che i conti anti-brute-force) Ad esempio, puoi "stabilire la priorità" risorse, assegnandole prima agli utenti registrati e lasciando la metà dei rimanenti a quelli non registrati
• Se un utente malintenzionato tenta una password su tutti gli account, avrà comunque bisogno di molto tempo per provare i migliaia di account utente che hai
• Se il tuo database viene violato, l'attacco offline richiederà ancora molto tempo, sufficiente per permettere agli utenti di aggiornare le loro password
• È stateless, quindi non avrai problemi con la memorizzazione di chi ha effettuato un tentativo di accesso, su quale account, ecc.
• 1 secondo è abbastanza breve da essere notabile dagli utenti regolari