Perché gli attacchi di cracking della password a forza bruta non vengono rilevati automaticamente e ostacolati?

Ragionevolmente spesso, lo fanno. Qualsiasi sistema ragionevole bloccherà se effettui troppi attacchi online (o tentativi errati legittimi) per accedere all'account.

Il problema si presenta con attacchi offline. Il server (o qualsiasi altra cosa tu stia autenticando) deve avere qualcosa a cui confrontare la password. Questo è in genere un valore crittografato che può essere decodificato con la password o un hash. Se questo valore viene compromesso, ad esempio quando un utente malintenzionato accede al database degli utenti, può tentare di eseguire l'hash o la decrittografia sul proprio computer e ignorare tutti i conteggi di quante volte sono state provate le cose. Possono anche provare a indovinare ordini di grandezza più veloci dal momento che stanno lavorando localmente e non devono aspettare una rete.

Con un attacco offline, è possibile provare migliaia se non milioni di attacchi al secondo e improvvisamente diventa banale attaccare password semplici in pochi minuti, se non in secondi. Non c'è modo di prevenire l'attacco poiché non abbiamo alcun controllo sul sistema utilizzato per controllare la password. Questo è il motivo per cui è importante modificare la password dopo aver scoperto un compromesso DB.

Per "attacchi online", lo fanno, in vari modi e con successo variabile. Di solito, è solo un fastidio per l'utente legittimo e non un grande deterrente per i criminali.
Per gli attacchi offline è impossibile. Se qualcuno ha il tuo database di password, non puoi impedirgli di fare qualcosa con esso (anche se puoi ritardarlo in qualche modo).

I telefoni cellulari funzionano esattamente nel modo che descrivi. Dopo aver inserito il codice PIN oltre la soglia (ad esempio 3 tentativi), è necessario che il PUK sblocchi il dispositivo. Se questo mi dovesse succedere, sarò molto incazzato, dal momento che ho buttato via il pezzo di carta in cui viene annotato quel numero di 10 cifre.

Il mio router AVM ti bloccherà per 5 secondi, raddoppiando la quantità di tempo con ogni accesso fallito. Pertanto, dopo 10 tentativi falliti hai 42 minuti di attesa prima di poter riprovare.

Un tale schema è, tuttavia, solo moderatamente intelligente. Mentre è improbabile che si verifichi un errore di digitazione 10 volte di seguito, è perfettamente possibile che non si ricordi quale delle 10 password (password utilizzate raramente in una varietà di luoghi o tra le password che si hanno cambiato nel tempo) è quella corretta. Inoltre, consente un attacco denial of service con relativamente poco lavoro.
Ovviamente, anche l'attaccante deve attendere tra un tentativo di accesso, ma aspetta solo 21 minuti dove dovrai aspettare 42 minuti (o 6 ore mentre aspetti 12). Inoltre, se qualcuno è solo malizioso, aspettare non fa male, puoi sempre impostare una sveglia a 6 ore e fare un altro accesso falso la sera. Per l'utente legittimo, sarà un giorno intero di attesa, se questo funziona (e, cosa più importante, aspettare fa male se effettivamente devi fare qualcosa).
Altri sistemi che ho visto con alcuni siti Web sono ancora meno intelligenti. In un caso, alcuni anni fa, sono stato costretto a cambiare la mia password per sbloccare il mio account perché qualcuno ha fatto un paio di falsi accessi. Il che è, ovviamente, una totale assurdità dal momento che la password era in modo dimostrabile non stata compromessa (poiché questi tentativi di accesso non avevano avuto successo). Quella misura di "sicurezza" era solo un grande fastidio per il cliente, senza alcun beneficio.

Nella difesa degli implementatori, non è affatto facile (se possibile) trovare qualcosa che funzioni molto meglio.

C'è un altro scenario che sarebbe difficile da rilevare.

Per prima cosa, guardiamo scenari facili da difendere;

Facile: difesa contro attacchi brute force su un singolo utente.

