Autenticazione per "partecipanti" vs "utenti"

Question

Autenticazione per "partecipanti" vs "utenti"

#1 da (2 voti)
#2 da (2 voti)
#3 da (0 voti)

2

Sto costruendo un sito che consente agli utenti di programmare interviste / conferenze con terze parti e mi chiedo quale sia il modo migliore per fornire sicurezza intorno all'esperienza dei partecipanti fornendo al contempo la più piccola barriera di usabilità possibile.

Attualmente, invio un'email con un link e un codice di autorizzazione di 5 cifre. Il collegamento apre una pagina, il partecipante digita il codice di autorizzazione ed è temporaneamente connesso per la durata dell'intervista / conferenza.

Da un punto di vista della sicurezza, penso che il codice di autorizzazione sia ridondante e introduce attriti per il partecipante, che potrebbe non avere mai motivo di visitare nuovamente il mio sito e potrebbe non essere tecnicamente esperto. Il link che invio come parte dell'invito contiene una stringa casuale, quindi potrei semplicemente aumentare la sua lunghezza di 5 caratteri e avere lo stesso spazio di ricerca per i potenziali attaccanti.

Il rovescio della medaglia è che dovrei potenzialmente limitare le risposte per gli URL di invito, quindi non sono sicuro che ci sia alcun beneficio da una prospettiva di complessità / linee di codice.

Il codice non-auth sembra meno sicuro, ma so che è irrazionale. Qualche idea su quale sarebbe l'approccio migliore?

security authentication usability

posta edoloughlin 31.01.2012 - 12:25

fonte

3 risposte

Leggi altre domande sui tag security authentication usability

Come si verifica un carico di dati? Taglio della dimensione dello script utilizzando la notazione della matrice per le proprietà ad accesso frequente

score 2 · Answer 1

avere un codice a 5 cifre che devono digitare non è niente, è quasi troppo corto. È molto meglio della mia esperienza media con riunioni online che generalmente richiedono la digitazione di un ID di riunione + potenzialmente una password.

Se sei preoccupato per la sicurezza tecnica di un utente, la password è l'ultimo dei tuoi problemi, se possono usare la loro webcam / microfono per condurre l'intervista possono gestire una password.

Nulla rovinerà il tuo sito più rapidamente di quanto accade alle persone che partecipano a interviste / conferenze a cui non appartengono, quindi sbagliare dal lato della sicurezza è una buona cosa.

score 2 · Answer 2

Che ne dici di crittografare il codice di autenticazione nella sequenza querystring del link, quindi tutto quello che devono fare è fare clic sul link per partecipare?

In passato ho crittografato una sorta di campo identificativo nella stringa di query e la pagina che il link impiega per decrittografare l'id e lo controlla per cose come se fosse per una sessione valida, e se la sessione è attualmente attivo. Se passa, li porterà alla loro sessione. In caso contrario, visualizza un qualche tipo di pagina indicando che il link utilizzato non è valido o è scaduto.

score 0 · Answer 3

Quasi tutto ciò che un umano può fare, una macchina può anche fare. Ciò include l'inserimento di un po 'di testo in un modulo su una pagina web. Ad esempio, curl(1) può essere indirizzato a inviare% richieste diPOST, inclusi i campi modulo:

curl -F 'code=foo' 'http://example.com?session=bar'

E quindi aggiungere alcuni passaggi affinché un essere umano si esibisca raramente migliora la sicurezza.

Un altro problema è quello che stai cercando di prevenire. Ti interessa davvero se è uno script che emette dieci richieste al secondo o un paio di umani annoiati (che digiunano velocemente) facendo lo stesso? Quello che vuoi veramente è limitare abuse .

Puoi fare molto di ciò usando un filtro di rete che limita la frequenza per tutti (o per determinati URL) che di solito possono essere configurati nella maggior parte dei server http. È anche possibile concordare che ciascun link fornito sia utilizzabile una sola volta (o una volta al giorno).