La mia prevenzione della bruteforce ha importanti aspetti negativi - qualche idea?

Naviga le tue risposte
2

Attualmente sto cercando il modo migliore per impedire il portale web del mio software dagli attacchi bruteforce e mi è venuta in mente la seguente idea:

  • 3 tentativi di accesso senza alcuna sfida visiva
  • dopo 3 tentativi falliti mostra Google reCaptcha
  • consentire altri 3 tentativi, ma ora devi fare clic sul captcha ogni volta
  • se gli ultimi 3 tentativi non sono riusciti, blocca nuovamente l'account

La mia idea ha solo importanti aspetti negativi e spero che tu possa dare qualche consiglio:

  • cosa succede se il nome utente cambia ad ogni tentativo di accesso? quale account posso bloccare dopo 6 tentativi?
  • come devo registrare i 3 tentativi falliti (non dipendenti se questi sono 3 tentativi di un account o un tentativo per 3 account diversi) prima di mostrare il captcha?
    • IP? Ma cosa succede se un sacco di persone provenienti da una rete aziendale utilizzano il software in una volta?
    • Agente utente del browser? Cosa succede se qualcuno che tenta l'attacco bruteforce cambia semplicemente l'agente utente ad ogni tentativo di accesso?
    • Cookie?
posta 12dollar 12.10.2015 - 10:47
fonte

2 risposte

2

Rilevare la forza bruta dal solo comportamento del client dell'utente è notoriamente difficile. A causa di attacchi distribuiti, attacchi contro più nomi utente e così via, gli schemi di traffico sono difficili da rilevare.

La mia raccomandazione, e la soluzione che uso su quasi tutti i miei sistemi, è di inserire un semplice ritardo nel processo al punto di errore, quindi se un utente si autentica correttamente funziona semplicemente normalmente ma per ogni errore inserire un ritardo di 2 o 3 secondi prima di dichiarare l'errore.

Sia per gli utenti umani che per i client scriptati (come l'accesso legittimo alle API, ecc.) questo non causa alcun problema, ma per gli attacchi a forza bruta questo rallenta il processo fino a una velocità lenta, anche per ogni probabile numero di thread di forza bruta paralleli (purché le password siano complesse, ovviamente.)

Inoltre, la maggior parte dei linguaggi sul lato server rilascia la CPU per i comandi di "sospensione" e questo evita questa particolare soluzione causando un DOS basato sul tempo della CPU (anche se i socket pool di connessione potrebbero essere ancora un problema).

    
risposta data 12.10.2015 - 10:54
fonte
1

Penso che il tuo approccio sia abbastanza buono.

Alcune note sulla soluzione proposta: un "tentativo di accesso fallito" può essere considerato come tale quando ad es. è lo stesso nome utente che è stato testato. Per proteggersi dagli attacchi bruteforce, si contano il numero di tentativi di accesso non riusciti in un intervallo di tempo, ad es. nel tuo caso, 15 minuti per 3 tentativi di accesso sarebbero un buon valore. Questo innescherebbe il secondo livello, cioè mostra il captcha.

Anche introdurre ritardi dopo ogni tentativo di accesso (come proposto da @DavidScholefield) è una soluzione eccellente, e puoi usarla insieme al tuo metodo. Puoi utilizzare:

  • un ritardo fisso di 2-3 secondi prima di mostrare all'utente il messaggio relativo a qualsiasi tentativo di accesso fallito, anche se è il suo primo
  • oppure puoi usare un ritardo crescente, che può essere
    • o lineare (ad esempio 3 secondi, 6 secondi, 9 secondi, 12 secondi, ...)
    • o esponenziale (ad esempio 2 secondi, 4 secondi, 8 secondi, 16 secondi, ...)

Il bello del ritardo fisso è che non devi registrare nulla.
Nel caso di un ritardo crescente, devi accedere al nome utente che ha fallito il login (per evitare bruteforcing su un utente) e anche l'indirizzo IP che ha fallito il login (per evitare che un indirizzo IP bruisca su tutti gli utenti del tuo sistema, uno prova alla volta).

Gli IP sovrapposti della stessa azienda non rappresentano un problema poiché gli utenti devono utilizzare il proprio account. (Se non lo fanno, e condividono le credenziali dell'account, questo è il loro problema.)

    
risposta data 12.10.2015 - 10:56
fonte

Leggi altre domande sui tag

È possibile contrastare BREAK semplicemente aggiungendo una sorta di "sale" nella pagina che viene compressa? Cosa * effettivamente * è una vulnerabilità di applet Java?