Quanto è importante CAPTCHA nelle pagine di registrazione?

7

Sto lavorando su un sito e vorrei aggiungere CAPTCHA alla pagina di registrazione dell'utente per impedire l'enumerazione dei nomi utente.

Sto lavorando con uno sviluppatore front-end che ritiene che non dovremmo aggiungere CAPTCHA alla pagina di registrazione perché è un problema per gli utenti e ridurrà il nostro tasso di conversione.

So che a volte esiste una relazione inversa tra la sicurezza di un sito e l'usabilità del sito e che alcune vulnerabilità di sicurezza sono peggiori di altre.

Se ci fosse qualcosa come una vulnerabilità di SQL Injection, vorrei insistere sul fatto che la risolviamo, ma non sono sicuro che una vulnerabilità di enumerazione degli utenti sia abbastanza seria da giustificarmi a combattere per questa particolare correzione.

Quanto è importante avere CAPTCHA su una pagina di registrazione e quanto seriamente dovrebbero essere presi gli attacchi di enumerazione degli utenti?

    
posta Abe Miessler 12.09.2013 - 17:53
fonte

3 risposte

6

La mia esperienza personale con ReCAPTCHA (ampiamente considerato uno dei migliori) è che ci sono voluti circa una settimana dopo che l'abbiamo aggiunto prima che gli spammer stessimo cercando di evitare di capire come risolverli.

Non risolvono correttamente il 100% delle immagini presentate ma non devono. Anche ottenere uno su dieci corretti va bene per loro e stanno facendo meglio di così. Probabilmente stanno meglio dei nostri clienti.

Ci sono alcuni stili alternativi di CAPTCHA che riguardano il gioco o la selezione di un gattino tra più immagini. Questi tipi di CAPTCHA non hanno ancora ricevuto alcuna attenzione da parte degli spammer dedicati.

L'enumerazione degli utenti potrebbe non essere un problema risolvibile, a seconda del design del tuo sito. Nel caso di un forum, un utente malintenzionato deve semplicemente visitare il forum e annotare i nomi utente che vede allegati ad ogni post.

Se qualcuno può registrarsi al sito, il processo di registrazione dovrà informare il potenziale utente che il nome che hanno scelto è già stato preso. Un CAPTCHA probabilmente cambierà l'equazione per un attaccante qui perché il costo di risolverlo e il tasso di fallimento rispetto al valore potenziale delle credenziali enumerate probabilmente significherebbe che non ne vale la pena.

Poiché i nomi utente sono generalmente la parte non segreta della coppia di credenziali, anche la loro individuazione di solito non ha molto valore per un utente malintenzionato.

    
risposta data 12.09.2013 - 17:59
fonte
1

Riguardo a enumerazione utente , puoi mitigare questo particolare minaccia senza verifica umana di:

  1. Scollega il nome utente di accesso da qualsiasi altro dettaglio utente (indirizzo email, identificatore pseudonimo, qualsiasi attributo pubblico "di me"). Le banche fanno ciò dando al cliente un numero di accesso completamente distaccato da qualsiasi altro numero o dettaglio del proprio account. Ad esempio:

    • Fornisci nomi utente di accesso casuali che l'utente non può modificare. Il punto chiave è che il sistema fornisce il nome utente o l'utente può scegliere solo nomi utente casuali lunghi; altrimenti la creazione di account è un'opportunità per indovinare i nomi esistenti.
    • Avvisa gli utenti quando includono il loro nome utente di accesso nei post (supponendo che i nomi utente non siano stati salati e con hash).
  2. Sdraiati su qualsiasi query o modulo pubblico che può dedurre informazioni sugli utenti nel sistema:

    • Pronuncia sempre l'accesso negato. Non dire mai perché.
    • Pronuncia sempre "reimpostazione della password inviata all'indirizzo indicato". Non dire mai che ciò è impossibile perché l'utente non esiste.
    • Non disporre mai di una funzione Visualizza profilo utente che utilizza il proprio nome di accesso come ID query. Usa una chiave surrogata come il loro presunto manico pseudonimo del forum.

Ogni campo utilizzato nell'autenticazione presenta le stesse limitazioni della stessa password.

Un approccio non ortodosso alternativo potrebbe essere quello di non avere nomi utente di accesso .

Gli account vengono creati e accessibili utilizzando solo una password. Quindi le persone sono incoraggiate ad avere la password più lunga e casuale possibile se non vogliono che qualcun altro entri nel loro account. Il nome di un utente nel sistema viene utilizzato per l'interazione con i membri, non per l'autenticazione.

Non è meno sicuro di qualcuno che impone un nome utente e una password, dal momento che la maggior parte dei nomi utente aggiunge solo qualche bit in più di entropia; che sarebbe più intuitivamente riconosciuto dai membri se avessero solo una password. Le persone che registrano una coppia nome utente / password su una nota appiccicosa sul monitor stanno rivelando la verità essenziale che queste coppie di attributi di dati sono semplicemente un'unità di autenticazione atomica tagliata arbitrariamente in due o più pezzi. Un modulo di accesso con 5 caselle di immissione etichettate "Numero A; Numero B; Numero C; Numero D; Il numero E" non sarebbe più o meno sicuro di 2 caselle di immissione denominate "Nome utente; e password ".

Questo rende anche il semplice punto in cui il recupero della password in questo giorno ed età può e forse dovrebbe essere responsabilità dell'utente, non del sito web. L'utilizzo di un indirizzo e-mail come gestore di password post-hoc di fatto riduce tutta la sicurezza del sito a qualsiasi entropia si trovi nella "risposta segreta / risposta" per il ripristino o il ripristino della password dell'account e-mail. Inoltre rende gli account e-mail molto più allettanti per gli hacker di quanto non sarebbero altrimenti - gli indirizzi e-mail non sono mai stati progettati per essere segreti, soprattutto sul filo.

    
risposta data 13.09.2013 - 00:25
fonte
-2

I captcha vengono utilizzati per impedire qualsiasi script o bot per la richiesta del server, assicurano che la richiesta provenga solo da persone.

Se non si desidera captcha nei moduli, è possibile utilizzare il meccanismo di token e fornire token al caricamento del modulo in campi nascosti il cui valore viene inviato insieme ai dati del modulo ed è possibile elaborare il token per l'autenticità prima di elaborare i dati del modulo. / p>     

risposta data 13.09.2013 - 00:30
fonte

Leggi altre domande sui tag