Registrazione senza verifica quando l'utente è stato invitato?

Question

Registrazione senza verifica quando l'utente è stato invitato?

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

4

La tipica procedura di registrazione è ovviamente:

Alice immette l'indirizzo email e la password desiderata (e possibilmente altri dati).
Viene inviata un'email di verifica all'indirizzo fornito da Alice.
Alice conferma il suo indirizzo email tramite un link (con un token univoco) nell'email.
Alice ora ha accesso al servizio.

Ma nel caso di servizi in cui gli utenti invitano altri inserendo i loro indirizzi email, ha senso semplificare la procedura di registrazione? Se il nuovo utente arriva al sito tramite un collegamento email, non è possibile saltare l'email di verifica?

Il flusso dovrebbe invece essere:

Alice (un utente esistente) invita Bob al servizio inserendo il suo indirizzo email nella funzione di invito del servizio.
Bob riceve l'email, che ha un collegamento (sempre con un token) alla pagina di registrazione.
La pagina di registrazione è precompilata con l'indirizzo email di Bob, quindi tutto ciò che deve fare è scegliere una password (il token viene propagato, quindi Bob non può creare una richiesta per sovrascrivere l'indirizzo email precompilato).
Bob ha accesso immediatamente.

Non mi sorprenderebbe se alcuni servizi lo facessero già, io non ne ho visto nessuno (almeno nessuno che io ricordi).

Per quanto posso dire, il secondo flusso fornisce la stessa quantità di verifica / conferma del primo; in entrambi i casi, l'utente segue un collegamento con un token univoco che è legato al loro indirizzo. O, in ogni caso, un account di posta elettronica a cui hanno accesso.

Ma è lo stesso? Il flusso alterato fornisce un punto d'appoggio per gli attaccanti?

authentication email web-application

posta Flambino 05.07.2016 - 14:08

fonte

2 risposte

Leggi altre domande sui tag authentication email web-application

SSL / TLS CipherSuite TLS_NULL_WITH_NULL_NULL SAML 2.0 definisce come passare nome utente e password per l'autenticazione?

score 3 · Answer 1

Potrei immaginare il seguente scenario:

Bob legge l'email e pensa "Non per me, ma questo sito sarebbe perfetto per il mio buon amico Mallory". Bob inoltra l'email a lui.
Mallory ora ha la possibilità di registrarsi con l'e-mail di Bob.
Mallory utilizza la capacità di impersonare Bob ad es. organizzare attacchi di social engineering o solo per imbrattare la reputazione di Bob.

A seconda di come si formula l'e-mail, il rischio che ciò accada potrebbe essere piuttosto ridotto. Ma non importa quanto tu sia chiaro, il punto n. 3 è destinato a risentire alcune volte, perché anche se sei chiaro, le persone non leggono veramente ciò che scrivi nelle email.

Va anche notato che Bob avrebbe la possibilità di fermare Mallory effettuando una reimpostazione della password (la password verrà inviata alla e-mail di Bobs). Ma a quel punto Mallory potrebbe già aver causato qualche danno.

score 2 · Answer 2

In generale non è necessario richiedere all'utente di reinserire il proprio indirizzo email se il collegamento viene ricevuto tramite lo stesso indirizzo email. È importante però utilizzare SSL, scadere il collegamento non appena viene creata una password e considerare di scadere il collegamento se non è stata creata alcuna password dopo un certo periodo di tempo.

Detto questo, è leggermente più sicuro per richiedere comunque all'utente di reinserire il proprio indirizzo email. È possibile che un utente malintenzionato possa accedere al collegamento senza l'e-mail, ad esempio in una cache del browser di un utente che ha fatto clic sul collegamento da un computer pubblico e quindi non ha terminato l'impostazione di una password. Tuttavia, considererei questo scenario piuttosto ingegnoso, rispetto alla comodità di pre-compilare l'e-mail.