Anche gli attacchi di forza bruta sono facili da difendere, se un singolo utente è il bersaglio dell'attacco. Possiamo bloccare solo l'account dell'utente. Ciò potrebbe infastidire l'utente, ma ci consente di impedire che il sistema venga compromesso.

• accedi a UserJoe
• accedi a UserJoe
• accedi a UserJoe
• accedi a UserJoe
• accedi a UserJoe
• Blocca l'account UserJoe

Facile: difesa contro l'attacco brute force da un singolo indirizzo IP

Attacchi di forza bruta facili da individuare e difendere, se tutte le richieste provengono dallo stesso indirizzo IP.

Possiamo semplicemente impedire a quell'indirizzo IP di fare altre richieste.

• AlcuniIPAddress1 che tentano di accedere
• AlcuniIPAddress1 che tentano di accedere
• AlcuniIPAddress1 che tentano di accedere
• AlcuniIPAddress1 che tentano di accedere
• Impedisci a SomeIPAddress1 di tentare accessi futuri

Impossible (?): Difesa contro una botnet brute - costringendo un nuovo utente ad ogni tentativo.

Supponiamo che qualcuno che usa una botnet stia cercando di forzare il tuo sistema. Hanno indirizzi IP diversi, quindi non è possibile filtrare gli accessi per indirizzo IP.

Supponiamo che provino ad accedere a un utente diverso per ogni tentativo.

Quindi le richieste potrebbero apparire come questa:

• SomeIPAddress1 che sta tentando di accedere a UserJoe
• SomeIPAddress2 che tenta di accedere a UserAnne
• SomeIPAddress3 che tenta di accedere a UserMarc
• SomeIPAddress4 che tenta di accedere a UserHanah
• ...

Non riesco a pensare a un modo per differenziare gli accessi legittimi dagli accessi falsi.

Sarà sempre un modo per bilanciare quanto tempo impiegare qualcuno per attendere dopo un tentativo di accesso errato. Non è irragionevole continuare ad aumentare il tempo di attesa dopo ogni tentativo (e alla fine bloccare ulteriori tentativi fino a una sorta di reset), ma questo deve essere legato all'indirizzo IP in cui il tentativo sta arrivando, in modo che l'utente legittimo non lo faccia. anche essere bloccato (vittimizzato perché qualcuno sta cercando di violare il proprio account). Tuttavia, un attacco distribuito (da molti indirizzi IP) può caricare il sistema fino al punto di diventare un semplice attacco DDoS.

Se qualcuno è determinato a provare un sacco di password (non necessariamente tutte possibili , solo le più comuni / probabili) e ha una mandria di macchine zombi per farlo, o ' Alla fine ci riuscirà, o mettere il sistema in ginocchio. Non dimenticare che applicare un tempo di attesa (rifiutando le richieste di accesso) o negare un indirizzo IP utilizza anche risorse. E se hai così tante password da non ricordare quale usare, hai un problema con la tua metodologia se devi esaminarle tutte!

Una sfida "domanda di sicurezza" (in pratica, una password alternativa) dopo tanti tentativi falliti è possibile, così come inviare una password monouso (ripristinata) a un indirizzo email registrato (sia automaticamente che richiesta "password dimenticata") , così come lo è un blocco su questo indirizzo IP per un dato periodo di tempo o fino a quando viene chiesto all'amministratore di sbloccarlo. Ho visto tutti questi metodi usati.

Se l'utente malintenzionato ha informazioni interne, vale a dire il file delle password hash o crittografato, può eseguire la maggior parte del proprio lavoro offline e accedere una sola volta (dopo aver individuato la password da utilizzare). Le password devono sempre essere archiviate come hash (crittografia unidirezionale) e mai in testo normale o persino in forma crittografata reversibile. Gli hash sono difficili (ma non impossibili) per recuperare la password in testo semplice, specialmente se sono salati (in modo che l'hash non sia lo stesso per due utenti diversi che hanno scelto "segreto" per la loro password).