El procedimiento que describe parece ser la combinación de dos procedimientos distintos que se aplican a contextos diferentes.
1. Registro para una persona específica
Hay algunos contextos en los que el registro es para una persona específica, con una identidad física definida, y ocurre en un proceso que no permite la configuración de una contraseña elegida por el usuario. Un ejemplo es cuando "registra" a alguien que conoció en una feria comercial y que le dio su tarjeta de presentación. Usted conoce su dirección de correo electrónico, pero cuando se realiza el registro, el usuario no está allí. En tal situación, tiene que enviarle una manera de iniciar sesión inicialmente en su sistema (con al menos algún nivel de autenticación; no desea crear una cuenta para todos, solo para ese tipo) para que pueda completar El procedimiento mediante la elección de su propia contraseña.
Una contraseña inicial, enviada por correo electrónico, y que debe cambiarse en el primer uso (impuesta por la aplicación), es una forma de lidiar con ese contexto. Enviarle un "enlace de registro único" que lo lleva a una página donde puede elegir su contraseña, desde un punto de vista de seguridad, es exactamente lo mismo .
Esta es una situación no ideal, ya que las credenciales iniciales deben viajar sin protección. Forzar el cambio de contraseña en el primer uso es una medida de mitigación: sí, un atacante podría interceptar la contraseña inicial / enlace de validación, pero luego tendría que elegir una contraseña, y al menos el usuario previsto se dará cuenta. El problema (al no recibir el correo electrónico o no poder iniciar sesión).
2. Registro para "cualquiera"
La mayoría de las aplicaciones web implementadas que utilizan el registro funcionan en un contexto diferente. Considere un proveedor basado en la web de algunos productos (piense en Amazon). Aquí, aceptas a cualquiera como nuevo usuario. Debe "registrar" a los usuarios porque desea que los usuarios puedan realizar un seguimiento de sus comandos, y no deberían poder ver los comandos de otras personas.
En ese contexto, el usuario está disponible durante el registro inicial: lo inició, está justo detrás de su teclado en ese momento y puede escribir la contraseña elegida bajo la cubierta de HTTPS. La aplicación web puede aceptar este tipo de registro porque no es exigente: por diseño, cualquiera tiene derecho a registrarse.
Aún necesita un "enlace de validación" enviado por correo electrónico, pero para un propósito muy distinto: el enlace de validación se usa para asegurarse de que la dirección de correo electrónico sea genuina. Un atacante que intercepta esa comunicación podría engañarlo (es decir, registrarse con una dirección de correo electrónico que no es su "dueño", aunque puede interceptar los correos electrónicos enviados a esa dirección, por lo que realmente es su propietario, hasta cierto punto), pero tal atacante lo haría. No atacar lo mismo que en el primer contexto. En el primer contexto, el atacante se hace pasar por el usuario que tiene derecho a iniciar sesión; en el segundo contexto, el atacante tiene el derecho de iniciar sesión de todos modos, pero logra hacerlo al proporcionar la dirección de correo electrónico de otra persona.
Summary
Enviar una contraseña inicial única por correo electrónico es algo bueno o malo, según el tipo de registro que esté ejecutando. Para una creación de cuenta clásica basada en la Web que cualquiera puede hacer, esto es malo. Para el registro de una persona específica, el cumplimiento de un cambio de contraseña desde la contraseña inicial es bueno, porque en ese caso, ya tenía que enviarlo por correo electrónico, lo cual es un peligro para la seguridad (simplemente no tenía elección, y usted debe mitigar los riesgos).