Best practice nell'autenticazione della sicurezza delle applicazioni Web per evitare attacchi bruteforce

Un modo relativamente user-friendly di mitigare attacchi a forza bruta sta ritardando il tempo minimo tra i tentativi. La prima volta che l'utente inserisce credenziali errate, gli permetti di aspettare un secondo prima che possa riprovare. La seconda volta, lo lasci aspettare 2 secondi. La terza volta, lo fai aspettare 4 secondi. 4a volta, 8 secondi e così via. Lo si basa anche sul nome utente utilizzato per l'autenticazione, non sugli indirizzi IP. Se non è stato effettuato alcun tentativo negli ultimi 5 minuti (o se l'utente è stato autenticato correttamente), il contatore viene resettato.

Il risultato è che un utente che fa un errore di battitura nella propria password non viene influenzato le prime volte, ma qualsiasi forzante bruto raggiungerà molto rapidamente un punto in cui la forza bruta non è più praticabile.

Oltre a impedire la tua applicazione web contro gli attacchi a forza bruta, devi anche garantire pratiche di protezione della password standard come hashing e amp; salatura (preferibilmente con PBKDF2 o bcrypt), ripristino sicuro della password e attenuazione contro l'enumerazione dei nomi utente. Ma suppongo che, dal momento che pubblichi qui, lo sai già.

Un buon compromesso tra esperienza utente e sicurezza sarebbe avere i captcha basati su IP che si attivano dopo alcuni accessi non riusciti da un particolare IP, indipendentemente dal nome utente.

• Questo approccio non è vulnerabile agli attacchi DoS contro un singolo utente bruteforcing del suo account fino a quando il tempo di backoff raggiunge diverse ore / giorni e impedisce al legittimo proprietario dell'account di accedere.

• Il numero di persone bloccate dietro un NAT non è così elevato, ed è meglio degradare leggermente la propria esperienza con un captcha piuttosto che con gli aggressori prioviding con la possibilità di eseguire un account DoS completo e bloccare i legittimi proprietari.

• Dipende da cosa è la tua app e per quanto tempo è la durata della sessione, ma se si tratta di qualcosa come Stack Exchange, la gente di solito non effettua il log in e out frequentemente.

Per quanto riguarda le tue preoccupazioni sull'uso delle sessioni per tenere traccia degli accessi non corretti, hai ragione, è inutile dato che funzionerà per utenti legittimi, ma un utente malintenzionato non si preoccuperà nemmeno di memorizzare i cookie di sessione, il che significa che a ogni tentativo lo farà ottieni una nuova sessione e nuovi tentativi di accesso senza captcha.

Per il cambio di IP, sì, è un po 'un problema, ma un IP è ancora un costo per l'attaccante, alla fine finirà per finire i proxy e / o le macchine compromesse nella sua botnet, e dovrà comprare Di Più. Dovresti inoltre sempre richiedere un captcha se l'IP si trova in un database proxy aperto (cercane uno su Google) o nell'elenco dei nodi di uscita di Tor; in questo modo un utente malintenzionato non sarà in grado di utilizzare queste soluzioni "gratuite" e dovrà noleggiare una botnet o alcuni proxy "premium" che non sono ancora nelle liste nere.

Ho fatto delle ricerche su come mitigare gli attacchi di forza bruta e ho trovato questo post. Recentemente ho implementato il seguente approccio:

In un periodo di 24 ore: in 20 o più tentativi di autenticazione falliti per un singolo indirizzo IP richiediamo captcha per ogni tentativo successivo. A 100 tentativi falliti, abbiamo richieste di blackhole, ma non diamo alcuna indicazione che la richiesta è stata segnata, continuiamo a restituire il messaggio di errore standard.

Per noi è ragionevole perché non siamo preoccupati di grandi quantità di persone che accedono dallo stesso IP e riteniamo che le nostre soglie siano abbastanza elevate da non interessare un utente normale. È banale inviare un avviso a 100 errori o se un nome utente appare su più indirizzi IP.

Registriamo tutto in un database. Ammettiamo che una botnet possa utilizzare una grande quantità di IP, tuttavia registriamo il nome utente con cui un IP non è riuscito a autenticarsi. Questa tabella viene generalmente controllata una volta al giorno, quindi esiste potenzialmente la possibilità di identificare un attacco di forza bruta su larga scala rivolto a un singolo utente.

Inoltre, abbiamo recentemente migliorato i nostri requisiti di password per aumentare la lunghezza e la complessità dei caratteri, oltre a non consentire password che si trovano in vari dizionari di password. La nostra pagina di accesso non è indicizzata in Google (non in robots.txt, usa il tag meta robots perché gli hacker possono controllare il tuo robots.txt per pagine interessanti). Infine, gli account amministratore richiedono l'autenticazione a due fattori.

Tuttavia accettiamo il rischio che un attacco di forza bruta sia possibile.