Evitare gli attacchi di forza bruta in un modulo di accesso basato sul Web

5

Il mio modulo di login usa Ajax quindi non ha bisogno di ricaricare se la password è sbagliata. Uno script PHP elabora la richiesta e crea la sessione se le credenziali sono corrette. La mia idea è di far dormire lo script PHP per mitigare un attacco di forza bruta. All'inizio non avrebbe dormito affatto, ma dopo non ne sono sicuro.

Per quanto tempo un modulo richiede che un utente malintenzionato attenda di provare la password successiva? Sono ancora raccomandati i lockout completi? Se sì dopo quanti tentativi?

    
posta Celeritas 29.04.2013 - 22:30
fonte

3 risposte

9

Poiché HTTP è un protocollo stateless, non vi è alcun concetto di tempo di attesa tra i tentativi. L'autore dell'attacco può semplicemente generare più processi e provare più password contemporaneamente.

Un modo comune per affrontare il problema e per ridurre l'impatto sul server è l'implementazione di un criterio di blocco, in cui si mantiene un contatore per tenere traccia dei tentativi errati di password per un determinato nome utente in un determinato periodo di tempo (5 tentativi errati in 5 minuti è un valore predefinito comune) e semplicemente si è interrotto il tentativo di autenticare le richieste con tale nome utente per i minuti successivi.

    
risposta data 29.04.2013 - 22:43
fonte
6

Un hacker può facilmente generare più chiamate AJAX in parallelo, questo eviterà il tuo sonno. E potresti finire per intasare le risorse del server. Invece, fai quanto segue:

  • Inizia a mostrare CAPTCHA dopo tre tentativi errati da un IP
  • Dopo un tentativo errato, blocca tutte le nuove richieste di accesso al tuo server da quell'IP per un periodo di tempo. Incrementalo su ogni tentativo fallito.
  • Tieni un registro e osserva i picchi di attività. Se qualcuno sta provando a fare bruteforce, dovresti prenderne nota e contrastarlo.
risposta data 29.04.2013 - 23:36
fonte
1

ACCOUNT UTENTE

Un criterio di blocco (o l'uso della funzione sleep php) per proteggere un modulo di accesso potrebbe in alcuni casi essere anche peggiore (o molto peggiore) di un attacco di forza bruta, in particolare se l'utente malintenzionato ha accesso ai dati di accesso dell'account utente: ad esempio, nei casi in cui i nomi utente pubblici vengono utilizzati per l'autenticazione, che in generale è male, se evitabile. L'utente malintenzionato potrebbe bloccare gli utenti registrati ancora e ancora (DOS), causando un vero disastro. Non farlo mai su un sito web pubblico. È probabilmente molto più facile per un utente malintenzionato sfruttare un sistema di blocco degli account basato sui tentativi di accesso, piuttosto che per uno sviluppatore creare uno efficace. Una soluzione migliore è mantenere le buone pratiche: nascondere quante più informazioni possibili, come al solito, mentre si costringono gli utenti a creare buone password. In questo modo, gli attacchi di forza bruta potrebbero essere totalmente inutili: l'attaccante avrà bisogno di troppe risorse per ottenere qualcosa. In questo scenario, ad esempio, utilizza solo le email per accedere (o qualsiasi altro dato utente che non sia pubblico), mai nomi utente pubblici e mai renderli visibili e raccoglibili da altri utenti o pubblico. Ma non applicare un criterio di blocco sugli account utente.

IP

Un buon attacco DOS è fatto da molti IP differenti. Detto questo, è possibile applicare un criterio di blocco sul server Web per evitare attacchi DOS e Brute Force rilevando richieste eccessive da un singolo IP (richieste di qualsiasi tipo e non solo su una pagina di accesso o un modulo). Gli hosting condivisi adottano spesso politiche di questo tipo nella mia conoscenza e generalmente non devi preoccuparti troppo di te dato che non puoi cambiarle. Ma se devi configurare un server dedicato, questo può essere un po 'più complicato: questo è un argomento per gli amministratori di server, più degli sviluppatori web. Se usi Apache, potresti essere interessato a qualcosa di simile: link

E: link

    
risposta data 06.07.2013 - 00:44
fonte

Leggi altre domande sui tag