¿Existe algún riesgo de seguridad para la autenticación de inicio de sesión y para cambiar la contraseña en la misma página?

  

Normalmente, el usuario necesita autenticarse primero para ver el formulario de cambio de contraseña.

Al ingresar el nombre de usuario y la contraseña, el sistema debería autenticar primero al usuario y una vez que la autenticación sea exitosa, la contraseña debe cambiarse. Esto es algo que no se puede verificar con la URL de ejemplo que proporcionó.

Sin embargo, en este caso, recomendaría tener un anti Mecanismo de falsificación de solicitudes entre sitios implementado en este formulario específico para validar el origen de la solicitud.

Además, se recomienda implementar algún tipo de mecanismo anti scripting para evitar que los robots adivinen las credenciales y luego cambiarlas al iniciar sesión correctamente. Por ejemplo, límite de velocidad o captcha después de x cantidad de solicitudes fallidas.

En cuanto a su pregunta sobre si existen riesgos de seguridad, mi respuesta sería: Puede haber, pero depende en gran medida de la implementación. Desafortunadamente, esto no es algo que podamos determinar sin tener una cuenta en una de estas aplicaciones.

Por lo que puedo ver en la página de ejemplo que nos proporcionó, no existe un mecanismo anti CSRF, que en teoría podría iniciar un ataque de fuerza bruta en su nombre si visitaría un sitio web malicioso que contiene este tipo de código. .

Uno de los posibles riesgos es que dicho formulario no requiera cookies o soporte de sesión para iniciar sesión con una contraseña robada y cambiarla de inmediato.

Desde la perspectiva de los autores de software malintencionados, hay muchos lenguajes y marcos posibles que se pueden usar para crear su software. Cada uno de estos requiere algún conocimiento para comenzar. P.ej. crear un bot que pueda iniciar sesión automáticamente en la página web y robar cierta información, requiere al menos conocimientos básicos, cómo funciona la sesión http, cómo funcionan las cookies, etc. Por lo tanto, para la mayoría de estas páginas es bastante fácil, pero no trivial, crear dicho bot.

Pero cuando creas un formulario que permite 2 cosas usando 1 solicitud, estás facilitando la escritura de un bot que cambiará inmediatamente la contraseña robada para evitar que el usuario inicie sesión y, por lo tanto, le da al atacante algo de tiempo (antes restablecimiento de la contraseña por el administrador notificado) para buscar más información interesante.

En general, no. No hay riesgos de seguridad adicionales significativos asociados con este enfoque.

Cualquier atacante que pueda cambiar exitosamente la contraseña del usuario usando un formulario como este podría fácilmente iniciar sesión en la cuenta del usuario y luego cambiar su contraseña. De cualquier manera, se requiere la misma información (nombre de usuario, contraseña actual, nueva contraseña).

Los formularios de cambio de contraseña generalmente se colocan detrás de un formulario de inicio de sesión por razones de conveniencia, no de seguridad. Si un usuario ya ha iniciado sesión, es un inconveniente forzarlo a ingresar su nombre de usuario nuevamente antes de cambiar su contraseña.

Dicho esto, existen los riesgos de seguridad habituales a tener en cuenta con un formulario como este. Básicamente, cualquier protección que normalmente pondrías en un formulario de inicio de sesión también deberías poner aquí. Esto incluye intentos de cambio de contraseña con limitación de velocidad y la protección del formulario contra CSRF ( particularmente si la aplicación firma automáticamente a los usuarios cuando cambian su contraseña ).

Creo que hay pro / contras para ambos enfoques. Recuerde que generalmente debe pensar en un enfoque en capas .

En primer lugar, ¿es esto más utilizable? ¿Confunde al usuario? contraseña (teórica en este caso, pero UX es muy importante para que las personas jueguen bien con la seguridad). Hay un beneficio de UX al tener que pasar por menos páginas. Mantener los flujos bien entendidos y el diseño uniforme también es importante para ayudar a los usuarios a identificar el phishing: si las cosas cambian constantemente o son diferentes, el usuario puede estar confundido.

En este caso, me preocuparía más lo que está sucediendo en el resto de mi pila. ¿Qué otra cosa además del nombre de usuario se utiliza para identificar al usuario? ¿Existen cookies del navegador, huellas digitales del navegador, etc.? Si todas estas cosas solo se tienen en cuenta para un usuario autenticado, es posible que desee prohibir una acción de alto riesgo hasta después de la autenticación. Si tiene una seguridad razonable de la identidad del usuario, puede que no sea un gran riesgo en equilibrio con el lado UX.

Mi conjetura sería que, en general, cuando los desarrolladores toman esta decisión no necesariamente tienen en cuenta los objetivos de seguridad o los motivos de seguridad. Puede ser más fácil para el flujo de usuarios o la mesa de ayuda proporcionar estos enlaces en lugar de dar instrucciones que incluyan el inicio de sesión y luego navegar en algún lugar. También puede tener sentido desde el punto de vista de los desarrolladores segmentar cada función de esta manera.

Por lo general, me gustaría ver una autenticación exitosa y luego solicitar una nueva autenticación para cambiar la contraseña. Creo que esto también proporciona más compartimentación (elimina la identidad de la imagen) que probablemente conduciría a menos errores relacionados con la seguridad; también está restringiendo el privilegio solo a usuarios ya autenticados. Estoy de acuerdo con algunas otras respuestas en que existe el riesgo de bloqueo / DoS al poner esta función antes de una autenticación inicial.

Desde el punto de vista de la seguridad, esto debería estar bien siempre que la página proteja contra la enumeración de usuarios y la búsqueda de contraseñas.

Debería validar la combinación antigua de ID de usuario y contraseña en su totalidad, y no informar específicamente al usuario si la ID de usuario no existe, solo debe mostrar un mensaje de error genérico:

Your current user ID and password combination was incorrect. Your password was not changed.

Después de una pequeña cantidad de combinaciones de ID de usuario y contraseña incorrectas contra un nombre de usuario, debería acelerar las respuestas para reducir la velocidad Cualquier ataque de adivinación de contraseña, haciendo el ataque inviable. También debe hacer esto para las ID de usuario no válidas, para no filtrar la información de tiempo en cuanto a si la ID de usuario se relaciona con una cuenta válida o no.

Una de las ventajas de un formulario que solicita la contraseña existente es que protege inherentemente contra CSRF. Cualquier dominio externo que intente tal ataque no podrá proporcionar una contraseña actual válida. Esto se menciona en la Hoja de trucos de prevención de falsificación de solicitudes (CSRF) de OWASP como Reautentificación de Respuesta-Desafío .

Los únicos inconvenientes pueden estar en un nivel de interfaz de usuario. Como el navegador dejará en blanco los campos de contraseña en caso de que falle la validación del lado del servidor, el usuario tendrá que ingresar su contraseña actual y nueva dos veces más.