Prevenzione del blocco degli account di massa utilizzando i token CSRF

1

Attualmente sto lavorando per ridurre il rischio di blocco degli account di massa in un sito che (sfortunatamente) genera ID utente numerici sequenziali. La modifica della struttura dell'ID utente è non un'opzione a questo punto.

Ho esaminato alcune opzioni (CAPTCHA, Limitazioni sui tentativi di accesso per IP). Uno pensa che sia l'uso di un token anti-CSRF nella pagina di accesso, che richiede a un utente malintenzionato di caricare la pagina di accesso (e ottenere il token) prima di qualsiasi tentativo di accesso. Questo probabilmente verrebbe combinato con un ritardo prima che il token fosse accettato (diversi secondi, il tempo impiegato da un utente normale per inserire i dettagli di accesso).

Questo non impedirebbe il blocco, ma rallenterebbe la velocità dei tentativi e aumenterebbe leggermente la complessità di esecuzione del blocco. Qualcuno ha visto questo usato prima? Funzionerebbe davvero?

    
posta bdg 19.06.2012 - 06:29
fonte

3 risposte

2

Personalmente non ho mai visto una cosa del genere implementata, ma perché non imposti un tempo che aumenta il login fallito?

Ad esempio, dopo tre accessi non riusciti, si blocca il login per questo account per, diciamo, 30 secondi. Dopo gli anni '30, se il quarto login non ha ancora successo, lo fermi per 1 minuto, poi 5 minuti, e aumenti sempre di più.

Questo non influenzerà i tuoi utenti reali (generalmente non fallisci 3 volte se ricordi la tua password, e se non lo fai, vai al processo "Lost my password"), e i robot non funzioneranno un attacco di forza bruta.

Ora, l'idea CSRF è interessante per forzare l'utente a ottenere il token, ma se costruisco un robot, posso ancora simulare una richiesta GET alla pagina di login, analizzare l'HTML e ottenere il token, per poi usarlo per un POST combinato con le credenziali. L'unica limitazione che suggerisci qui è l'attesa tra il token generato e il modulo inviato (e questo potrebbe danneggiare i tuoi utenti che sono scrittori veloci).

    
risposta data 19.06.2012 - 07:15
fonte
2

I ritardi sono una strategia ragionevole che limita la velocità del livello dell'applicazione per proteggere le interfacce sensibili ai bot in generale. Puoi utilizzare un token di autorizzazione come parte di tale strategia, ad esempio un token con firma HMAC che include un timestamp di emissione o un timestamp nella sessione se stai utilizzando le sessioni.

requiring an attacker to load the login page (and get the token) prior to any login attempt. This would probably be combined with a delay before the token would be accepted (several seconds, the time taken for a regular user to enter login details).

Tale ritardo dovrebbe aumentare con l'emissione di un numero sempre maggiore di token, per agire efficacemente come una coda che non consente più di un tentativo di accesso per X secondi per una particolare fonte (tipicamente un singolo IP o netblock). In caso contrario, un utente malintenzionato potrebbe richiedere un centinaio di token di autenticazione e inviarli tutti in una volta pochi secondi dopo.

Determinare cosa sia questa X e monitorare il comportamento buono e cattivo da fonti diverse per regolare quella X per indirizzi diversi (manualmente o nel codice), è potenzialmente un processo in corso significativo.

    
risposta data 19.06.2012 - 13:53
fonte
0

Ho visto qualcosa di simile che viene usato per prevenire lo spam dei commenti. Dai un'occhiata ai cookie per i commenti plugin per wordpress se hai bisogno di ispirazione. Un bel plugin utile. È semplice ma molto efficace. Sembra essenzialmente lo stesso principio della tua idea.

Il concetto di base sta fornendo un valore difficile da prevedere tramite un form / cookie e ci aspettiamo di vederlo di nuovo entro un vincolo temporale per impedire attacchi bot automatizzati.

    
risposta data 19.06.2012 - 09:05
fonte

Leggi altre domande sui tag