È utile avere un captcha su una schermata di login?

Il modo in cui ho visto alcuni grandi sistemi farlo è richiedere solo un captcha dopo tentativi di accesso sequenziali falliti (es .: resettare il conteggio dopo un login valido). Se sei preoccupato per il cracking automatico, potresti inserire il captcha in un numero elevato di errori come 20, 50, 100 tentativi falliti. Quasi nessun utente legittimo vedrà il captcha, ma un attacco automatico verrà colpito da esso.

Vale la pena aggiungere questa complessità? Sicurezza e UX sono trade-off. Devi trovare il giusto compromesso per il tuo profilo di rischio.

The users now hate it, Some did not even understand it and I had to remove it.

Questo è il punto in cui dovrai decidere tra usabilità e sicurezza. Anche se è utile avere un captcha sulle pagine di accesso, è incredibilmente scostante.

Il mio miglior suggerimento sarebbe di registrare ogni tentativo di accesso non valido a un database, e prima di autenticare l'utente, controlla se quell'IP ha provato ad accedere X volte nell'ultima ora.

Potresti anche aggiungere una qualche forma di sistema di richiesta di cross site request per ogni pagina di accesso. Ciò significa che ad ogni tentativo di accesso verrà generato un campo nascosto con un token, il che significa che un utente malintenzionato dovrebbe effettuare due richieste per provare ad accedere.

Un captcha su una schermata di accesso non ha senso. Non sono sorpreso che i tuoi utenti lo abbiano odiato. Lo scopo dei campi captcha nei form è di impedire che vengano inviati dai bot. Un bot non dovrebbe essere in grado di accedere attraverso la schermata di accesso, in quanto non dovrebbe avere credenziali valide. Se un bot può indovinare credenziali valide, è necessario aumentare la sicurezza della password.

Un altro modo per attaccare questo potrebbe essere l'installazione di un "honeypot". Questo è un campo di input ordinario che è incluso nell'HTML insieme ai campi di login (username, password), ma questo campo extra è nascosto usando CSS.

Tipicamente, i bot proveranno ad inserire del testo in tutti i campi mostrati nell'HTML, quindi in PHP ho controllato che se il campo honeypot non fosse vuoto - vieterei quell'IP.

(Questo era per una homepage per un club di paracadutismo con una piccola funzione di amministrazione per aggiornare le date in cui stiamo per saltare ecc. Non lo consiglierei per le applicazioni sensibili)

I sistemi CAPTCHA sono lì per distinguere tra bot automatizzati e utenti reali. Purtroppo, come hai notato, non sono molto convenienti (in particolare per gli utenti disabili).

Che sia "una buona idea" o meno dipende dal tuo caso d'uso, in realtà, anche se non sono molto efficienti con gli accessi degli utenti: non sono molto utili per prevenire attacchi di indovinare la password e implementare un limitatore di velocità nell'applicazione più conveniente per l'utente mentre implementa un TOTP PIN offre una maggiore sicurezza.

Avere qualche forma di "prova di lavoro" dal tuo cliente potrebbe essere ancora un'ottima idea se hai intenzione di spendere le risorse del server per loro e se queste risorse sono limitate. Un tipico caso d'uso per tale query è un sistema che eseguirà il lavoro per gli utenti anonimi (ad esempio, un'applicazione WHOIS basata sul Web potrebbe utilizzarla per preservare le risorse).

Aggiungere un Captcha o ReCaptcha non è una soluzione, è solo un ostacolo per hacker e utenti.

Ho una visione molto buona con gli occhiali e talvolta riesco a malapena a distinguere il testo dell'immagine. Immagino che qualcuno che rinnega la loro visione si infurierà.

Tutto ciò che implementa ha bisogno di uno scopo specifico, altrimenti finisci col lanciare torte nel cielo con il ripieno di cacca e queste torte finiscono per atterrare direttamente sui tuoi utenti.

Ecco alcuni spunti di riflessione:

1

Problema

User accounts are getting hacked due to automated brute force attempts

Soluzione

Accounts are now locked after 3 failed logins

2

Problema

All user accounts have been revealed and a bot is now trying to brute force all accounts

All accounts get locked within a matter of seconds due to 3 failed logins

Soluzioni? Abbondante, ma abbiamo anche bisogno di arrivare a questo passo? Questo è attualmente un problema?

Pensa per un momento a cosa sta cercando di ottenere il tuo captcha. Ecco l'obiettivo a cui posso pensare:

• Impedisci a un attacco automatico su vasta scala di penetrare in account deboli

Ecco un modo per farlo che probabilmente renderà più felici i tuoi utenti:

• Se un computer accede correttamente (come Bob), imposta un cookie su quel computer in modo che il server sappia che il computer ottiene 5 tentativi gratuiti di accedere all'account di Bob senza bisogno del capcha.

• Se il computer che tenta di accedere proviene dall'ultimo IP conosciuto di Bob, dai quell'ip 5 tentativi gratuiti di accedere all'account di Bob senza bisogno del capcha.

L'idea qui è che l'individuazione di password di massa di solito accade da computer o IP che non sono legittimamente registrati nell'account.

Probabilmente questo può essere migliorato combinandolo con idee di altre risposte in cui dai "tentativi gratuiti" a account o ips.

Aggiungere un captcha dopo 10 o 100 tentativi falliti è inutile, come la maggior parte dei bot attuali hanno un account deathbycaptcha, e l'API per dbc è davvero facile da usare. Quindi, mostrare un captcha ogni seconda volta è una buona cosa, penso.

Per prevenire attacchi di forza bruta, sarebbe meglio fare quanto segue.

1) Assicurati che le password siano abbastanza complesse. Se viene data la possibilità a molti utenti di utilizzare password estremamente semplici, come il loro nome, ecc. Le password devono contenere almeno 8 caratteri e includere numeri, lettere e maiuscole.

2) IP di blocco dopo 5 tentativi di accesso falliti.

Potrebbe essere utile aggiungere un campo captcha alla schermata di recupero della password. Assicurati di includere abbastanza testo per spiegare agli utenti come funziona.