Flujo de recuperación de contraseña: ¿Enviar la recuperación de contraseña a cualquier correo electrónico?

Posiblemente. No está claro de inmediato si confía en la dirección de correo electrónico como el único identificador (es decir, lo está utilizando como nombre de usuario) o si se está utilizando un nombre de usuario diferente. Si es el último caso, la falla obvia es que un atacante puede proporcionar el nombre de usuario de otra persona, pero proporcionar su propia dirección de correo electrónico como destino de la contraseña de recuperación.

Suponiendo que la dirección de correo electrónico es el único identificador para un usuario, obviamente deberá proporcionarla para restablecer su contraseña. Sugeriría que, independientemente de que exista una cuenta asociada con esa dirección de correo electrónico, el sistema debería responder de manera similar. (Por ejemplo, si dice "Se ha enviado la información de recuperación de su contraseña"). Sin embargo, obviamente solo desearía enviar el correo electrónico de recuperación si hay una cuenta correspondiente; Si no existe tal cuenta no hay nada que recuperar. Esto evita que un atacante intente varias direcciones para ver cuál tiene éxito y cuál falla, y por lo tanto, crea una lista de cuentas válidas en el sistema. (Si su aplicación es más rápida de responder si no necesita enviar el correo electrónico, es posible que desee agregar un poco de retraso aleatorio para ocultarlo).

Hay algunos problemas significativos potenciales, principalmente relacionados con aspectos de su procedimiento que no se han especificado (por lo tanto, "potencial"). Estas son consideraciones adicionales, en lugar de problemas con su método:

• Los robots automatizados pueden enviar correo basura a los usuarios enviando muchas direcciones de correo electrónico diferentes. Enviar un correo electrónico (o al menos dar la misma respuesta), independientemente de si un usuario es válido o no, es una es una buena forma de evitar la enumeración de nombres de usuario, pero le abre este riesgo. Considere usar un CAPTCHA cuando los usuarios soliciten el correo electrónico de restablecimiento, para evitar el envío automático.

• El valor secreto incluido en el enlace puede ser demasiado fácil de adivinar. Si el token incluido en el enlace no se genera al azar con un alto nivel de entropía, un atacante podría ser capaz de para adivinarlo.

• El atacante puede reutilizar el valor secreto si el correo electrónico se ve comprometido en una fecha posterior. El token debe ser de un solo uso (es decir, un nonce) e, idealmente, debe caducar. después de un período de tiempo establecido (adecuado para su base de usuarios y requisitos de seguridad - OWASP_Pay_Pay_Aver_aver_a_Side-Channel"> OWASP_Pay_Pay_Aver_aver_a_Side-Channel"> OWASP_Pablen_Over_aver_a_Side-Channel"> OWASP minutos aquí , pero puede considerar que su solicitud no es tan sensible).

• El valor secreto podría ser interceptado. El correo electrónico carece de cifrado de extremo a extremo, y usted no sabe qué tan seguros están los servidores de correo o punto final de un usuario. Por lo tanto, algunas aplicaciones requieren pasos de verificación adicionales antes o después de enviar y seguir el enlace. OWASP recomienda preguntas secretas en la adición al correo electrónico, aunque Es posible que sienta que esto es excesivo para la sensibilidad de su aplicación.

• La nueva contraseña no se envía con seguridad de transporte. Naturalmente, la URL en su correo electrónico debe apuntar a una página HTTPS (parcialmente para que el usuario pueda verificar que está enviando su nueva contraseña directamente) al servidor), y luego el formulario también debe enviar la contraseña a través de HTTPS.

• Un atacante solicita un correo electrónico de restablecimiento en nombre de un usuario, y el usuario no puede evitar que el token permanezca activo. Considere proporcionar una manera para que los usuarios cancelen el restablecimiento de la contraseña desde el correo electrónico, permitiéndoles desactivar el enlace si no lo solicitaron.

• No se notifica al usuario si un atacante logra cambiar su contraseña. Considere al menos notificar al usuario por correo electrónico cada vez que se reinicie la contraseña, en caso de que no la haya iniciado.

Creo que es importante verificar que las direcciones de correo electrónico ingresadas realmente pertenecen a uno de sus usuarios antes de enviar el correo de recuperación. Suponiendo que su formulario de registro ya recopile direcciones de correo electrónico, sería una tontería no hacer uso de ellas para realizar esta simple verificación.

Sin verificación, una de las principales preocupaciones serían los spammers / piratas informáticos que ingresan toneladas de direcciones de correo electrónico invalidadas e inventadas. Esto causaría que su servidor envíe muchos mensajes que rebotan, y atrae la atención de los filtros de spam y las bases de datos de spammers. Eventualmente, su servidor podría ser incluido en una lista negra, y ya no se recibirían correos electrónicos de su sitio.

Además, las direcciones de correo electrónico mal escritas son bastante comunes, por lo que puede tener casos en que un usuario envía accidentalmente un correo electrónico de recuperación a la bandeja de entrada de otra persona.

Sin información adicional sobre su implementación, realmente no puedo señalar ningún otro problema, pero en la fase 3 hay algunas medidas de seguridad adicionales que puede considerar. Por ejemplo, debe asegurarse de que las URL de recuperación sean largas y aleatorias, de modo que no puedan ser fácilmente adivinadas o forzadas. Es probable que tampoco desees que las URL estén activas para siempre; es una buena idea caducar después de una o dos horas si un usuario genera una URL de recuperación pero nunca la visita o si la visita pero nunca proporciona una nueva contraseña. Para reducir aún más la posibilidad de un pirateo, puede deshabilitar completamente la función de recuperación de contraseña si la cuenta se utilizó en los últimos días, o si la ubicación basada en IP es atípica para ese usuario (aunque estas medidas pueden incomodar a los usuarios). / p>     

Phishing

Los spammers podrían falsificar el correo electrónico para restablecer la contraseña y engañar a otros usuarios para que hagan clic en un enlace que busca información para obtener información.

Los atacantes podrían DDOS su servidor

Al enviar el formulario rápidamente, es posible que su servidor no pueda mantenerse al día con la potencia de procesamiento requerida para enviar correos electrónicos lo suficientemente rápido