La limitazione di tentativi di login

Question

(Questo è in linea di principio un linguaggio indipendente dalla domanda, anche se nel mio caso sto usando ASP.NET 3.5)

Sto usando lo standard ASP.NET controllo di accesso e vorrei implementare il seguente tentativo di accesso non riuscito di limitazione logica.

• Gestire il OnLoginError eventi e mantenere, in Sessione, il numero di tentativi di login falliti
• Quando il conteggio arriva a [un po ' di valore configurabile] blocco di ulteriori tentativi di accesso dall'indirizzo IP di origine o per l'utente / gli utenti per 1 ora

Fa questo suono come un approccio sensato?Mi manca un'evidente che tale verifica potrebbe essere bypassato?

Nota:ASP.NET la Sessione è associato con il browser dell'utente che utilizza un cookie

Modifica

Questo è un sito di amministrazione che è solo andare a essere utilizzato dal regno UNITO e India

Answer 1

Jeff Atwood citato un altro approccio: Invece di bloccaggio un account dopo un certo numero di tentativi, aumentare il tempo fino è consentito un altro tentativo di accesso:

1st failed login    no delay
2nd failed login    2 sec delay
3rd failed login    4 sec delay
4th failed login    8 sec delay
5th failed login    16 sec delay

Questo sarebbe ridurre il rischio che questa misura di protezione può essere oggetto di abusi per attacchi denial of service.

http://www.codinghorror.com/blog/archives/001206. html

Answer 2

L'ultima cosa che vuoi fare è memorizzare tutti i tentativi di accesso non riusciti in un database, che verrà bene il loro lavoro, ma anche rende estremamente banale per gli attacchi DDOS di portare il vostro server di database in giù.

Probabilmente si sta utilizzando un certo tipo di server-side cache sul tuo webserver, memcached o simili.Quelli sono sistemi perfetti da utilizzare per tenere traccia dei tentativi falliti di indirizzo e/o il nome utente.Se una certa soglia, per i tentativi di login falliti è superato, si può quindi decidere di disattivare l'account nel database, ma potrai risparmiare un sacco di letture e scritture archiviazione persistente per il login fallito contatori che non c'è bisogno di persistere.

Se stai cercando di impedire alla gente di brute-forzare l'autenticazione, un sistema di limitazione come Gumbo suggerito probabilmente funziona meglio.Si farà forza bruta attacchi privi di interesse per l'attaccante riducendo al minimo l'impatto per gli utenti legittimi, in circostanze normali, o anche durante un attacco è in corso.Io suggerirei solo di conteggio tentativi falliti da IP in memcached o simili, e se mai diventare il bersaglio di un estremamente distribuito attacco di forza bruta, si può comunque scegliere anche di iniziare a tenere traccia dei tentativi per ogni nome utente, supponendo che gli attaccanti sono in realtà cercando lo stesso nome utente spesso.Fintanto che il tentativo non è molto distribuito, come proveniente da un insieme numerabile di quantità di indirizzi IP iniziale da-codice IP dovrebbe mantenere gli aggressori abbastanza adeguatamente.

La chiave per prevenire problemi con i visitatori provenienti da paesi con un numero limitato di indirizzi IP è quello di non fare le soglie troppo rigida;se non si ricevono più tentativi in un paio di secondi, probabilmente non hanno molto di cui preoccuparsi re.script bruta forzatura.Se siete più interessati con persone che cercano di svelare altro utente password manualmente, è possibile impostare più ampio dei confini per i successivi tentativi di login falliti per nome utente.

Un altro suggerimento, che non risponde alla tua domanda, ma è in qualche modo collegato, è quello di far rispettare un certo livello di password di sicurezza per gli utenti finali.Non vorrei esagerare con posto un misto caso, almeno x caratteri, camere non-dizionario, etc.ecc.password, perché non si vuole bug persone molto, quando essi non hanno ancora firmato, ma semplicemente impedire che le persone usando il loro nome utente password dovrebbe andare un lungo cammino per proteggere il vostro servizio e degli utenti contro il più sofisticato di indovinare perché la chiamano loro forza bruta ;) attacchi.

Answer 3

La risposta accettata, che inserisce crescenti ritardi nei successivi tentativi di accesso, può eseguire molto male in ASP.NET seconda di come viene implementato. ASP.NET utilizza un pool di thread per le richieste di servizio. Una volta che questo pool di thread è esaurito, le richieste in arrivo verranno messi in coda fino a quando un filo diventa disponibile.

Se si inserisce il ritardo con Thread.Sleep (n), si legare un thread pool di thread ASP.NET per tutta la durata del ritardo. Questo thread non sarà più disponibile per eseguire altre richieste. In questo scenario un attacco semplice stile DOS sarebbe quello di mantenere presentando il form di login. Alla fine di ogni filo disposizione eseguire richieste saranno dormendo (e per aumentare periodi di tempo).

L'unico modo che posso pensare di applicare correttamente questo meccanismo di ritardo è quello di utilizzare un gestore HTTP asincrono. Vedere Procedura dettagliata: creazione di un asincrona HTTP Handler . L'implementazione avrebbe probabilmente bisogno di:

1. l'autenticazione Tentativo durante BeginProcessRequest e determinare il ritardo in caso di errore
2. Restituire un IAsyncResult esponendo una WaitHandle che verrà attivato dopo il ritardo
3. Assicurarsi che il WaitHandle è stato attivato (o il blocco fino a quando non è stato) in EndProcessRequest

Answer 4

Questo potrebbe influenzare gli utenti genuini troppo. Per es. in paesi come Singapore, ci sono il numero limitato di fornitori di servizi Internet e di un insieme ridotto di indirizzi IP che sono disponibili per gli utenti domestici.

In alternativa, si potrebbe inserire un captcha dopo x tentativi falliti per contrastare script kiddies.

Answer 5

Credo che sarà necessario mantenere il conteggio di fuori della sessione - altrimenti l'attacco banale è quello di eliminare i cookie prima di ogni tentativo di accesso

.

In caso contrario, un conteggio e lock-out è ragionevole - anche se una soluzione più facile potrebbe essere quella di avere un raddoppio-timeout tra ogni errore di accesso. vale a dire 2 secondi dopo il primo tentativo di accesso, 4 secondi dopo la prossima, 8 ecc.

Per implementare il timeout rifiutando gli accessi nel periodo di timeout - anche se l'utente dà la password corretta -. Basta rispondere con testo leggibile dicendo che l'account è bloccato-out

Anche per monitorare stesso IP / utente diverso e dello stesso utente / IP differente.