Cuentas y sesiones afectadas

Una sesión es lo que la aplicación entrega después de autenticarte: una cookie o un token que sirve en lugar de la contraseña durante un tiempo. Cambiar la contraseña modifica lo que hace falta para entrar, pero la sesión que ya existe sigue siendo válida si la aplicación no la invalida al hacerlo.

Que sea así o no es una decisión de diseño de la aplicación, y por eso la tabla de política de sesión es la primera que se lee: dice cuánto dura una sesión, si caduca por inactividad y si el cambio de contraseña las cierra.

El registro de autenticación de la aplicación anota cuenta, dirección y resultado de cada intento. Una dirección que falla en varias cuentas distintas y acierta en una, sin repetir la misma, es la huella de probar credenciales que alguien obtuvo en otro sitio, no de una persona que olvidó la suya. Lo primero que se necesita es saber en qué cuenta entró primero.

El orden lo da la hora, en UTC.

El alcance de la contención es la lista de cuentas con acierto, no el número de intentos. Los fallos no entregan sesión: solo cuentan las cuentas distintas que entraron. Una cuenta que aparece dos veces con acierto se cuenta una sola vez.

La tabla de sesiones guarda la creación, el último uso y la dirección de ese último uso. Cruzada con las acciones del equipo, deja ver lo que la contraseña sola no cerró: una sesión «activa» con un último uso posterior a la hora en que se restableció la contraseña de su cuenta, y desde la misma dirección ajena.

No basta con que la sesión siga abierta: lo que prueba el problema es que se usó después.

La contención de cuentas tiene un orden con sentido: primero se invalidan las sesiones de todas las cuentas alcanzadas (si se hace después, la sesión abierta sigue sirviendo mientras se espera), luego se fuerza el restablecimiento de contraseña y por último se comprueba en el registro que la dirección ajena ya no logra usar nada. Se actúa sobre las tres cuentas, no solo sobre las dos que el soporte ya tocó.