¿Los enlaces de verificación de correo electrónico deben tener un "límite de tiempo" después del registro del usuario?

Un límite de tiempo para un enlace de verificación es una pequeña parte del modelo de seguridad general de su sistema. El principal riesgo-beneficio es que si el enlace se ve comprometido, el mismo enlace de verificación no se puede usar en el futuro (si el usuario nunca usó el enlace de verificación de una sola vez). El enlace podría verse comprometido por un futuro hackeo de correo electrónico de un usuario, los resultados se evaluarán mediante el escaneo de la red, etc. La teoría es que lleva algún tiempo comprometer el enlace en sí y luego actuar sobre él.

Es un riesgo de probabilidad bastante bajo, sin embargo, tiene sentido implementar un límite de tiempo.

Todo se reduce al riesgo. Existe hay cierto riesgo de que el enlace de restablecimiento pueda ser obtenido por un tercero, pero el tiempo que esto puede tardar es algo que supongo. Si el tercero tiene acceso a la cuenta de correo electrónico de alguna manera, entonces no importa de ninguna manera, pero existe la posibilidad de que el acceso esté limitado hasta que el usuario se aleje de su teclado sin recordar bloquear su pantalla. Lo que realmente se reduce es que, por lo trivial que es implementar, ¿por qué no haces que el enlace caduque después de 15/30/60 minutos?

Personalmente, al desarrollar una aplicación web con un sistema de reinicio de inicio de sesión, trato de evitar el uso de enlaces enviados por correo electrónico a menos que tenga que hacerlo absolutamente . Yo prefiero un sistema por el cual el usuario puede restablecer su contraseña en la aplicación web, lo que requiere que ingresen 2/3 partes de información que se configuró cuando se creó la cuenta (y luego, posiblemente, enviar un correo electrónico a un enlace / código / lo que sea). Por lo general, el usuario no puede cambiar la información, de modo que si la cuenta se ve comprometida, el tercero no puede impedir que el usuario real reinicie su contraseña.

Ningún método es una prueba completa, todo se reduce a tratar de mitigar los riesgos tanto como sea posible sin implementar algún tipo de ritual azteca que implique un sacrificio de sangre para restablecer las contraseñas.

Da la vuelta a la pregunta. ¿Por qué NO caducan los enlaces de verificación? Si incurre en pocos gastos generales, y existe la posibilidad de que pueda aumentar la seguridad de sus usuarios, incluso un poco, ¿por qué NO? Es probable que el tiempo que su desarrollador tome para implementarlo sea trivial, lo que es una victoria en comparación con la posibilidad (aunque es pequeña) de compromiso.

Lo que se debe y lo que no se hace es generalmente bastante estándar en seguridad. Si hay una pregunta, piénselo, porque la respuesta probablemente esté del lado de un poco más de esfuerzo. Sí, tiene que usar una función hash diseñada específicamente para el hashing de contraseñas. Sí, tienes que usar una función de derivación de clave estándar. Sí, deberías usar HTTPS en todas partes. ( Estoy mirando usted, Stack Exchange .) No, no puede escribir su propio cifrado.