La risposta per negare la forza bruta è negare un gran numero di tentativi, dove grande è definito dallo spazio della chiave e dall'accettazione del rischio.

Ogni situazione avrà soluzioni diverse.

Spazio per la carne

• Le porte sono rinforzate contro i danni causati dalla forza bruta.
• Sfondare una porta è mitigato dalla possibilità di allertare la polizia.
• Le chiavi hanno solo circa 5 variabili, ma ci vogliono risorse per avere una di ciascuna chiave (più facile attaccare il lucchetto in altri modi che non siano forza bruta)

Computer

• Automatizzare gli attacchi di forza bruta significa che devi in ​​qualche modo limitare la velocità. Con un limite di frequenza, puoi assolutamente conoscere la tua fascia superiore di tentativi per un certo periodo di tempo.
• Monitoraggio: se puoi limitare i tentativi di forza bruta a una certa frequenza (forse 500 al giorno), il monitoraggio e gli avvisi possono far sapere a una persona di dare un'occhiata più da vicino a cosa sta succedendo. Quanti tentativi occorreranno per raggiungere un certo livello di rischio inaccettabile?
• Ampio spazio per la chiave: avere requisiti di password complessi può aumentare notevolmente il numero di tentativi necessari per una certa probabilità di trovare la password.
• Autenticazione a due fattori: la forzatura bruta della password non è sufficiente in questo caso

Tutte le soluzioni hanno anche dei compromessi come qualsiasi altra cosa nella vita.

• Limitazione della velocità: può DoS utenti legittimi, non efficace se l'attacco è di ampiezza per primo - un tentativo per ogni account prima di provare una seconda volta
• Limitazione della velocità per IP: non efficace se è un attacco distribuito
• Complessità della password: di solito è un compromesso nell'usabilità, il che significa che gli utenti annoteranno le loro password, riducendo la sicurezza di una quantità maggiore rispetto alla minaccia di forza bruta
• Due fattori: potrebbe essere visto come costoso, può perdere gettoni

Il blocco dell'account è un'opzione, in cui l'account viene bloccato in modo permanente o per un periodo di tempo dopo x accessi non riusciti. I problemi qui sono i rischi di Denial of Service se un utente malintenzionato tenta di indovinare le password e anche il sovraccarico amministrativo di reimpostazione degli account (supponendo che non sia disponibile un ripristino automatico)

Un'altra opzione è introdurre CAPTCHA nel processo di accesso . Questo ha lo scopo di limitare gli attacchi automatici e bloccare la negazione del servizio dai blocchi degli account. I problemi con esso possono essere i requisiti di accessibilità e il cracking CAPTCHA automatizzato. Da quello che ho visto alcuni CAPTCHA sono più facili da decifrare per il software rispetto ad altri.

Una terza opzione è introdurre un ritardo progressivo nel processo di accesso, quindi per ogni accesso sbagliato fai sì che il processo diventi sempre più lento. Ciò ha un effetto limitato sugli utenti reali ma rende la forzatura bruta automatizzata molto più difficile.

