¿Puedo almacenar de forma segura el hash (sessionId) en los registros de la aplicación?

3

Estoy considerando almacenar un hash del ID de sesión de un usuario en nuestros registros de aplicaciones en cada solicitud. Esto permitiría que las sesiones de los usuarios se rastrearan fácilmente a las acciones en nuestros registros.

Entiendo que almacenar esto es un riesgo potencial de seguridad, que puedo estar dispuesto a considerar si el riesgo es muy bajo. ¿Por qué es un riesgo? Si alguien que tiene acceso a los registros puede descubrir cómo obtener un ID de sesión, entonces esencialmente puede robar esa sesión de usuarios e iniciar sesión sin credenciales.

Para ese fin, si fuera a hacer esto, ¿cuál es la mejor manera de hacerlo?

Aquí hay algunas cosas que me gustaría considerar:

  • ¿Qué algoritmo de hash debería usar? Necesita ser rápido.
  • ¿Qué debería hacer hash? ID de sesión + Salt?
  • ¿Qué tan arriesgado es esto? ¿Debería simplemente no hacer esto?

EDITAR: Estoy considerando simplemente generar un GUID y agregarlo a una sesión de usuarios al crear la sesión. Entonces registrando esto en su lugar. De esa manera, siempre sería único para la vida de las sesiones. El problema con esto es que agregaría más datos de sesión y requeriría más memoria de sesión para cada usuario. Con este enfoque, no se necesitaría hash, y la sesión del usuario podría seguirse de forma única.

    
pregunta Brad Parks 26.08.2015 - 16:47
fuente

1 respuesta

5

Si el identificador de sesión se elige aleatoriamente de un espacio suficientemente grande (algo así como 12 bytes debería ser más que suficiente) entonces cualquier función de hash no invertible (incluso md5) será segura, y no habrá necesidad de sal (tablas de arco iris de este tamaño son inviables).

Para expandir, el problema al almacenar el hash de contraseña es que las contraseñas suelen tener una entropía muy baja (a diferencia de los tokens, como el identificador de sesión, por ejemplo). Además, no le interesan otras propiedades de la función hash en las que md5 se considera débil: el atacante no puede influir en su ID de sesión para que colisione con ningún usuario, e incluso si lo hace solo (en el mejor de los casos) lo confundirá al estudiar los registros). p>     

respondido por el Cthulhu 26.08.2015 - 17:18
fuente

Lea otras preguntas en las etiquetas