¿Es seguro generar una contraseña para un usuario al registrarse en una aplicación web?

Eso depende totalmente de su aplicación y sus requisitos.

Si sus aplicaciones necesitan verificar las direcciones de correo electrónico de los usuarios, puede enviarles un token generado aleatoriamente (uso único y válido por un período de tiempo limitado) para el primer inicio de sesión, en la dirección de correo electrónico que proporcionaron durante el registro. Y pídales que establezcan su propia contraseña después de usar ese token aleatorio para iniciar sesión. De esta manera también estás verificando su dirección de correo electrónico.

Si no está preocupado por la verificación del correo electrónico, simplemente puede pedirles que elijan una contraseña segura durante el registro. En este caso, no olvide volver a autenticar a los usuarios justo después de que se registren.

En cualquier caso, asegúrese de que sus usuarios elijan una contraseña segura, cumpliendo con una política de contraseña segura . Asegúrese también de que todas las funciones relacionadas con las contraseñas en su aplicación (contraseña olvidada, restablecer contraseña, etc.) también cumplan con la política de contraseña de su aplicación.

Si el método de generación tiene suficiente longitud y buen conjunto de caracteres, será más seguro que pedirle al usuario la contraseña.

El problema de esta manera que hace que los sitios web no lo usen, es que las contraseñas generadas automáticamente son difíciles de recordar y no ofrecen una buena experiencia de usuario.

Yo recomendaría no hacerlo. Su aplicación web debe tener una política de que las contraseñas solo se ingresan, nunca se emiten. Encuentro que siguiendo este enfoque, su aplicación será más segura en general.

También hay un problema adicional de cómo dar la contraseña al usuario. Mostrar la contraseña en la pantalla (ya sea en un correo electrónico o cuando se registran) conlleva el riesgo de que un internauta vea la contraseña. Si se muestra en la página, también existen riesgos de que la página se almacene en el navegador o en la memoria caché del proxy. Sí, los encabezados de respuesta deben configurarse para evitar esto, sin embargo, es fácil de olvidar.

Un mejor enfoque sería generar un enlace aleatorio como parte del proceso de registro , que se envía por correo electrónico al usuario. El enfoque también protege contra enumeración de usuarios y valida el correo electrónico al mismo tiempo. El enlace debe caducar, por lo tanto, si el correo electrónico se deja en la bandeja de entrada del usuario y luego se descubre, no se puede usar para iniciar sesión en la cuenta. En el momento del registro, la caducidad de este enlace es, de hecho, lo mismo que eliminar la cuenta. Esto es útil en el caso de que alguien haya ingresado la dirección de correo electrónico incorrecta; esta cuenta accidental no impide que el propietario de la dirección de correo electrónico real se registre.

Si un atacante todavía quisiera acceder a la cuenta en una dirección de correo electrónico a la que habían logrado acceder, sí podrían generar un nuevo registro en esa dirección de correo electrónico. Sin embargo, esto deja un rastro de auditoría atrás para que luego pueda determinar lo que sucedió. El uso del enlace le permite a la aplicación transmitir más información sobre lo que ha sucedido. p.ej. al hacer clic en un enlace caducado se podría generar un mensaje a efecto de Sorry, this registration has expired, please register again . Sin embargo, si un usuario intenta iniciar sesión con una contraseña caducada, no podrá proporcionar más información sobre la cuenta sin reducir la seguridad. Revelar que la cuenta ha caducado sería una vulnerabilidad de enumeración del usuario, y revelar que la contraseña ya se ha cambiado también filtra información sobre el estado de la cuenta.