La presenza del token XSRF e del cookie di sessione per richiesta riduce il rischio di sicurezza delle credenziali di accesso brute-forcing? [duplicare]

Disabilitazione dei tentativi di accesso che non hanno un cookie / token valido (che indica che il client ha caricato la pagina prima di inviare la richiesta) e che il cookie / token è monouso (quindi non è possibile caricare la pagina una sola volta e quindi inviare un gruppo di richieste con quelle credenziali) è, in teoria, un modo valido per rallentare i tentativi di brute-force di accesso. Uno strumento può ancora automatizzare il processo, ma deve fare una richiesta e ricevere la risposta per ogni tentativo, piuttosto che lanciare richieste il più velocemente possibile, di solito portando ad avere più richieste in volo contemporaneamente.

Tuttavia ci sono problemi con questo approccio. Per prima cosa, è difficile da scalare. Non è facile bilanciare il carico dei tentativi di accesso, operazione importante se si dispone di molto traffico e di una funzione di hashing della password opportunamente costosa, in quanto l'utilizzo singolo del token si interrompe se più "validi" le richieste vengono bilanciate su più server e l'elenco di token validi dei server non viene mantenuto perfettamente sincronizzato. Per un altro, in realtà non impedirà la forza bruta automatizzata - nel peggiore dei casi, lo strumento ha semplicemente bisogno di racimolare le risposte per i valori che include nella sua prossima richiesta - come farà un CAPTCHA. Diventa anche più difficile creare uno strumento che autentica (con credenziali valide) automaticamente, che a volte è prezioso da abilitare.