Evita el secuestro de la sesión, donde un atacante roba el ID de la sesión (cookie) del navegador físicamente

Las cookies están ahí para evitar la autenticación a través de una contraseña para cada transacción web (de lo contrario, cada página protegida tendría que volver a autenticarse cada vez que se acceda a ella).

En ese sentido, las cookies son independientes de la contraseña.

Deben ser revisados por

• el navegador que verifica que su validez no haya caducado. El servidor nunca debe confiar en esta verificación por medios de seguridad, ya que el navegador es controlado por el cliente (y puede elegir no verificar la validez)
• el servidor que garantiza que la cookie que recupera del cliente sigue siendo válida según sus propios criterios (el servidor) (debe realizar un seguimiento de la validez de las cookies independientemente de un posible "tiempo de validez" dentro de la cookie) .

Por lo tanto, el hecho de que haya cambiado la contraseña no significa necesariamente que la cookie no sea válida. Debería ser así porque el servidor debería invalidarlos de su lado.
Cerrar sesión es la forma normal (o mejor dicho, debería ser) de invalidar las sesiones.

No hay mucho más allá de eso (en términos de cookies como un mecanismo de autenticación), son una forma posible de evitar la reautenticación constante.

Para agregar a lo que dijo @WoJ, este comportamiento no es ideal, pero los sitios más grandes a menudo proporcionan una lista de sesiones activas, que generalmente incluye la dirección IP de acceso y ofrece la opción de expirar sesiones específicas. En el caso de que varias direcciones IP accedan simultáneamente al sitio utilizando los mismos detalles de la sesión (la misma cookie, en este caso), esperaría que un sistema seguro expire esa sesión y cierre ambas instancias, lo que solicita al usuario que vuelva a iniciar sesión. .

En general, la caducidad de todas las sesiones activas es la mejor práctica cuando se cambia una contraseña en una cuenta, pero hay casos en que esto no se hace. Además, incluso cuando esto no sea así (tal vez el sitio no quiera desconectar a los usuarios de las sesiones móviles por algún motivo), el identificador de la sesión actual debería cambiarse; esto normalmente se indicaría al navegador al configurar una nueva cookie.

Existe una vulnerabilidad relacionada conocida como reparación de sesión, donde una cookie específica no se cambia al iniciar sesión, por lo que un atacante que haya podido configurar una cookie por adelantado (probablemente a través del acceso a la máquina) puede obligar al sitio a use un identificador de sesión conocido, que tendría el mismo resultado: un atacante podría usar la misma sesión que el usuario legítimo. Una vez más, la solución es garantizar que, al iniciar sesión, el identificador de sesión se regenere.

Por cierto, ninguno de estos es un click-jacking, eso es un ataque distinto.