¿Es seguro autenticar al usuario mediante un enlace de confirmación por correo electrónico?

Depende de por qué desea confirmar un correo electrónico. Si ese correo electrónico se usará más adelante para restablecer la contraseña, el flujo de trabajo propuesto tiene un problema de seguridad importante. Considere el siguiente escenario:

• Alice crea una nueva cuenta y escribe involuntariamente el correo de Bob (por ejemplo, copia y pega el correo y usa la línea incorrecta)
• el mal Bob ve el correo, confirma la cuenta, anota el nombre de inicio de sesión de Alice si es diferente del correo electrónico y cierra la sesión
• Alice intenta conectarse más tarde y ve que todo funciona bien. Asume que la validación fue automática y que normalmente usa su cuenta por un tiempo
• algunas veces más tarde, Bob intenta conectarse utilizando la cuenta de Alice, solicita un restablecimiento de contraseña = > como él posee el correo registrado, tiene éxito en cambiar la contraseña
• ¡Bob ahora es el propietario de la cuenta de Alice y puede hacer cualquier cosa en nombre de ella!

Ok, Alice no fue muy cautelosa al crear su cuenta, pero el flujo de trabajo propuesto realmente no la protegió :-(

Esa es la razón por la que mi flujo de trabajo preferido es:

• permita que un usuario cree una nueva cuenta con inicio de sesión, contraseña y correo electrónico (puede iniciar sesión o no, mejor no) - > la cuenta se crea sin activar y se destruirá si no se activa dentro de un período de tiempo limitado (por ejemplo, 2 días)
• enviar un enlace de confirmación único al correo dado
• el enlace abre un formulario login : el nombre de usuario debe estar completado previamente y es de solo lectura. Si el usuario inicia sesión con éxito, la cuenta se valida, el enlace se invalida y el usuario se pone en sesión. Si la contraseña es incorrecta después de tres intentos, se interrumpe la conexión.
• si un usuario intenta conectarse utilizando una cuenta no validada, ve un mensaje que dice que se envió un correo de validación a esa dirección, que aún tiene n días / horas para validar la cuenta y proponerle / ella para volver a crear la cuenta con una nueva dirección de correo. En ese caso, el enlace de validación anterior se invalida inmediatamente.

Si ocurre el escenario anterior, Bob no podrá validar la cuenta de Alice ni robar su cuenta más tarde.

Depende si el formulario de registro contiene datos confidenciales y si la cuenta recién creada puede tener algún valor para un tercero (ya sea por sí mismo o por suplantación de identidad del usuario legítimo).

El problema es que si el usuario cometió un error al escribir su dirección de correo electrónico, el enlace de registro se puede enviar a una persona desconocida.

• En el flujo de registro propuesto, este destinatario desconocido tendrá acceso a la cuenta recién creada.
• En su flujo de registro actual, este enlace será casi inútil para este destinatario, la única acción que puede hacer es "validar" la dirección de correo electrónico.

Por lo tanto, el flujo de registro propuesto puede aportar algunas mejoras de usabilidad al usuario final, pero a costa de una seguridad potencialmente más débil.

Con su "Flujo de registro propuesto" usted está asumiendo que la persona que acaba de crear la cuenta es la persona que hace clic en el enlace. Esta suposición es generalmente cierta y hay personas que se arriesgan a asumir este riesgo. Posteriormente, se trata de una cuestión de qué equilibrio está buscando entre seguridad y facilidad de uso (un tema de debate bastante interesante: D).

Lo malo de esto es que si su suposición es errónea, alguien podría simplemente iniciar sesión y restablecer la contraseña con acceso completo desde ahora a la cuenta, incluso cambiar la cuenta de correo electrónico del usuario.

Con su "Mi flujo de registro actual" ha mejorado la seguridad al tiempo que se arriesga a molestar un poco al usuario al obligarlo a iniciar sesión DE NUEVO, aunque eso es lo que acaba de hacer hace unos minutos.

La forma en que lo haría es que, al registrarme, inicio sesión directamente en el usuario, restringiendo lo que puede hacer pero abriéndole una sesión. Si quiere una funcionalidad completa de la que tiene que activar su cuenta. Después de hacer clic en el enlace de un solo token en su correo electrónico, se le redirige al sitio web donde, si tiene una sesión abierta, iniciará sesión (tener una sesión abierta significa que las posibilidades de que alguien obtenga su correo electrónico desde la inscripción hasta ahora son más bajos) de lo contrario, tendrá que volver a iniciar sesión (lo que significa que su sesión ha caducado mientras tanto, por lo que hay mayores posibilidades de que este ya no sea mi usuario).

Espero que esto te haya ayudado y espero que tenga algún tipo de sentido en lo que intenté exponer.

El problema que está indicando aquí es más bien si minimiza la seguridad (un poco) para obtener más facilidad de uso o si encuentra algo intermedio.

Yo diría, depende.

Todo el mundo sabe que el correo electrónico es inseguro, hay cosas que puede hacer para hacerlo de forma segura, pero por lo que sé, muy pocas personas lo usan y debe configurarse tanto en las cuentas del remitente como del destinatario.

Según lo dicho por @WhiteWinterWolf, le está dando acceso a la cuenta a quien sea el propietario de ese correo electrónico. Hasta ayer, escribí mal mi dirección de correo electrónico, la he tenido durante más de 10 años y debo haberla escrito más de 10.000 veces en ese tiempo, pero aún así cometí un error. Entonces, si puede suceder en esa situación, puede suceder en muchas más situaciones.

Por último, ¿qué tan bueno es tu azar? ¿Podría ser adivinado? No sé qué idioma está utilizando, pero hay funciones aleatorias que no son tan aleatorias como cree. ¿Está dispuesto a poner toda su fe en esa función aleatoria cuando podría agregar una protección?

Además, sé que esto no es UX, pero no hay mucha pérdida en términos de experiencia de usuario para iniciar sesión nuevamente, pero como medida de precaución, puede hacer que la página de autenticación de correo electrónico compruebe una cookie generada por el registro. Página, esto indicaría que el registro y la autenticación de correo electrónico se realizaron en el mismo navegador y eliminaría el requisito de iniciar sesión con esa cookie presente.

El flujo actual puede considerarse inseguro por las siguientes razones.

1. Un adversario que tenga acceso (incluso limitado) al correo electrónico de otra persona puede crear y usar una cuenta en su nombre.
2. La autenticación aquí depende completamente de la seguridad del correo electrónico. Correo electrónico, aquí está el enlace más débil y con acceso a él, un adversario puede obtener acceso.

En el flujo propuesto, los problemas anteriores se mitigan a medida que confirma que la persona que creó la cuenta y la persona con acceso al correo electrónico son las mismas.

He visto ciertas aplicaciones que utilizan el flujo original que mencionaste. Consideran que es un riesgo aceptado que limita los correos electrónicos aceptados a algunos dominios. El flujo original es fácil de usar con una ligera compensación en la seguridad.

  

La mayoría de los sitios web requieren que el usuario ingrese su contraseña después de activar   cuenta. ¿Es incluso necesario?

mucho.

Si alguien puede leer sus correos electrónicos, no pueden controlar su cuenta de esta manera, , ya que depende de un secreto compartido previamente, la contraseña .

Una muy buena práctica.

Es similar a requerir una contraseña para realizar acciones clave (consulte el modo sudo de GitHub), como cambiar la contraseña. Si alguien puede secuestrar su sesión o simplemente obtener acceso a su computadora, no pueden hacer mucho ya que todavía necesitan la contraseña, que no se les proporcionó.