Devo implementare il ritardo della password errata in un sito Web o un servizio web?

Suppongo che la tua intenzione con il ritardo di fallimento sia di prevenire attacchi di forza bruta: se un utente malintenzionato tenta di indovinare la password di un utente, per prima cosa fallirà molte volte; se riusciamo a fare in modo che quei fallimenti impieghino più tempo, allora renderà l'attacco un ordine di grandezza più difficile, e quindi improbabile che abbia successo (in un ragionevole lasso di tempo).

Tuttavia.

Ciò presuppone che l'attaccante attenda pazientemente tra i tentativi di accesso. E, come tutti sappiamo, i cyberhacker sono gente molto educata e paziente.
Detto questo, alcuni attaccanti potrebbero scegliere di NON aspettare e semplicemente inviare molte richieste in parallelo. Se un tentativo di accesso non riceve immediatamente una risposta, l'attaccante può interpretarlo come un tentativo fallito, uccidere quella richiesta e passare alla successiva.

Un ulteriore vantaggio di questo schema è che sarebbe molto più semplice per un utente malintenzionato creare un carico irragionevole sul server (basta inviare molte richieste di accesso non riuscite, ognuna occuperà un thread per diversi secondi ...) , e forse anche riuscire a fare il server.

In effetti, il problema principale di questa soluzione è che NON impedisce precisamente molte richieste parallele. Se un attaccante sta tentando un attacco brute force online, non siederà davanti alla tastiera digitando molte password, una dopo l'altra, alla stessa velocità di Hugh Jackman - se così fosse, saresti solo a rischio se l'utente ha una password morta semplice.
In realtà, avrà uno script o uno strumento automatico che invierà (quasi) tutte le richieste che il server può gestire, e poi continuerà. Il rischio non è che qualcuno provi 30 password diverse al minuto, sono 1000 password al minuto o 10.000.

Il modo solo per impedire che sia la limitazione utente / blocco account / sospensione incrementale - chiamalo come vuoi, questa è fondamentalmente la stessa idea di consentire il numero X di tentativi di accesso per account entro un determinato lasso di tempo.
Quindi, anche se questo non riduce a "un singolo tentativo di accesso alla volta", si avvicina abbastanza.

Una parte del problema è che mantenere aperta la connessione mentre aspetti che il ritardo scada utilizza risorse preziose, in particolare in determinate configurazioni popolari in cui il numero di connessioni simultanee consentite è piuttosto ridotto.

Una soluzione ideale è progettare il tuo sistema come segue:

• Progetta la logica prima nell'interfaccia utente. Un accesso non riuscito restituisce immediatamente lo stato di errore, ma c'è un ritardo prima che l'UI si ripristini per consentire un ulteriore tentativo di accesso. Questo non è per applicare la regola , ma piuttosto per garantire che un utente ben educato non veda mai un messaggio di errore.

• Applicare la logica sul back-end restituendo immediatamente uno stato di errore per qualsiasi tentativo di accesso durante il periodo di "raffreddamento". Non controllare nemmeno per vedere se la password fosse corretta, fallisci immediatamente consumando il minor numero di risorse possibile.

• Per verificare se è ancora consentito un tentativo di accesso, la soluzione migliore è utilizzare qualcosa di leggero, come memcached. Ad esempio, dopo un tentativo fallito con un determinato nome utente, memorizza in memcached l'ora in cui termina il raffreddamento. Quindi, quando si mettono in campo nuovi tentativi di password, selezionare la voce in memcached per vedere se il periodo di defaticamento è ancora scaduto.

• Applica la stessa logica su base per-IP, non solo in base al nome utente. Non dovrei essere in grado di indovinare migliaia di password al secondo solo ruotando attraverso i nomi utente.

• Implementa un backoff esponenziale. Questo è un po 'di credito extra, ma 2 tentativi in 1 secondo non sono un grosso problema, ma 50 tentativi in 5 minuti sono un grosso problema. Questo potrebbe essere un po 'più difficile da progettare, ma i guasti ripetuti dovrebbero innescare tempi di ripristino più lunghi. Questo potrebbe essere semplice come mantenere un contatore di errori (di nuovo, in memcached) e calcolare il prossimo raffreddamento come funzione di quel contatore. La logica per-IP dovrebbe essere un po 'diversa, tuttavia, dal momento che non vuoi che l'hacker sia in grado di resettare il suo contatore semplicemente inviando le credenziali di un utente conosciuto.

Vuoi che il tuo server faccia il minor lavoro possibile, per evitare di farlo da solo. Il blocco degli account è ottimo per fare i tuoi utenti.

if count (autenticazioni non riuscite per nome utente U) > soglia quindi richiesta CAPTCHA

if count (autenticazioni non riuscite per la password P) > soglia quindi richiesta CAPTCHA

se non ti piace CAPTCHA allora richiedi Prova di lavoro

(fai in modo che il client calcoli i fattori primi di un vero grande numero)

Un ritardo tradizionale attenuerebbe gli attacchi basati sul browser, ad esempio se qualcuno usa phantomjs per automatizzare i tentativi di accesso, il normale ritardo (nel tuo caso "più di un secondo") sarebbe sufficiente per impedire a chiunque di forzare una password , ci vuole solo troppo tempo.

Tuttavia, la maggior parte degli attacchi di forza bruta non viene eseguita nei browser Web ma in ambienti con script in cui possono inviare più richieste contemporaneamente.

Il modo in cui lo implementerei è di avere un ritardo intenzionale sul lato server dopo un login non riuscito, oltre a un meccanismo di limitazione (qualcosa come questo ) e un messaggio front-end o spinner che informa l'utente che le credenziali vengono controllate (nessuno vuole una pagina vuota per un ricaricamento o un sistema apparentemente sospeso per < em> un lungo tempo)