Perché ricontrollare con CAPTCHA in caso di immissione di moduli non riusciti?

Se il sito ha un mezzo per sapere che è lo stesso utente nella stessa sessione, allora no. Quindi, ad esempio, dato un cookie o una sessione SSL, sembra OK assumere che sia ancora un utente umano (entro i limiti di captcha).

Se si tratta solo di un cookie che stabilisce la sessione (ad esempio, questo è su http senza SSL), assicurati di crearlo. E dovresti comunque usare SSL: -)

No. Ma poi, c'era un motivo per chiedere un CAPTCHA in primo luogo?

Facciamo un esempio casuale di una piattaforma che implementa CAPTCHA; diciamo, Stack Exchange. Quello che vogliono i siti Stack Exchange è una raccolta di domande e risposte di alta qualità su un particolare argomento. Non c'è nulla che richieda intrinsecamente human di fornire le domande e le risposte: devono solo essere buone. Questa qualità di bontà è determinata e filtrata per dopo il contenuto è stato pubblicato, dalla comunità di elettori e moderatori.

Non è inoltre garantito che una volta stabilito che l'hardware del livello 8 è umano, sono predestinati a fornire buoni contenuti. In effetti questo è il modo più semplice per aggirare i CAPTCHA dei siti Web: trovare alcuni poveri e dare loro non molti soldi per compilare CAPTCHA per te.

Quindi implementare un CAPTCHA rende più difficile per le persone (molto più difficile, in alcuni casi, poiché molti meccanismi CAPTCHA sono inaccessibili alle persone con difficoltà visive) di usare la piattaforma, mentre rende solo un po 'più difficile per le persone abusare del piattaforma. In cambio, non ottieni informazioni utili relative al tuo obiettivo.

Penso che i motivi principali siano:

• È il comportamento predefinito che funziona fuori dalla scatola. Se il programmatore deve ricordare che il captcha è stato risolto, dovrà scrivere un codice extra. E deve essere ricordato in un modo che non può essere manipolato dall'utente (ad esempio la sessione), quindi un < input type="hidden" > il campo con una bandiera non va bene.
• Dopo che la convalida delle informazioni personali è fallita una o due volte e gli utenti devono reinserire il captcha ogni volta, diventa davvero fastidioso. Quindi le persone hanno maggiori probabilità di fornire dati personali reali invece di dati falsi. (Questo elemento si applica solo alle società che richiedono informazioni personali non strettamente necessarie per offrire il servizio che l'utente sta cercando.)

Per quanto riguarda l'usabilità nella scelta dei nomi utente, suggerisco di controllarli immediatamente usando Ajax prima che il modulo venga inviato. In alternativa puoi usare gli indirizzi email che sono (soprattutto) unici.

Conoscere il nome utente può rendere più facile per un utente malintenzionato di crackare le password: un attaccante intelligente, che non è interessato a un particolare account, sceglierà una password e quindi le forze brute tramite i nomi utente. Quindi questo è qualcosa da tenere a mente, a meno che tu non abbia una directory utente pubblica comunque. Anche senza una directory utente, esiste una serie di nomi utente che sono probabilmente scelti dagli utenti. Pertanto, per evitare questo tipo di attacco, è necessario un limite di velocità per tentativi di accesso non riusciti.

Ciò dipenderà completamente da quale sia lo scopo del modulo, ovvero dal tipo di informazioni raccolte.

Un caso molto comune è un tentativo di accesso dopo un login fallito su un sito web. In questo caso il CAPTCHA ha un duplice scopo:

1. Sta rendendo più difficile automatizzare i tentativi di accesso con un bot, rendendo così più difficile automatizzare un attacco indovinatore di password, e
2. Sta rallentando i tentativi di accesso; fare un attacco di forza bruta online più difficile da montare. (Nota, questo non dovrebbe essere lasciato solo al CAPTCHA, il sistema di autenticazione di backend dovrebbe avere un limite di velocità e / o un massimo di tentativi falliti di login.)

È anche comune che il intero modulo debba essere ripresentato se solo un singolo campo era sbagliato. Non c'è davvero una buona ragione tecnologica per questo, viene dal non dare priorità all'usabilità. Utilizzo di SSL, sessioni e token di protezione CSRF la webapp può sapere con certezza che l'utente finale ha risolto CAPTCHA nel suo primo tentativo e quindi non richiede di nuovo CAPTCHA, ma è più difficile implementarlo correttamente.

La ragione per cambiare sempre la sfida è rendere più difficile gli attacchi bruteforce. Immagina che i CAPTCHA non cambino dopo il primo tentativo fallito. Quindi un hacker potrebbe prima provare manualmente a compilare il modulo, introdurre la giusta sfida e quindi avviare uno strumento bruteforce, che riempie la casella di input formando i captcha sempre con lo stesso valore rendendo il CAPTCHA inutile. È utile creare, ad esempio, la creazione di massa dell'utente in servizi come, ad esempio, Gmail.