¿Debo también codificar mi ID de sesión antes de almacenarla en la base de datos? [duplicar]

  

Con sal, los ID no se verán igual en la base de datos, incluso si lo son.

• Los tokens de sesión deben generarse con un generador de números aleatorios criptográficamente seguros.

• Los tokens de sesión deben tener 72 bits de entropía o más.

Para el futuro previsible , un token aleatorio de 72 bits será globalmente único, por lo que La sal no es necesaria.

  

Pro [a hashing] El atacante no puede leer el [token de sesión simple] para enviarlo directamente.

• Es mejor buscar una dirección IP coincidente además del token de sesión. Es posible que esto no funcione para los usuarios móviles porque si cambian su IP (es decir, una señal débil), se desconectarán.

De lo contrario, el atacante puede usar el token de sesión desde cualquier IP, lo que, como sugiere, (después de un ataque SQLi) es poco más que una conveniencia, ya que el atacante ya tiene acceso a la base de datos completa.

Sin embargo, secuestrar una sesión de esta manera sería muy útil si algunos archivos / datos se almacenan fuera de la base de datos. (y si las sesiones comprometidas tienen acceso para ver esos datos)

  

[El token de sesión] no es realmente un secreto que se filtra a otros sitios, como lo harían las contraseñas.

Verdadero.

  

Si la base de datos está comprometida, todos los datos se pueden leer de todos modos. No es necesario [para el atacante] tomar el camino de la API.

1. A veces, los archivos o datos se almacenan fuera de la base de datos.

2. Un procedimiento de seguridad bastante común es usar cuentas de usuario de base de datos separadas , por lo que es posible que los tokens de sesión puedan ser robados con un SQLi de solo lectura (es decir, un usuario de base de datos de acceso limitado), con los datos más confidenciales permaneciendo seguros es decir, requiere un usuario de base de datos de propósito especial)

3. Puede que desee use contraseñas (y tokens de sesión) para acceder a las claves de cifrado en el camino.

Es realmente fácil ejecutar un SHA-2 rápido en el token de la sesión, por lo que si existe la posibilidad de que se implementen # 1, # 2 o # 3 en el futuro, ¡adelante!

Es bueno tener una función, pero no es absolutamente obligatorio.
Tendría mucho más de qué preocuparse si un atacante puede filtrar datos de su almacenamiento. Si está realizando una buena gestión de sesión, no debería preocuparse mucho por la clave de sesión.

Puede consultar la guía OWASP para la administración de sesiones: enlace
Y otra entrada de blog:
enlace

Dos vectores de ataque vienen a la mente:

Inyección de SQL, ya sea contra su sitio público o un sitio de administración administrativa: puede permitir que un usuario malintencionado obtenga un ID de sesión en tiempo real, lo que significa que podría hacerse pasar por cualquier usuario. Consulte también este artículo

Mecanismo de registro: usted ubica sus eventos de sesión de registro, y si se registran con el ID de sesión de cleartext y los controles de acceso a los archivos de registro no son tan seguros como su base de datos, entonces tendrá el mismo problema. Enlace a OWasP en este caso.