Silenziosamente limitanti tentativi di accesso

C'è un numero crescente di quelli che sto definendo "attacchi a forza bruta". Laddove una rete bot con un elenco di bersagli effettua un numero basso di tentativi a intervalli regolari per ciascun obiettivo, allo scopo di non farsi prendere dai soliti metodi di monitoraggio degli attacchi veloci.

Gestisco un numero di siti Web e in genere vedo tentativi di accesso non riusciti che vanno da 3 a 10 tentativi su più siti non collegati con gli stessi identici nomi utente e combinazioni di password. Tipicamente è un elenco alfabetico, ma non sempre. I tentativi di solito si verificano una volta al giorno per un numero qualsiasi di giorni.

La sofisticazione di questi tentativi di hacking è molto bassa, ma è probabile che siano in grado di aggirare un breve blocco mentre descrivi. Qualsiasi utente con una password debole può / alla fine verrà compromesso e l'attacco è progettato per rimanere al di sotto del radar.

Il tuo metodo potrebbe essere molto utile per un tipo specifico / velocità di attacco rapido, ma dovrebbe essere solo uno dei tanti strumenti se scegli di usarlo del tutto.

Una forza bruta può implementare pause per abbinare il breve intervallo di blocco che stai presentando, quindi questo rallenterebbe uno script a forza bruta. Tuttavia, bloccare definitivamente l'account (o forzare la domanda di sicurezza CAPTCHA oltre ai tentativi di accesso futuri) dopo il numero x di tentativi falliti consecutivi è un modo migliore per raggiungere tale obiettivo. Il tuo approccio ha un piccolo merito, ma vorresti sicuramente accoppiarlo con i metodi tradizionali anti-bruta.

Mi piace l'approccio silenzioso. Come tester di penetrazione che frequentemente esegue test per la conformità PCI, eseguo regolarmente i problemi di blocco dell'account. PCI-DSS richiede che gli account vengano bloccati per un minimo di 30 minuti (o fino a quando non vengono sbloccati da un amministratore) dopo sei tentativi di accesso falliti. Il mio problema con un messaggio che dichiara che l'account è stato bloccato rende molto semplice causare un Denial of Service su un utente. Questo può anche essere usato per enumerare account utente validi (anche se si è forzanti brute, si presume che sia già noto un account valido).

Se aumenti il ritardo fino a quando viene raggiunta una "soglia massima", quindi blocchi l'account per un periodo di tempo prolungato, l'approccio mi sembra perfettamente valido. Inoltre, dovresti anche resettare l'orologio ogni volta che viene effettuato un altro tentativo di autenticazione.

L'implementazione di questo sarebbe difficile da ottenere. Dovresti considerare vari modi in cui un utente malintenzionato potrebbe rendersi conto che qualcosa è successo. Il mio primo pensiero immediato è che un utente malintenzionato potrebbe notare che un accesso limitato con una frequenza limitata ritorna più velocemente di un normale login fallito. O forse il messaggio restituito è leggermente diverso, inavvertitamente.

In ogni caso, questa non dovrebbe essere l'unica linea di difesa. Un blocco totale è un inconveniente per un utente, ma lo sono anche gli account compromessi. Come minimo, il sito dovrebbe continuare a non riuscire tutti i tentativi di accesso con lo stesso algoritmo, ma forzare un blocco totale fino a quando l'utente non reimposta la propria password. Dovrebbero anche essere avvisati tramite e-mail o SMS, solo una volta, che si sono verificati più tentativi falliti; sapranno se l'hanno fatto o no.

Nel complesso, ritengo che l'implementazione non valga il tempo rispetto al blocco dell'utente o alla richiesta di un captcha o di una password secondaria, come una domanda di sicurezza, dopo alcuni tentativi.

La maggior parte dei meccanismi di blocco basati sul ritardo specificano un ritardo progressivo. Se il ritardo non aumenta nel tempo, potrebbe non essere sufficiente fermare un programma di forzatura bruto adattivo, che rallenta per soddisfare i piccoli ritardi. Il lato negativo nell'esempio originale è che potrebbe non rallentare abbastanza la forza bruta. Lo svantaggio di un algoritmo che aumenta il ritardo è che potrebbe bloccare utenti legittimi.

Non penso che tu voglia bloccare un utente in questo modo, vuoi bloccare l'endpoint. Ci sono due ragioni per cui dovresti fare questo: in primo luogo, se un utente sta tentando di accedere nello stesso momento in cui il suo account viene violato, non verrebbe modificato poiché non sta effettuando l'accesso dallo stesso endpoint, in secondo luogo l'autore dell'attacco potrebbe non puntare a uno solo account in modo da bloccarli quando si provano più account e account singoli.

Come altri hanno sottolineato, non vuoi alterare i tuoi tempi o trascurare le altre linee di difesa.

Penso che bloccare IP temporaneamente non offra una buona sicurezza. Perché l'attaccante cambierà il proprio IP per proxy e tenterà con IP diversi. Può essere superato con due metodi.

1. Aggiungi la verifica captcha nella pagina di accesso

2. Aggiungi il blocco IP temporaneamente.

In WordPress, possiamo aggiungere plugin per questo. link plugin che fornisce queste due categorie.