La procedura che descrivi sembra essere la combinazione di due procedure distinte che si applicano a contesti distinti.
1. Registrazione per un individuo mirato
Ci sono alcuni contesti in cui la registrazione è per un individuo specifico, con un'identità fisica definita, e si verifica in un processo che non consente l'impostazione di una password scelta dall'utente. Un esempio è quando "registri" qualcuno che hai incontrato ad una fiera e che ti ha dato il suo biglietto da visita. Conoscete il suo indirizzo e-mail, ma al momento della registrazione l'utente non è presente. In una situazione del genere, devi mandargli un modo per accedere inizialmente al tuo sistema (con almeno un certo livello di autenticazione - non vuoi creare un account per tutti, solo per quel ragazzo) in modo che possa completare la procedura scegliendo la sua password.
Una password iniziale, inviata via e-mail e che deve essere modificata al primo utilizzo (applicata dall'applicazione), è un modo per far fronte a tale contesto. L'invio di un "link di registrazione unico" che lo porta a una pagina in cui può scegliere la sua password è, da un punto di vista della sicurezza, esattamente la stessa cosa .
Questa è una situazione non ideale, in quanto le credenziali iniziali devono viaggiare senza protezione. Forzare il cambio della password al primo utilizzo è una misura di attenuazione: sì, un utente malintenzionato potrebbe intercettare il collegamento password / convalida iniziale, ma poi dovrebbe scegliere una password da sé, e almeno l'utente previsto noterà il problema (non ricevendo l'email o non potendo accedere).
2. Registrazione per "anybody"
La maggior parte delle app Web implementate che utilizzano la registrazione funzionano in un contesto diverso. Considera un venditore di alcuni prodotti basato sul Web (pensa Amazon). Qui, accetti anybody come nuovo utente. Devi "registrare" gli utenti perché vuoi che gli utenti siano in grado di tenere traccia dei loro comandi e non dovrebbero essere in grado di vedere i comandi di altre persone.
In tale contesto, l'utente è disponibile durante la registrazione iniziale: l'ha avviato, è proprio dietro la sua tastiera in quel momento, e può digitare la sua password scelta sotto la copertina di HTTPS. L'app Web può accettare questo tipo di registrazione perché non è schizzinosa: in base alla progettazione, chiunque è autorizzato a registrarsi.
Hai ancora bisogno di un "link di convalida" inviato via email, ma per uno scopo ben preciso: il link di convalida è usato per assicurarti che l' indirizzo email sia autentico. Un attaccante che intercetta tale comunicazione potrebbe ingannare l'utente (cioè registrarsi sotto un indirizzo e-mail che non "possiede" - anche se può intercettare le e-mail inviate a quell'indirizzo, quindi lo possiede davvero, in una certa misura), ma un tale aggressore non attaccare la stessa cosa rispetto al primo contesto. Nel primo contesto, l'autore dell'attacco impersona l'utente che ha il diritto di accedere; nel secondo contesto, l'autore dell'attacco ha il diritto di accedere in ogni caso, ma riesce a farlo mentre fornisce l'indirizzo email di qualcun altro.
Riepilogo
L'invio di una password iniziale una tantum tramite e-mail è una buona o una cattiva cosa, a seconda del tipo di registrazione che stai utilizzando. Per una classica creazione di account basata sul Web che chiunque può fare, questo è male. Per la registrazione di una persona specifica, l'applicazione di una modifica della password dalla password iniziale è buona, perché in quel caso l'hai già inviata via email, che è un rischio per la sicurezza (non hai avuto scelta, e devi mitigare i rischi).