Quanto è sicuro per un'app fidarsi di un clic su un link in un'email?

Crea un numero casuale crittografico e aggiungilo come parametro nell'url (token). Quindi mostra solo la pagina reale se è un token valido. I token dovrebbero essere archiviati nel database, ovviamente.

How safe is it to provide a link within that app generated email to allow his friends to directly respond to the question without having to register on the site?

È molto sicuro se il tuo numero casuale crittografico è molto lungo. Sessione / Autenticazione usa anche semplicemente un numero casuale crittografico. Se consideri sicuro il tuo cookie di sessione / autenticazione, puoi anche considerarlo sicuro.

Indovinare un numero casuale crittografico molto lungo richiederà molto tempo. Per maggiore sicurezza, puoi prendere in considerazione

• token una tantum
Token
• che scade nel tempo

What precautions do I need to include to avoid or detect malicious clicks on that link?

Nessuno. Non è possibile distinguere tra un utente malintenzionato e l'utente reale. Ma questo è vero per tutto sul web ... Un utente malintenzionato può provare a indovinare la password di un utente nello stesso modo in cui può provare a indovinare il tuo token. Ma entrambi probabilmente richiederanno molto tempo, quindi non è pratico.

Creerei i token (alcuni hash casuali o GUID ) per ciascun utente previsto e lo passeremo nel stringa di query per identificare i singoli utenti. Un po 'come una password temporanea . Mettendo questo sulla stringa di query è conveniente per l'utente. Rendere il GUID, o il token temporaneo o per un uso singolo ridurrà la condivisione. La tua unica preoccupazione dopo questo è se i tuoi utenti hanno bisogno di modificare o modificare la loro risposta alla tua domanda dopo il fatto. Vorrei inviare l'ID della domanda insieme al GUID. Ad esempio:

http://example.com/thread/27?AHG324y6CVSA452aw34aF

Dove http://example.com è il tuo dominio, thread è il tuo controller / azione (MVC) e 27 identifica il thread o la domanda che viene posta. Puoi quindi utilizzare il loro token AHG324y6CVSA452aw34aF per identificare chi ha inviato la risposta. (A meno che tu non abbia intenzione di mantenere l'anonimato, spetta a te, ma gli utenti non si fideranno di te, o piuttosto, non mi fiderei di te, con questo approccio).

Sembra un progetto divertente.

Modifica

Nota importante: i GUID sono unici, non casuali in modo che non dovrebbe essere usato in questo scenario.

Includere un identificativo univoco o un token in ogni singola e-mail è la migliore scommessa. Questo token dovrebbe essere casuale, difficile da indovinare e da un set abbastanza grande che i valori inseriti casualmente non genereranno mai un token valido.

Questi token dovrebbero quindi essere limitati nella portata e nella scala di ciò che possono fare. Se limiti gli utenti a una singola risposta e commenti su quella risposta, la condivisione del link sarà in gran parte attenuata dal momento che solo una voce principale può essere fatta da quella e-mail senza registrarsi.