In termini della seconda parte della tua domanda sull'identificazione del "qualcuno" che sta effettuando l'attacco, dipende da cosa stanno facendo . Se stanno solo attaccando un singolo utente, il nome utente è l'identificatore e le azioni sono legate a quell'account. Se stanno forzando brute su un'ampia gamma di utenti, l'IP di origine (forse combinato con l'agente del browser) è un'opzione. Non è perfetto (ad esempio, uso di botnet, spoofing di agenti) ma è probabilmente l'unica informazione su cui dovresti continuare.

L'importante è come identificare il "qualcuno"?

Non puoi farlo tramite l'indirizzo IP: molti utenti potrebbero avere lo stesso indirizzo cliente (questo diventerà ancora di più frequente con il continuo problema della mancanza di indirizzi IPV4).

Può sembrare che un utente si connetta da più indirizzi client, ad es. utilizzando i proxy con bilanciamento del carico di AOL, o meno legittimamente, tramite tor.

Qualsiasi altra cosa sono dati forniti dal client, quindi possono potenzialmente modificare qualsiasi cookie impostato, la stringa dello user-agent ecc.

L'unico approccio pratico è applicare il punteggio euristico alla richiesta per cercare di confrontarla con i tentativi precedenti, ma sarà comunque impossibile distinguere tra attacchi sofisticati e utenti legittimi.

Imposta un punteggio soglia alla quale ritieni che il client stia tentando di forzare il tuo sito, ad esempio -20.

La richiesta di una sessione valida corrente a cui fa riferimento un cookie di sessione (che non è impostato nella pagina che richiede un nome utente / password) è un inizio: se il cookie non viene presentato con i dettagli di autenticazione, reindirizza a una pagina separata che rilascia il cookie e inizializza la sessione con un punteggio di -10 e un punteggio di (ad esempio ) -2 all'indirizzo IP del client. Puoi utilizzare un meccanismo di punteggio dinamico quando inizi a vedere più utenti validi dallo stesso indirizzo. Allo stesso modo potresti mantenere il punteggio dinamico per user-agent e per nome utente.

Quando cookie + auth vengono presentati per un utente inesistente, aggiungi un punteggio di -5 alla sessione, -1 al client address, -5 al nome utente.

Quando cookie + auth viene presentato con una password non valida, aggiungi un punteggio di -3 alla sessione, -1 all'indirizzo del client, -4 al nome utente.

Quando cookie + autenticazione + password valida aggiunge +4 dal punteggio per l'indirizzo client, +3 al nome utente, +2 allo user-agent.

NB è anche necessario impostare un decadimento per consentire il recupero di qualsiasi punteggio tenuto contro indirizzo cliente / agente utente / nome utente, ad esempio + 2 / ora

Devi pensare a cosa succede quando il punteggio supera la soglia. Hai fornito a chiunque un meccanismo per bloccare l'accesso al tuo sito?

Se hai bloccato l'accesso con un punteggio alto per un nome utente specifico, invia un'e-mail con un URL di ripristino all'utente registrato per quello account in modo che possano resettare il punteggio detenuto per il loro nome utente e ridurre il punteggio detenuto per il loro user-agent / indirizzo.

Come suggerisco, intendi il bruteforcing di login / password nell'applicazione web.

Nessuno bruteforza manualmente. Quindi, se ci sono dubbi sul fatto che questo sia un essere umano che cerca di autenticarsi, mostra Captcha, diciamo, dal tentativo di accesso 3-d fallito. Inoltre puoi mettere un timeout tra i tentativi di accesso, ma questo non funzionerà per attacchi distribuiti da IP diversi. Successivamente, ci sono due tipi di bruteforcing: cieco, solo tentativo di login / password casuale e attacco contro un utente. Per l'ultimo attacco è efficace implementare funzionalità come il blocco dell'account per un po 'di tempo e la notifica all'utente tramite e-mail. Per i ciechi la mitigazione della forza bruta può essere più difficile da implementare, soprattutto se il sito è popolare. In questo caso è possibile tenere traccia di tali informazioni sull'utente come IP / Paese / Browser / ecc. E, cercando di combinarle, è possibile ipotizzare se si tratta di un utente valido. Come aggiunta a questo, puoi giocare con i cookie di lunga durata: una volta che l'utente ha effettuato l'accesso, salva il cookie e in seguito lo verifica.

Senza una soluzione di tipo web-application è possibile implementare il server soluzioni di livello come mod_evasive di Apache. O anche scrivere il proprio modulo web-server, specificamente per tali scopi.

Certo, ci sono molti altri modi per rafforzare la mitigazione degli attacchi bruteforce, ma spesso risultano rumorosi, piuttosto inutili e sgradevoli. Cerca di restare con i KISS.

Memorizza i lunghi ips dei precedenti accessi e tentativi di accesso.

Dopo N tentativi falliti metterli contro captcha.

Blocca rapidamente gli indirizzi che non hanno accessi riusciti nella loro cronologia ma un numero di tentativi.

Blocca rapidamente indirizzi che hanno un indirizzo sorgente simultaneo o tentativi inumani a velocità / staminarapidi.

Inoltre, nessuna di queste risposte tiene conto del metodo di forzatura bruta in cui un utente malintenzionato utilizza una password e la prova contro tutti gli account, un'inversione del normale processo e uno contro cui generalmente non è protetto.

Il controllo sarebbe ovviamente quello di avere un processo che monitora più tentativi contro diversi account con la stessa password, ma ancora una volta molto difficile da bloccare anche se provengono da un unico indirizzo, così come blocchi quell'IP ? Potrebbe essere utilizzato anche da utenti validi o semplicemente interrompi gli accessi con quella password, con il rischio di bloccare un utente valido con quella password?

E ovviamente se un utente malintenzionato esegue questo tipo di cosa da una rete distribuita, o su un lungo periodo di tempo, come si correlano gli incidenti in un profilo di attacco?

I meccanismi generali del settore includono il blocco

• sui tentativi diretti (superiore a 3, di solito inferiore a 20)
• ritardo progressivo
• strumenti statistici per bloccare gli incidenti che sembrano forza bruta distribuita

In primo luogo, ha senso capire quali scenari / attacchi intendi gestire:

• Un utente valido digita erroneamente la password sbagliata
• L'utente valido ha davvero dimenticato la sua password - ed è disposto a provare manualmente qualsiasi cosa gli venga in mente
• L'aggressore sta tentando manualmente di indovinare la password di qualcun altro
• L'aggressore sta utilizzando uno strumento automatico per forzare la password di un utente specifico
• L'autore dell'attacco utilizza uno strumento automatico per forzare la password di qualsiasi utente possibile (ad es. ricerca in base all'ampiezza)
• L'attaccante desidera impedire a un utente specifico di accedere al sito
• Il malintenzionato desidera impedire alla maggior parte degli utenti di accedere al sito
• Il malintenzionato desidera impedire agli amministratori di accedere al sito
• L'attaccante desidera creare molto lavoro manuale o costa molto alla tua organizzazione in qualche altro modo.

(Vedi? Non è così semplice, non è ...) E ci sono diverse soluzioni per ciascuna parte di questi ...

• Non rivelare un elenco di nomi utente. Non renderlo più semplice ... Ciò include non rivelare se il nome utente è valido o meno, quando si rifiuta il login.
• Richiedi una policy per le password complesse - lunga e complessa.
• Rendi il meccanismo "password dimenticata" facile e visibile. (Ovviamente, assicurati anche che sia sicuro).
• Ogni volta che una richiesta di accesso fallisce, registra questo nel database. Assicurati di scrivere il nome utente, l'indirizzo IP, l'ora, ecc.
• Se vengono ricevute numerose richieste non riuscite per un nome utente specifico, contrassegna quell'utente nel database come bloccato per un breve periodo. Incoraggia anche l'utente a utilizzare la funzione "password dimenticata", se questa è nella stessa sessione.
• Quante richieste non riuscite? Dipende. In breve, qualunque cosa abbia senso per il tuo sito, il numero esatto non è critico.
• Per quanto tempo l'utente deve essere bloccato? Intervalli brevi. Matematicamente, non ha molta importanza, a patto che tu abbia una politica delle password forte. Realisticamente, inizia con un intervallo molto breve di pochi minuti, quindi se continua aumentalo gradualmente. Per esempio. dopo 5 tentativi sbagliati, bloccare per 5 minuti; dopo altri 3 tentativi sbagliati, bloccare per 15; dopo altri 2, bloccare per 30; ecc.
• Non bloccare gli account utente in modo permanente. Questo porta a Account DoS. Inoltre, può anche costare molto tempo e denaro al personale dell'assistenza.
• Nonostante i punti precedenti, se il tuo sito è molto molto sensibile, ad es. un'app bancaria, potresti prendere in considerazione il blocco permanente fino a nuovo avviso, ad es. fare in modo che il cliente entri nella sua filiale.
• I blocchi dovrebbero essere per nome utente, sul database. Non per sessionId e non nella sessione del server web.
• Se ricevi molte richieste non riuscite con nomi utente diversi, ma dallo stesso indirizzo IP, implementa il blocco incrementale come sopra, ma con grazia più ampia e intervalli più brevi.
• Fornisci una funzione "nome utente dimenticato", oltre alla password dimenticata.
• Gli account amministratore dovrebbero avere una tolleranza più breve, intervalli più lunghi e non bloccarli mai in modo permanente.
• In ogni caso, quando si blocca un utente o un IP, inviare un avviso agli amministratori. Non per il blocco ripetuto, però: non vuoi inondare la posta in arrivo dell'amministratore. Ma se continua, aumenta il livello di avviso dopo alcune volte.
• Non utilizzare CAPTCHA: la difficoltà minima aggiunta è banale, in relazione al valore dell'accesso alla password dell'utente. (Ci sono molti modi per aggirarlo, CAPTCHA è fondamentalmente rotto, indipendentemente dall'implementazione).
• Ovviamente, come ha affermato @ rox0r, l'autenticazione a più fattori potrebbe essere appropriata per te.
• Un'altra alternativa, è la cosiddetta " autenticazione adattiva ": se l'utente non è riuscito a eseguire il login, chiedi ulteriori informazioni (che erano state preregistrate). A seconda di fattori di rischio aggiuntivi (ad esempio posizione, modelli temporali diversi dal solito, ecc.), Aumentare le informazioni richieste per l'autenticazione con successo. Ad esempio, il prodotto AdaptiveAuthentication di RSA fa questo.

Se si tratta di un sito web aziendale, utilizza il certificato più l'autenticazione della password. Senza un certificato valido non arrivano mai al punto di provare a indovinare la password. Puoi anche usare qualcosa come RSA SecurID al posto del certificato.