Prevenzione della forza bruta: dove e quando?

Le misure del lato client sono solo una soluzione parziale (e soprattutto cosmetica), ciò può limitare solo i tentativi non gravi. Qualsiasi tentativo grave colpirà il tuo server direttamente perché è stato rilevato un URL / API di accesso o eseguirà il tuo client tramite un proxy di intercettazione per acquisire i dettagli richiesti per creare un'esecuzione di forza bruta.

Solide difese generalmente richiedono di assumere che l'attaccante sappia tutto sul sistema eccetto la chiave segreta ( Principio di Kerckhoff ), quindi dovresti iniziare da quella posizione.

Le misure di attenuazione includono:

• rendere difficile / impossibile per un utente malintenzionato determinare nomi utente validi, password non valide o account bloccati (feedback fondamentalmente minimi, ovvero nessun messaggio "nome utente non valido" o "password troppo lunga", sebbene emettere un codice incidente univoco se questo è importante per il supporto degli utenti). Come indicato nel commento di My1 , la registrazione aperta potrebbe essere un punto debole qui.
• rende difficile determinare qualcosa di diverso dal successo o dall'errore, un login fallito dovrebbe richiedere lo stesso tempo di un successo - questo di solito significa renderlo artificialmente lungo (200ms è un punto di partenza)
• rendere l'API di accesso multi-step utilizzando un token nonce o un po 'di tempo o di sessione per complicare gli attacchi automatici e prevenire attacchi distribuiti; o aggiungi qualche prova del lavoro sul lato client (l'hashing della password lato client è una opzione, ma richiede attenta considerazione )
• assicurati che lo spazio della password sia sufficientemente ampio, incoraggi (e supporti!) l'uso di un gestore di password
• utilizza il blocco degli account e il blocco dell'IP di origine con tempi di blocco esponenzialmente crescenti (ad esempio raddoppiando il tempo di blocco su ciascun errore, questo dovrebbe evitare di annoiare un utente che riceve una password errata un paio di volte). Come notato nei commenti, questa è un'opportunità per DOS, quindi considera attentamente i compromessi
• implementare il controllo adattativo della velocità e il rilevamento di attività dannose (in genere è più difficile rispetto a qualsiasi altra soluzione in quanto richiede ulteriore stato e logica sul lato server)
• considera l'aggiunta di una modalità operativa "sotto attacco" che può essere abilitata come richiesto, idealmente questo avrà un impatto minimo sugli utenti

Da CAPEC-112 Forza brutale :

The key factor in this attack is the attackers' ability to explore the possible secret space rapidly. While the defender cannot control the resources available to an attacker, they can control the size of the secret space. The defender must rely on making sure that the time and resources necessary to do so will exceed the value of the information.

Vedi anche CAPEC-49 Forza bruta password

Il modo abituale di prevenire un attacco a forza bruta consiste nell'aggiungere un piccolo ritardo sul server.

Come è stato sottolineato in un commento da parte dell'utente immibis , un utente malintenzionato non ha bisogno di utilizzare la tua app per eseguire un DoS o un DDoS. Tutto ciò di cui l'attaccante ha bisogno è l'endpoint, quindi possono inondarlo. E possono trovare l'endpoint eseguendo il reverse engineering del file .apk o semplicemente monitorando il traffico in uscita.

Quindi la difesa deve essere sul lato server. Aggiungendo un po 'di ritardo dopo ogni tentativo di accesso fallito (ad esempio 1 secondo), diventa impossibile per un utente malintenzionato provare milioni di possibili combinazioni di nome utente / password.

Se desideri proteggere il tuo server dagli attacchi DDoS in generale, hai bisogno di una server farm strong o di un servizio come CloudFlare.

Un aspetto importante è se nel dispositivo è presente qualsiasi tipo di materiale chiave che può essere utilizzato per autenticare il dispositivo o se un utente può semplicemente prendere un dispositivo nuovo di zecca, scaricare l'app ed effettuare il login.

Se sul dispositivo è presente materiale chiave, è possibile che il server applichi i limiti di velocità per dispositivo. Altri modi di applicare i limiti di frequenza lato server (come i limiti di velocità per IP o per nome utente) sono potenziali vettori di attacco DoS. Ciò è vero indipendentemente dal fatto che il limite di velocità sia implementato facendo in modo che il server esegua calcoli pesanti della CPU come parte della convalida della password o da blocchi temporanei.

Quando si ha il controllo del codice client e server è possibile progettare un protocollo in cui la parte pesante della CPU della convalida viene eseguita lato client, ma il server esegue ancora un hash salato per assicurarsi di avere ancora i vantaggi del server convalida laterale. Ovviamente se implementate una cosa del genere da zero vi è il rischio di vulnerabilità introdotte da difetti nella progettazione o implementazione.

Il vantaggio di fare parte della parte client della CPU è che elimina principalmente il vettore di attacco DoS. Uno svantaggio di fare parte della parte client della CPU intensiva è che il client potrebbe essere limitato nelle risorse della CPU.

È possibile combinare gli approcci precedenti. Al primo accesso potreste fare in modo che il client esegua l'hashing per più secondi, ad esempio inviando un salt al client e facendolo fare molti round di hashing, infine il server esegue l'ultimo ciclo di hashing con un diverso salt. Se la password viene accettata, il dispositivo invia un token che consentirà al client di autenticarsi sullo stesso account con un hash secondario molto più economico in futuro. Il server può imporre un limite su quanti tentativi di accesso non riusciti con il token sono consentiti prima che il token sia scaduto e il client ritorni all'hash più lento.

Ancora una volta devo avvertire che ci sono molti modi per introdurre difetti di sicurezza in un progetto come questo, quindi devi correre rischi in termini di rischio di attacchi brute force.

Potrebbe essere possibile combinare il tarpitting del dispositivo e la prova di lavoro:

Se ogni dispositivo doveva connettersi utilizzando una chiave autofirmata (~ 4096 bit) come identità del dispositivo e utilizzata per limitare la velocità:

O

• ogni dispositivo spende troppo tempo generando nuove chiavi; ritardando così i tentativi di password
• molti accessi si verificano con la stessa chiave client; garantito come un singolo dispositivo malevolo, quindi può essere bloccato senza il rischio del servizio DOS.
• si verifica una condivisione in stile botnet di chiavi e accessi; limitato dalla potenza dei dispositivi disponibili per generare nuove chiavi --- quanto è prezioso un target per il tuo servizio e per quanto tempo puoi far aspettare gli utenti per la prima generazione di login / generazione di chiavi certificate?

Oppure rendilo solo un problema di qualcun altro: utilizza un sistema di autenticazione a 2 fattori pubblico.