La limitazione del login è ancora necessaria se impieghiamo l'autenticazione a più fattori?

Se la limitazione della velocità di accesso è implementata correttamente, non ci sono aspetti negativi, e dovrebbe essere usata con o senza 2FA (e in effetti con i tentativi 2FA stessi). E blocco account è non il modo corretto per limitare i tentativi di accesso.

Limitare la velocità significa limitare il numero di tentativi che una determinata fonte può effettuare. In genere questo significa un dato indirizzo IP, anche se è possibile definire "fonte" comunque ha senso nella propria situazione.

Ci sono davvero tre tipi di attacchi che stai cercando di difendere da qui:
(a) L'hacker conosce la password - in questo caso i blocchi non saranno d'aiuto un po '.
(b) La password è facilmente intuibile, come "123456" o "passw0rd" o "zxcvbn". Anche in questo caso, i blocchi degli account non saranno utili perché questi aggressori non tentano più di 5 o 10 password al massimo prima di passare al prossimo account. Spesso ne proveranno solo uno. Devi bloccare l' attacker , non l'account . (c) L'utente malintenzionato sta effettuando un determinato viaggio su un singolo account ad alto valore e proverà l'intero dizionario e poi alcuni. La password potrebbe non essere facile da indovinare, ma l'aggressore ha tutto il mese.

Non c'è molto che possiamo fare sulla condizione (a) sopra, sebbene 2FA possa aiutare. La condizione (b) è estremamente comune mentre (c) è un po 'più rara perché il tasso di successo è così basso. Ma, cosa importante, entrambi possono essere vanificati rallentando l'aggressore.

Idealmente questo non significa un limite rigido di 15, e quindi aspetti 10 minuti. Idealmente, fai un back-off esponenziale. Ciò significa che dopo 2 tentativi, si attende diversi secondi. Dopo il terzo, aspetti ancora un po '. E poi più lungo dopo il quarto e così via. Il limite viene applicato nel back-end e nel front-end si utilizza una logica lato client come un timer in javascript per impedire all'utente di inviare tentativi durante il periodo di attesa.

Ho spiegato questa tecnica qui diverse volte, quindi non approfondirò i dettagli. Ma la cosa importante è che è semplice da costruire, non disturba notevolmente gli utenti legittimi, ma fa funziona molto bene contro determinati attaccanti. Rallentandoli, si imposta in modo efficace un limite rigido al numero di tentativi che possono effettuare in un determinato intervallo di tempo, ma si riduce gradualmente il limite tra i tentativi. E ancora meglio, è possibile rilevare quali utenti continuano a inviare tentativi durante il periodo di attesa, che li contrassegna come utilizzando un software specializzato per aggirare il limite di velocità del client. Cool!

Se imposti le cose in questo modo, non c'è motivo di disabilitare la limitazione della velocità. Non ha alcun inconveniente, è in gran parte invisibile agli utenti e offre una ragionevole difesa in prima linea contro gli aggressori a forza bruta.

Questo lascia solo lo scenario di un attacco distribuito contro un singolo accesso da una botnet di grandi dimensioni. Questo è abbastanza raro da non accadere mai per la maggior parte dei siti, ma è abbastanza semplice da rilevare e indirizzare, quindi lo lascerò come esercizio al lettore.

Se il 100% della base utenti utilizza 2FA su tutti gli accessi, potrebbe non essere altrettanto importante, tuttavia potrebbe essere comunque necessario valutare il limite dei tentativi 2FA come minimo. Alcuni servizi utilizzano solo un codice a 4 cifre inviato via SMS con una finestra di 5 minuti, nel qual caso è plausibile che un utente malintenzionato possa forzare il codice. In altre parole, probabilmente hai ancora bisogno di limitare il tasso da qualche parte per evitare di diventare meno sicuro.

Raccomando comunque di limitare i tassi di accesso e 2FA:

• Le funzioni di crittografia sono in genere molto costose dal punto di vista computazionale, pertanto un utente malintenzionato potrebbe potenzialmente eseguire un attacco DOS eseguendo un volume elevato di richieste di accesso non valide.
• Non sai se il tuo dispositivo degli utenti è stato compromesso o rubato, allora gli aggressori potrebbero ancora tentare un attacco di forza bruta.
• 2FA di solito è opt-in, quindi è raro avere il 100% di iscrizione e altrimenti dovresti comunque votare utenti limite senza 2FA.

Raccomando anche di limitare i tassi. Meglio tenere d'occhio le cose.

Ecco cosa facciamo nel server WiKID. Il server bloccherà l'utente dopo un numero (admin configurabile) di tentativi di passcode errati, ma ignorerà i passcode non numerici. Ciò impedisce all'utente di essere bloccato da un semplice tentativo di forza bruta, ma ti protegge da codici indovinati.

Abbiamo creato una voce di log che è stato tentato un passcode non numerico. Ti consigliamo di esaminarli per vedere se l'autore dell'attacco utilizza una credenziale rubata valida.

(Si noti che alcuni token basati sul tempo o sul contatore possono essere configurati in modo che più di un passcode possa essere valido in un dato momento per consentire la risincronizzazione per la deriva di clock / contatore.)