Tu cuenta fue vulnerada — ¿basta con cambiar la contraseña para echar al atacante?
Respuesta breve
No por sí solo. Muchos sistemas mantienen válidas las sesiones existentes y los tokens ya emitidos tras un cambio de contraseña — tokens de actualización OAuth, «contraseñas de aplicación», claves de API y cookies persistentes — así que un atacante con una sesión activa puede permanecer dentro. La respuesta correcta es cambiar la contraseña Y invalidar todas las sesiones y tokens, revocar las credenciales de aplicación y auditar los dispositivos MFA y los ajustes de recuperación. Creer que un restablecimiento solo expulsa al atacante es un error clásico de respuesta a incidentes.
Parece obvio: el atacante entró con tu contraseña, así que cámbiala y queda bloqueado. En los sistemas de identidad modernos esa intuición suele ser errónea, y actuar según ella da una falsa sensación de contención.
Por qué un cambio de contraseña no siempre expulsa
La autenticación y el acceso continuo están desacoplados. Te autenticas con una contraseña una vez, pero el sistema emite después artefactos de vida más larga que no revisan la contraseña en cada solicitud:
- Sesiones activas / cookies — una sesión de navegador iniciada puede seguir válida durante días sin importar la contraseña actual.
- Tokens de actualización OAuth — emitidos a apps conectadas, generan nuevos tokens de acceso sin volver a ver la contraseña.
- Contraseñas de aplicación / claves de API — credenciales separadas de larga vida, creadas precisamente para no depender de la contraseña principal.
- Confianza persistente del dispositivo — los indicadores «recordar este dispositivo» que saltan la reautenticación.
Un atacante que estableció una sesión activa o capturó un token de actualización simplemente lo sigue usando tras tu restablecimiento.
Lo que realmente expulsa al atacante
Trata el restablecimiento como un paso de una secuencia, no como el trabajo completo:
- Restablecer la contraseña — sí, hazlo igualmente.
- Invalidar todas las sesiones — activa un cierre de sesión global / «revocar todas las sesiones» para matar las cookies existentes.
- Revocar tokens y credenciales de aplicación — elimina concesiones OAuth, tokens de actualización, contraseñas de aplicación y claves de API.
- Auditar la MFA y los ajustes de recuperación — los atacantes suelen añadir su propio dispositivo MFA, correo alternativo o teléfono de recuperación para restablecer la contraseña justo después. Quita todo lo que no reconozcas.
- Revisar las reglas de reenvío y los consentimientos OAuth — persistencia común en cuentas de correo.
La conclusión para la entrevista
El error es tratar la autenticación como una puerta continua cuando en realidad es un punto de control puntual que emite tokens duraderos. Decir solo «cambia la contraseña» revela que no entiendes el ciclo de vida de sesiones y tokens. La respuesta fuerte es «restablecer la contraseña y revocar cada sesión, token y vía de recuperación, luego verificar la MFA».
Posibles preguntas de seguimiento
- ¿Por qué un token de actualización OAuth puede seguir funcionando tras restablecer la contraseña?
- ¿Qué artefactos de la vía de recuperación debes auditar para que el atacante no restablezca la contraseña de nuevo?
- ¿Cuándo es «cierre de sesión global / revocar todas las sesiones» la primera acción correcta?