Reports
BAJA[AUTENTICACIÓN]#3189580

Remitly permitía "cambiar" la contraseña por la misma que ya estaba en uso

El flujo de restablecimiento y cambio de contraseña de Remitly aceptaba como nueva contraseña la que el usuario ya tenía, sin aviso ni error. En HackerOne figura sin severidad, pero el programa lo dio por resuelto.

Resumen
Resumen en castellano de un reporte público, no una traducción literal. El código y los comandos se mantienen como en el original.

Resumen

Cuando un usuario de Remitly restablecía o cambiaba su contraseña, la aplicación no comprobaba si la "nueva" contraseña era en realidad la misma que ya estaba usando. El formulario la daba por buena, el proceso se completaba y la cuenta seguía con exactamente la misma credencial.

No es un fallo que abra la puerta a nadie por sí solo: el investigador lo plantea como una carencia en la política de contraseñas. Según su análisis, debilita la protección de la cuenta, sobre todo combinado con un secuestro de sesión o con alguien que mantiene un acceso discreto a ella.

En HackerOne figura con la debilidad Unverified Password Change y sin severidad asignada ("none"). El programa lo marcó como resuelto. Se envió el 12 de junio de 2025 y se hizo público el 12 de octubre de 2026; el título del reporte lleva la referencia AUTH-3820.

Pasos de reproducción

  1. Iniciar sesión en una cuenta existente con sus credenciales válidas.
  2. Empezar un cambio de contraseña, ya sea desde "He olvidado mi contraseña" o desde la opción "Cambiar contraseña".
  3. En el campo de la nueva contraseña, escribir exactamente la contraseña actual.
  4. Enviar el formulario: el cambio se acepta sin ningún error ni advertencia.
  5. (Opcional) Volver a entrar con esa misma contraseña para confirmar que el "restablecimiento" se completó dejando la credencial igual.

Impacto

El reporte lo resume como mala higiene de seguridad: un usuario puede restablecer su contraseña una y otra vez a la misma, incluso si es débil. Eso resta valor al cambio de contraseña como medida de defensa, por ejemplo cuando alguien cree que ha cortado un acceso no autorizado y en realidad no ha cambiado nada. El reporte no describe un ataque concreto que permita acceder a cuentas ajenas.

Qué aprender de este caso

  • Al revisar un flujo de cambio o restablecimiento de contraseña, prueba a enviar la contraseña actual como nueva: es una comprobación de un minuto y muestra si el servidor compara el nuevo valor con el hash guardado.
  • La comparación tiene que hacerse en el servidor, verificando la nueva contraseña contra el hash actual (y, si se quiere ir más allá, contra los últimos hashes guardados), no solo en el formulario.
  • Si el cambio de contraseña se presenta como forma de recuperar el control de la cuenta, conviene que además cierre las demás sesiones abiertas; si no, ni siquiera una contraseña distinta expulsa a quien ya tiene una sesión robada.
  • Comprueba que los dos caminos, "olvidé mi contraseña" y "cambiar contraseña", aplican las mismas reglas: pueden estar implementados por separado y que solo uno valide.