Come proteggere dalla forza bruta

Il blocco degli account è un'opzione, in cui l'account è 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 resettare gli account (supponendo che un reset automatico non sia disponibile)

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

Una terza opzione consiste nell'introdurre un ritardo progressivo nel processo di accesso, quindi per ogni accesso errato si provoca un rallentamento del processo. Ciò ha un effetto limitato sugli utenti reali, ma rende molto più difficile la forzatura bruta automatizzata.

In termini di seconda parte della tua domanda sull'identificazione di "qualcuno" che fa 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 sono forzanti brutali su una vasta gamma di utenti, l'IP sorgente (eventualmente combinato con l'agente browser) è un'opzione. Non è perfetto (ad esempio, l'uso di botnet, lo spoofing degli agenti) ma probabilmente è l'unica informazione che dovresti fare.

La risposta a negare la forza bruta consiste nel negare un gran numero di tentativi, in cui il limite è definito dallo spazio chiave e dall'accettazione del rischio.

Ogni situazione avrà soluzioni diverse.

Spazio carne

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

Computer

• Automatizzare gli attacchi di forza bruta significa che devi limitare il limite in qualche modo. Con un limite di velocità, puoi assolutamente conoscere la tua fascia superiore di tentativi per un certo periodo di tempo.
• Monitoraggio: se riesci a limitare i tentativi di forza bruta a una determinata frequenza (forse 500 / giorno), il monitoraggio e gli allarmi possono far sapere a una persona di dare un'occhiata più da vicino a cosa sta succedendo. Quanti tentativi ci vorranno per raggiungere un certo livello di rischio inaccettabile?
• Largo spazio chiave: l'utilizzo di requisiti di password complessi può aumentare notevolmente il numero di tentativi richiesti 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 compromessi come qualsiasi altra cosa nella vita.

• Limitazione della frequenza: può gli utenti legittimi di DoS, non efficaci se l'attacco è di ampiezza prima - un tentativo per ogni account prima di provare una seconda volta
• Tasso di limitazione per IP: non efficace se si tratta di un attacco distribuito
• Complessità della password: di solito è un compromesso in termini di usabilità, il che significa che gli utenti scriveranno le loro password - riducendo la sicurezza di una quantità maggiore rispetto alla minaccia della forza bruta
• Two Factor: potrebbe essere considerato costoso, può perdere i token

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

Nessuna bruteforces manualmente. Quindi, se ci sono dubbi che questo sia umano che cerca di autenticarsi, mostra Captcha, ad esempio, dal tentativo di accesso fallito 3-d. Inoltre è possibile impostare un timeout tra i tentativi di accesso, ma questo non funzionerà per attacchi distribuiti da diversi IP. Successivamente, ci sono due tipi di bruteforcing: cieco, solo cercando l'accesso / password casuali e attaccando alcuni utenti. Per l'ultimo attacco è efficace implementare tali funzionalità come bloccare l'account per un po 'di tempo e avvisare l'utente via e-mail. Per i ciechi la mitigazione della forza bruta può essere più difficile da attuare, specialmente se il sito è popolare. In questo caso è possibile tenere traccia di tali informazioni dell'utente come IP / Paese / Browser / ecc. E calcolando la combinazione di questo, è possibile fare ipotesi sul fatto che si tratti di un utente valido. Come e addendum a questo, puoi giocare con i cookie long-life: una volta che l'utente ha effettuato l'accesso, salva i cookie e in seguito lo controlla.

Senza la soluzione del tipo di applicazione web è possibile implementare soluzioni a livello di server come il mod_evasive di Apache. O anche scrivere il proprio modulo web-server, appositamente per tali scopi.

Certo, ci sono molti altri modi su come rafforzare la mitigazione degli attacchi bruteforce, ma spesso essi risultano essere rumorosi, piuttosto inutili e cattivi. Cerca di mantenere con KISS.

L'importante è come identifica il "qualcuno"?

Non puoi farlo per indirizzo IP - molti utenti potrebbero sembrare avere lo stesso indirizzo client (questo diventerà ancora più frequente con il persistente problema dell'indirizzamento degli indirizzi IPV4).

Potrebbe sembrare che un utente si connetta da più indirizzi client, ad es. usando i proxy con bilanciamento del carico di AOL, o meno legittimamente, via tor.

Qualsiasi altra cosa sono dati forniti dal client - in modo che possano potenzialmente modificare i cookie impostati dall'utente, la stringa user-agent ecc.

L'unico approccio pratico è applicare il punteggio euristico alla richiesta di provare a combaciare con i tentativi precedenti, ma è ancora impossibile distinguere tra attacchi sofisticati e utenti legittimi.

Imposta una soglia di punteggio in base alla quale consideri che il client sta cercando di forzare il tuo sito, ad esempio -20.

Richiedere una sessione valida corrente a cui fa riferimento un cookie di sessione (che è non impostato nella pagina che richiede username / password) è un inizio - se il cookie non viene presentato con i dettagli di autenticazione quindi reindirizzare a una pagina separata che abbandona il cookie e inizializza la sessione con un punteggio di -10, e un punteggio di (say) -2 all'indirizzo IP del client. Potresti utilizzare un meccanismo di punteggio dinamico quando inizi a visualizzare più utenti validi dallo stesso indirizzo. Allo stesso modo, puoi mantenere il punteggio dinamico per user-agent e per nome utente.

Quando cookie + auth viene presentato per un utente inesistente, aggiungi un punteggio di -5 alla sessione, -1 all'indirizzo del cliente, -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 cliente, -4 al nome utente.

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

NB, devi anche impostare un decadimento per consentire a qualsiasi punteggio tenuto contro indirizzo cliente / user-agent / nome utente da recuperare, ad esempio + 2 / ora

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

Se hai bloccato l'accesso con un punteggio elevato per un nome utente specifico, invia un'email con un URL di ripristino all'utente registrato per quell'account in modo che possano reimpostare il punteggio posseduto per il loro nome utente e ridurre il punteggio posseduto per il loro user-agent / indirizzo.

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

Dopo N tentativi falliti metterli contro captcha.

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

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

Inoltre, nessuna di queste risposte prende in considerazione il metodo di forzatura bruta in cui un utente malintenzionato utilizza una password e la prova contro tutti gli account, un'inversione del solito processo e una generalmente non protetta.

Il controllo sarebbe naturalmente quello di avere un monitoraggio del processo per più tentativi contro diversi account con la stessa password, ma ancora molto difficile da bloccare anche se provengono da un singolo indirizzo, come si fa a bloccare quell'IP? Potrebbe essere usato anche da utenti validi, o ti basta inserire gli accessi con quella password - con il rischio di bloccare un utente valido con quella password?

E, naturalmente, se un utente malintenzionato esegue questo genere di cose da una rete distribuita o per un lungo periodo di tempo, come correlare gli incidenti in un profilo di attacco?

I meccanismi generali del settore includono blocco

• su tentativi diretti (superiori a 3, in genere inferiori a 20)
• ritardo progressivo
• strumenti statistici per bloccare gli incidenti che sembrano brute distribuite costringendo

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

• L'utente valido digita erroneamente la password errata
• L'utente valido ha davvero dimenticato la sua password ed è disposto a provare manualmente qualsiasi cosa possa pensare
• L'utente sta tentando manualmente di indovinare la password di qualcun altro
• L'attaccante utilizza lo strumento automatico per forzare la password di un utente specifico
• L'attaccante sta usando lo strumento automatico per forzare la password di qualsiasi utente possibile (cioè la ricerca per ampiezza)
• L'attaccante vuole bloccare un utente specifico dall'accesso al sito
• L'attaccante vuole bloccare la maggior parte degli utenti dall'accedere al sito
• L'attaccante vuole impedire agli amministratori di accedere al sito
• L'attaccante vuole creare un sacco di lavoro manuale, o costa molto la tua organizzazione in qualche altro modo.

(Vedi? Non è così semplice ...) E ci sono diverse soluzioni per ogni 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 un criterio per password complesse, lungo e complesso.
• Rendi il meccanismo della "password dimenticata" facile e notabile. (Certo, assicurati che sia sicuro anche tu.
• Ogni volta che una richiesta di accesso non riesce, registrarla 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, contrassegnare tale utente nel database come bloccato per un breve periodo. Incoraggia inoltre l'utente a utilizzare la funzione "password dimenticata", se questa è nella stessa sessione.
• Quante richieste non riuscite? Dipende . In breve, qualsiasi cosa abbia senso per il tuo sito, il numero esatto non è critico.
• Per quanto tempo dovrebbe essere bloccato l'utente? Brevi intervalli Matematicamente, non importa, purché si disponga di una politica di password complessa. Realisticamente, inizia con un intervallo molto breve di pochi minuti, quindi se continua a farlo aumenta in modo incrementale. Per esempio. dopo 5 cattive prove, bloccare per 5 minuti; dopo altre 3 cattive prove, blocca per 15; dopo un altro 2, bloccare per 30; ecc.
• Non bloccare gli account utente in modo permanente. Ciò porta a Account DoS. E, può anche costare al tuo supporto personale un sacco di tempo e denaro.
• Nonostante il / i punto / i precedenti, se il tuo sito è molto sensibile, ad es. un'app per il settore bancario, potresti voler considerare il blocco permanente fino a nuovo avviso, ad es. fai entrare il cliente nella sua filiale.
• I blocchi dovrebbero essere per nome utente, sul database. Non di sessionId e non nella sessione del server web.
• Se si ricevono molte richieste non riuscite con nomi utente diversi, ma dallo stesso indirizzo IP, implementare il blocco incrementale come sopra, ma con una tolleranza più ampia e intervalli più brevi.
• Fornire una funzione "nome utente dimenticato", oltre alla password dimenticata.
• Gli account amministratore dovrebbero avere una grazia più breve, intervalli più lunghi e mai blocchi permanenti.
• 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 casella di posta dell'amministratore. Ma se continua, quindi eleva il livello di avviso dopo alcune volte.
• Non usare CAPTCHA - la minima difficoltà aggiunta è banale, in relazione al valore dell'accesso alla password dell'utente. (Ci sono molti modi per aggirarlo, CAPTCHA è fondamentalmente rotto, indipendentemente dall'implementazione ).
• Naturalmente, come dichiarato da @ rox0r, l'autenticazione a più fattori potrebbe essere appropriata per te.
• Un'altra alternativa, è quella che viene chiamata " autenticazione adattiva " - se l'utente non ha effettuato il login, chiedere ulteriori informazioni (che erano state preregistrate). A seconda di fattori di rischio aggiuntivi (ad es. Luogo, modelli temporali diversi dal solito, ecc.), Aumentare le informazioni richieste per l'autenticazione corretta. Ad esempio, il prodotto AdaptiveAuthentication di RSA fa questo.

Se si tratta di un sito Web aziendale, utilizzare il certificato e 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.