¿Por qué Google requiere una nueva autenticación antes de poder iniciar el proceso de cambio de contraseña?

1

Cuando un usuario desea cambiar la contraseña de una cuenta, la mayoría de las aplicaciones web presentan un formulario donde el usuario debe ingresar la nueva contraseña y la contraseña anterior. Hasta ahora pensé que entendía los beneficios de este enfoque. Por ejemplo, la contraseña antigua es una mitigación adicional a CSRF y evita el secuestro de cuentas (es decir, cambiar la contraseña de una cuenta) si un atacante obtiene la sesión web.

En Google - por supuesto;) - es diferente. Cuando el usuario hace clic en el enlace para cambiar la contraseña, se presenta un formulario de inicio de sesión y el usuario debe volver a autenticarse. Después de volver a autenticar, se muestra un formulario donde el usuario solo tiene que ingresar la nueva contraseña. La contraseña antigua no es necesaria otra vez.

Hay algunos pros y contras con los enfoques:

  • Pedir la contraseña allí donde ocurre el cambio (primer enfoque) tiene la ventaja de que se reduce considerablemente el riesgo de que se puedan aprovechar las debilidades en todo el proceso. La nueva contraseña y la contraseña anterior se procesan como un par. Si algo sale mal (por ejemplo, un atacante puede establecer un usuario arbitrario para la sesión web), existe una alta probabilidad de que la contraseña anterior aún proteja el cambio de contraseña.
  • Para el segundo enfoque (Google), podría haber puntos débiles en el proceso después de la autenticación (por ejemplo, la protección CSRF podría fallar, errores en la administración de la sesión).
  • El segundo enfoque tiene la ventaja de que la aplicación para cambiar la contraseña no es accesible antes de la autenticación. Por lo tanto, las debilidades en la aplicación no son accesibles antes de la autenticación nuevamente. Las debilidades que no son accesibles no pueden ser explotadas.
  • Tal vez Google quiera implementar una sola forma para realizar la autenticación. Creo que Google utiliza algún tipo de análisis de riesgo para el inicio de sesión y que podría ser posible que Google simplemente quiera usar esos mecanismos para el proceso de cambio de contraseña.

En mi opinión, el riesgo de debilidades en el segundo enfoque es mucho mayor, especialmente porque pueden ocurrir muchas cosas entre la autenticación y el envío de la nueva contraseña. Además, creo que la reutilización del análisis de riesgos y cosas por el estilo deberían ser posibles sin un gran esfuerzo para un proceso de cambio de contraseña también.

Entonces, mi pregunta es ¿echo de menos algo que hace que el segundo enfoque (Google) sea superior?

    
pregunta DanielE 05.07.2016 - 21:59
fuente

4 respuestas

3

Mi conjetura sería que para Google les permite manejar todas sus diferentes opciones diferentes para TFA (autenticación de dos factores) más fácilmente. En la parte superior de mi cabeza, admiten 3 o 4 métodos diferentes al menos. También le permiten tener múltiples TFA activados a la vez para que pueda elegir cuál usar.

No estoy diciendo que no puedas manejar todo eso en la misma página de cambio de contraseña con los campos de contraseña anterior y nueva, pero definitivamente es más complicado que solo pedir la contraseña antigua junto con la nueva.

    
respondido por el Evan Steinbrenner 06.07.2016 - 01:02
fuente
0

Una cosa a tener en cuenta es que Google ha dedicado mucho tiempo a diseñar su sistema de autenticación, lo que equivale a un grupo de expertos de ingenieros a nivel de PHD. Parece que proteger la forma de cambio de contraseña es solo otra implementación de esa funcionalidad, como es el propósito del código portátil y reutilizable. En mi humilde opinión, debería ser apalancado más a menudo. De esta manera, los desarrolladores no tienen que crear lo que es básicamente una segunda forma de su sistema de autenticación (es decir, oldpw == currentPW? ChangePW: returnError) cuando el original funciona bien.

Usted tiene razón en su evaluación de que las debilidades en un formulario de cambio de PW que no es accesible sin iniciar sesión, se presentan como una disminución de los riesgos.

Desarrollado e implementado correctamente, no sé que una versión de esta historia sea mejor que la otra (como ha demostrado que tienen ventajas y desventajas), por lo que creo que se trata de preferencias, arquitectura y decisiones comerciales. en dónde enfocar el tiempo y los esfuerzos de su desarrollador.

    
respondido por el HashHazard 05.07.2016 - 22:40
fuente
0

Tendría sentido para mí si también solicitaran el segundo factor en la re-autenticación, pero no lo hacen. Y la nueva página de contraseñas necesita una nueva autenticación si se abre de nuevo. Así que es muy similar al primer caso, pero se divide en 2 páginas. Así que no hay oportunidades para CSRF.

Supongo que fue más una elección arquitectónica que una seguridad. Además, las contraseñas antiguas y nuevas en la misma página son demasiado comunes para Google, supongo XD.

Realmente quiero ver una mejor razón que esta, sin embargo.

    
respondido por el subash 05.07.2016 - 23:44
fuente
0

Es porque las personas se alejan de su computadora, dejándolas desbloqueadas y conectadas.

El segundo requisito de inicio de sesión significa que la persona que está en la silla junto a usted no puede robar su cuenta cuando va a tomar más café o si tiene que correr para su avión y olvidó cerrar sesión o si alguien roba su sesión

Hacen esto por cualquier cosa relacionada con la seguridad.

Realmente no hay inconveniente.

    
respondido por el PushfPopf 12.11.2018 - 19:22
fuente

Lea otras preguntas en las etiquetas