Adeguata prevenzione degli attacchi brute force distribuiti?

if you provide wrong or right credentials, the login script will sleep for 1 second while verifying your credentials

Questo non sarebbe efficace a meno che questo sleep non sia stato eseguito su thread - cioè questo non fermerebbe un attacco parallelo in cui un utente malintenzionato effettua più connessioni ed esegue tentativi di accesso simultanei.

Se hai fatto in modo che questo ritardo si estendesse sui thread, allora avresti introdotto un punto di strozzatura nella tua applicazione. Supponiamo che l'1% degli utenti abbia tentato di accedere allo stesso tempo, l'ultimo utente dovrà attendere 500 secondi per completare il login.

Rallentare l'intera applicazione non è una buona idea in quanto ciò sta creando un Denial of Service (DoS) o un servizio ridotto per i tuoi utenti reali.

what if someone tries to distribute this brute force attack over multiple usernames/accounts for a same password?

Il modo per evitare ciò è rendere la tua applicazione sicura contro l'enumerazione del nome utente . I modi comuni in cui gli utenti malintenzionati possono enumerare i nomi utente sono:

• Dopo un accesso errato, se la pagina di accesso mostra che il nome utente è errato anziché la combinazione nome utente / password.
• Se la pagina di registrazione dell'utente informa gli utenti che il nome utente è già in uso.
• Se la pagina della password dimenticata informa l'utente che il nome utente inserito non è stato trovato.
• Se alcuni URL sono attivi per utenti validi (ad esempio, il mio nome utente è foo ) come www.example.com/user/foo .

Ci sono modi per prevenire la registrazione degli utenti e le pagine delle password dimenticate che rivelano se un nome utente è registrato se il nome utente è basato su indirizzo email. A volte la capacità di enumerare gli utenti che ha incorporato nel design dell'applicazione e impedire ciò non è possibile. per esempio. in un'applicazione webmail tutti i nomi utente sono effettivamente pubblici poiché Bob pubblicizzerà l'account [email protected] se desidera che le persone li inviino via email.

Oltre a fare quello che stai facendo con ipotesi sbagliate a un utente valido, vorrei fare anche per gli accessi dallo stesso IP. Questo ridurrà la velocità con cui le password possono essere indovinate orizzontalmente rispetto ai diversi utenti. Il ritardo artificiale potrebbe iniziare dopo 5 tentativi falliti dallo stesso IP e il tempo potrebbe essere gradualmente aumentato per tentativo.

Sebbene ciò non ti protegga completamente da una rete bot, limitando separatamente sia l'IP che il nome utente ripetuti tentativi ridurranno il rischio di attacchi di forza bruta.

Se vuoi ridurre completamente la minaccia della forza bruta botnet, puoi applicare un requisito per 2FA su tutti gli account. Questo potrebbe essere fatto tramite un OTP inviato via SMS.

Un po 'in ritardo qui ma ci sono un sacco di suggerimenti qui: link

Un problema con "ci vorranno circa 14 ore per provare una password su account 50k" è cosa succederebbe se il tuo utente legittimo tentasse di accedere dopo che una rete di bot ha inserito richieste di 50k e ha dovuto attendere le 14 ore? Non felice presumibilmente.

Il tuo metodo potrebbe essere alquanto efficace, ma il difetto più grande e più ovvio è che stai rallentando intenzionalmente la tua applicazione! Potrebbe essere tollerabile se la tua base di utenti sarà limitata a un paio di amici, ma se apri questa applicazione al mondo, un rallentamento intenzionale sarebbe del tutto inaccettabile dal punto di vista di un ingegnere. Un secondo potrebbe non sembrare molto, ma per gli utenti impazienti in questi giorni, ogni secondo conta . Se si aggiunge il tempo per il download e il rendering della pagina, il tempo di caricamento per la pagina di accesso potrebbe facilmente raggiungere 3-4 secondi o più, il che può sembrare un'eternità quando si è seduti lì ad aspettare.

Inoltre, sarebbe efficace solo se si presuppone che ogni singolo utente sceglierà una password sicura, il che è altamente improbabile che sia il caso. Le probabilità sono che una buona fetta di loro sceglierà qualcosa di semplice e comune, come 123456, password1 o password123 - e un attaccante proverà quasi sicuramente a provare per primo. Se trascorrono 140 ore provando le prime 10 password per ogni account, non sarei sorpreso se il 5% di esse fosse compromesso, il che è un numero piuttosto consistente.

Una soluzione più ordinata che molti dei principali siti utilizzano ora è l'uso di un Captcha (il testo distorto che devi leggere e digitare). Dopo circa 5 tentativi di accesso non corretti da un singolo indirizzo IP (indipendentemente dall'account), è necessario risolvere un captcha per continuare a provare le password. Questo è molto efficace nell'arrestare la forza bruta perché uno script a forza bruta non sarà in grado di risolvere il captcha.

Non preoccuparti se non sai come generare immagini captcha - Google può farlo per te . È molto facile da usare; devi solo registrare il tuo sito con il programma di recaptcha (gratuito) di Google, copiare un po 'di codice nel tuo sito web e Google farà il difficile lavoro. Qui è un piccolo tutorial su come usarlo. Ciò che è bello è che ultimamente lo hanno rinnovato per poter ora distinguere i bot dalle persone senza richiedere il testo distorto a>.

Una soluzione alternativa è semplicemente bloccare l'indirizzo IP degli utenti dopo un certo numero di password errate, indipendentemente dall'account, ma l'ovvio svantaggio di questo è che se qualcuno è forzato bruto da una rete pubblica (una libreria, ad esempio ), gli utenti legittimi potrebbero essere bloccati. Personalmente continuo a pensare che la soluzione captcha sia la migliore, perché è molto efficace nell'arrestare la forza bruta e nel contempo avere un impatto minimo sugli utenti legittimi.