Vulnerabilidades con tokens de sesión respaldados por DB

Diría que, en la mayoría de los casos, generalmente se considera que una vez que un atacante tiene un acceso de nivel DBA a su sistema se ve comprometido, por lo tanto, mitigar este ataque se realizará mediante la supervisión de la política / gestión de cambios / actividad, etc.

Si piensa en el daño que puede hacer un DBA enojado a un sistema, es probable que rastrear un token de sesión de usuarios sea bastante más bajo en la escala ...

Un administrador de base de datos enojado podría inyectar JavaScript en el contenido proporcionado por la base de datos y realizar ataques de XSS pristantes contra tu usuarios, lo que le permitirá robar los identificadores de sesión desde el navegador del usuario , haciendo que cualquier lugar en el que almacene los identificadores en el servidor sea tan bueno como el almacenamiento en la base de datos.

Entonces, el método que está proponiendo no es realmente inseguro, preferiría usar la administración de sesión integrada, como PHP $_SESSION[] y .Net's Session[] .

La razón por la que las contraseñas de hash es cuando un atacante tiene acceso a la base de datos (mediante inyección sql), debe dedicar tiempo y recursos para descifrar el hash de la contraseña antes de que sea útil.

El almacenamiento del token de sesión en la base de datos es un acceso directo, ahora está almacenando las credenciales de autenticación en la base de datos que se pueden usar de inmediato. Es como si estuviera almacenando contraseñas en texto plano.

Los tokens de restablecimiento de contraseña, los identificadores de sesión y las contraseñas deben estar marcados cuando se conservan estos datos.