Salva temporaneamente gli accessi password non riusciti per l'utilizzo contro l'attacco brute force

La risposta dipenderà completamente dal modo in cui definisci il tuo modello di minaccia e dalla tua propensione al rischio.

Dal momento che sei arrivato al punto di identificare i potenziali attacchi con una buona dose di dettagli, suppongo che tu creda che queste siano credibili e possibili minacce che affronti. Se non è il caso, non ci dovrebbero essere motivi per cercare di proteggerli.

Pro

• Come fai correttamente notare, memorizzando temporaneamente gli hash di fallito i tentativi di password potrebbero potenzialmente darti i dati necessari rilevare più efficacemente un attacco come descritto nello scenario 3. Se questo processo può quindi richiedere un prompt captcha o qualche secondo fattore di autenticazione sicuramente ostacolerà i tentativi di attaccante abbastanza per rendere l'attacco poco pratico.
• Potresti imparare molto sulla natura di questi attacchi dai dati raccolti, come il tipo di password che gli aggressori tentano e come le attraversano (forza bruta semplice contro attacchi di dizionario). Questo è più un guadagno accademico di quanto non sia direttamente correlato alla sicurezza del tuo sistema, anche se potresti identificare tendenze a lungo termine che potrebbero portare a migliori tecniche di identificazione in futuro.

Contro

• La considerazione principale che dovrai fare qui è se il compromesso tra maggiore sicurezza e risorse extra e l'elaborazione richiesta valga la pena. Ciò è dovuto al fatto che i confronti che si intendono effettuare possono essere molto dispendiosi dal punto di vista computazionale e richiedere una quantità significativa di risorse aggiuntive (a seconda della dimensione del sistema e della quantità di tentativi di accesso che si prevede di ricevere).
• Sospetto che il confronto che intendi fare per identificare questi attacchi descritti nello scenario 3 non sia semplice e immediato come sembra all'inizio. In primo luogo, come affermato in precedenza, potresti aver bisogno di più risorse per archiviare e confrontare gli hash delle password. Nella descrizione dello scenario 3 si presuppone che la richiesta proveniente da vari IP tenterà tutti la stessa password in tutti gli account possibili alla volta. Ciò significa che non sarai in grado di elaborare ogni richiesta di log di per sé ma piuttosto che dovrai valutare i tentativi di accesso come batch per essere in grado di vedere che ci sono più tentativi di accesso su vari account che utilizzano la stessa password esatta. Ricordare che un utente legittimo potrebbe tentare di accedere in coincidenza con l'attacco e che l'intero batch di tentativi di accesso dovrà essere interrogato se si sospetta la riproduzione di pollo. Ciò potrebbe portare a un'esperienza degradata dal punto di vista dell'utente se dovesse accadere spesso. Sarà anche difficile determinare per quanto tempo un certo hash dovrà essere memorizzato dopo che è stato contrassegnato come artefatto di un attacco sospetto specifico. Non è possibile mantenere l'hash lì a tempo indefinito poiché potrebbe essere l'hash della password di un utente legittimo che verrà quindi continuamente interrogato e questo potrebbe portarti essenzialmente al "DDoSing" del tuo sistema. Se decidi di implementare un sistema come questo, solo tracce ed errori nel tempo saranno in grado di indicare come deve essere configurato per funzionare efficacemente senza essere troppo oneroso.

Se il tuo scopo è proteggere i tuoi utenti e i loro dati sul tuo sistema piuttosto che identificare in modo specifico questi attacchi, ti suggerirei piuttosto di implementare (possibilmente anche richiedendo) un meccanismo di autenticazione a più fattori. Educare i tuoi utenti alle minacce che affronti ei vantaggi dell'utilizzo dell'autenticazione a più fattori per proteggerli potrebbe essere un approccio molto migliore per proteggere il sistema con molto meno frizione e sforzi da parte tua.

Non vedo il punto di preoccuparmi del tuo scenario n. 3; quella tattica avrà lo stesso successo dello scenario n. 4:

4. Una rete bot con targeting per molti account che tenta una delle tante password comuni per ogni tentativo.

Immagina di avere un milione di utenti, il 10% dei quali usa casualmente una delle 1000 password più comuni ( 123456 , password , letmein , ...). Se una rete bot tenta di attaccare tutti i milioni di account con la prima password nell'elenco e quindi prova la seconda password nell'elenco, lungo la linea, ogni tentativo di accesso avrà 1 possibilità su 10000 di funzionare. Se la botnet sceglie casualmente una password per ciascun account che attacca, avrà lo stesso tasso di successo. L'unica complicazione è originariamente se la botnet voleva impedire il lavoro ripetuto che doveva passare attraverso l'elenco degli account registrati in una sorta di ordine (o tenere traccia degli account già provati). Ora basta solo passare l'elenco delle coppie (login, password) in una sorta di ordine (o tenere traccia di quelle provate) per evitare tentativi sprecati.

Certo, ci sono cose che puoi fare per prevenire contro lo scenario 3 e amp; 4.

1. Non consentire agli utenti di utilizzare password comuni . Ottieni un ampio database di password perse e ogni volta che un utente configura o modifica una password, assicurati che non sia presente in questa lista comune. Avere regole di complessità della password aiuta anche (ad esempio, un capitale, un numero, un simbolo) che impedisce molte password comuni ( 123456 , password o letmein ) - le tue regole dovrebbero essere flessibili per consentire passphrase lunghe come < a href="http://xkcd.com/936/"> correct horse battery staple .

2. Tieni traccia degli indirizzi IP associati agli account . Se l'account johndoe non ha mai effettuato correttamente l'accesso da 1.2.3.4 prima, richiede CAPTCHA o autenticazione a 2 fattori (ricevi un codice tramite SMS / chiamata telefonica / email) prima che possano accedere da quell'IP.