È sicuro autenticare l'utente tramite il link di conferma via e-mail?

Dipende dal motivo per cui vuoi confermare una e-mail. Se tale e-mail verrà successivamente utilizzata per la reimpostazione della password, il flusso di lavoro proposto presenta un importante problema di sicurezza. Considera il seguente scenario:

• Alice crea un nuovo account e inavvertitamente scrive la posta di Bob (ad esempio copia e incolla la posta e utilizza la riga sbagliata)
• male Bob vede la posta, conferma l'account, scrive il nome di login di Alice se è diverso dall'e-mail e si disconnette
• Alice tenta di connettersi più tardi e vede che tutto funziona correttamente - presume che la convalida fosse automatica e che normalmente usa il suo account per un po '
• alcune volte dopo, Bob tenta di connettersi utilizzando l'account di Alice, chiede una reimpostazione della password = > come proprietario della posta raccomandata, ha successo nel cambiare la password
• Bob ora possiede l'account di Alice e può fare qualsiasi cosa per lei!

Ok, Alice non era molto cauta quando creava il suo account, ma il flusso di lavoro proposto non la proteggeva davvero: - (

Questa è la ragione per cui il mio flusso di lavoro preferito è:

• consente a un utente di creare un nuovo account con login, password e-mail (potrebbe essere il login o no, meglio non) - > l'account viene creato non attivato e verrà distrutto se non viene attivato entro un periodo di tempo limitato (ad esempio 2 giorni)
• invia un link di confimazione unico alla mail fornita
• il collegamento apre un modulo login - il nome utente deve essere precompilato e di sola lettura. Se l'utente accede correttamente, l'account viene convalidato, il link viene invalidato e l'utente inserisce la sua sessione. Se la password non è corretta dopo tre tentativi, la connessione è interrotta.
• se un utente prova a connettersi utilizzando un account non convalidato, vede un messaggio che dice che è stata inviata una mail di convalida a quell'indirizzo, che ha ancora n giorni / ore per convalidare l'account e che lo propone / lei per ricreare l'account con un nuovo indirizzo di posta. In tal caso, il vecchio link di convalida viene immediatamente invalidato.

Se accade lo scenario precedente, Bob non sarà in grado di convalidare l'account di Alice né di rubare il suo account in seguito.

Dipende se il modulo di registrazione contiene dati sensibili e se l'account appena creato può essere di qualsiasi valore per una terza parte (da solo o impersonando l'utente legittimo).

Il problema è che se l'utente ha commesso un errore durante la digitazione del suo indirizzo email, il link di registrazione può essere inviato a una persona sconosciuta.

• Nel flusso di registrazione proposto, questo destinatario sconosciuto avrà accesso all'account appena creato.
• Nel flusso di registrazione corrente, questo link sarà quasi inutile per questo destinatario, l'unica azione che può fare è "convalidare" l'indirizzo email.

Il flusso di registrazione proposto può quindi apportare un miglioramento dell'usabilità all'utente finale, ma a scapito di una sicurezza potenzialmente leggermente più debole.

Con il tuo "Flusso di registrazione proposto" presumi che la persona che ha appena creato l'account sia la persona che fa clic sul link. Questa ipotesi è generalmente vera e ci sono persone là fuori che si prenderanno questo rischio. In seguito questo è un problema di quale equilibrio si sta cercando tra sicurezza e usabilità (argomento di discussione piuttosto interessante: D).

La cosa brutta a questo proposito è che se la tua ipotesi è sbagliata, qualcuno potrebbe semplicemente accedere e reimpostare la password con accesso completo da ora in poi nell'account, anche cambiare l'account di posta elettronica dell'utente.

Con il tuo "My Current Registration Flow" hai migliorato la sicurezza, rischiando di infastidire un po 'l'utente costringendolo a fare il login di nuovo, anche se è quello che ha fatto solo pochi minuti fa.

Il modo in cui lo farei è che durante la registrazione, accedo direttamente all'utente, limitando ciò che può fare, ma aprendo una sessione per lui. Se vuole la piena funzionalità di lui deve attivare il suo account. Dopo aver fatto clic sul link di un token una volta nella sua e-mail, viene reindirizzato al sito Web dove, se ha una sessione aperta, avrà effettuato l'accesso (con una sessione aperta significa che le probabilità di qualcuno di ottenere la sua e-mail dalla registrazione fino a ora sono inferiori) altrimenti dovrà accedere nuovamente (ovvero la sua sessione è scaduta nel frattempo, quindi ci sono maggiori probabilità che questo non sia più il mio utente).

Spero che questo ti abbia aiutato e spero di avere un senso in quello che ho cercato di esporre.

Il problema che stai affermando qui è più se minimizzi la sicurezza (un po ') per guadagnare più usabilità o trovi qualcosa nel mezzo.

Direi, dipende.

Tutti sanno che l'e-mail è insicura, ci sono cose che puoi fare per inviare email per renderlo sicuro, ma da tutto ciò che so pochissime persone lo usano e deve essere impostato sia sul mittente che sul conto del destinatario.

Come detto da @WhiteWinterWolf, stai dando accesso all'account a chiunque possieda quell'e-mail. Solo ieri ho sbagliato a digitare il mio indirizzo email e l'ho avuto per oltre 10 anni e devo averlo digitato oltre 10.000 volte in quel momento, ma ho comunque commesso un errore. Quindi, se può accadere in quella situazione, può accadere in molte più situazioni.

Infine, quanto è buono il tuo casuale? Potrebbe essere indovinato? Non so quale lingua stai usando, ma ci sono funzioni casuali che non sono casuali come pensi. Sei disposto a mettere tutta la tua fiducia in quella funzione casuale quando potresti aggiungere una protezione?

Inoltre, so che questo non è UX, ma non c'è molto da perdere in termini di esperienza utente per farli di nuovo accedere, ma per precauzione si potrebbe avere la pagina di autenticazione e-mail per verificare un cookie generato dalla registrazione pagina, ciò indicherebbe che la registrazione e l'autenticazione e-mail sono state eseguite sullo stesso browser e rimuovere il requisito per accedere con quel cookie presente.

Il flusso corrente può essere considerato non sicuro per i seguenti motivi.

1. Un avversario con accesso (anche limitato) all'email di qualcun altro può creare e utilizzare un account per conto di loro.
2. L'autenticazione qui dipende interamente dalla sicurezza della posta elettronica. Email, ecco il link più debole e con l'accesso ad esso un avversario può accedere.

Nel flusso proposto, i problemi di cui sopra sono mitigati mentre confermi che la persona che ha creato l'account e la persona che ha accesso all'e-mail sono gli stessi.

Ho visto alcune applicazioni che usano il flusso originale che hai menzionato. Lo considerano un rischio accettato limitando le e-mail accettate ad alcuni domini. Il flusso originale è user-friendly con un leggero trade off in sicurezza.

Most websites require user to input his password after activating account. Is it even nessesary?

molto.

Se qualcuno può leggere le tue e-mail, non può prendere il tuo account in questo modo, poiché dipende da un segreto precondiviso, la password .

Un'ottima pratica.

Simile a richiedere una password per eseguire azioni chiave (vedi la modalità sudo di GitHub), come cambiare la password. Se qualcuno può dirottare la tua sessione o semplicemente accedere al tuo computer, non può fare molto dal momento che ha ancora bisogno della password, che non è stata loro fornita.