token de sesión criptográfica vs token de sesión aleatorio almacenado [duplicar]

Question

token de sesión criptográfica vs token de sesión aleatorio almacenado [duplicar]

#1 de CBHacking (2 votos)

1

Estoy creando una API web y me cuesta mucho elegir entre token de sesión criptográfica y token de sesión aleatorio para la autenticación de usuario.

Veo varios pros y amp; contras para cada uno:

token de sesión aleatorio almacenado (almacena un par que caduca {token: userId} en una base de datos):
- realmente aleatorio, con un riesgo de colisión insignificante; se puede realizar una verificación única adicional durante la inserción de la base de datos
- almacenado en una base de datos, lo que lleva a costos de escalado, desvía los costos de mantenimiento
- los tokens pueden ser revocados
- no hay riesgo de criptoanálisis mientras se use la función aleatoria correcta
token de sesión criptográfica (use una combinación fuertemente encriptada de 'userId, expiryTime' con una clave simétrica común almacenada en el servidor)
- aleatorio en cada sesión, gracias al tiempo de caducidad & un nonce
- no es necesario almacenarlas (no es necesario realizar llamadas de red adicionales): el descifrado simétrico del token de sesión será más rápido. Esto conduce a una mejora masiva de los devops y al costo
- los tokens no pueden ser revocados
- riesgo de criptoanálisis
- riesgo de colisión insignificante pero existente que no se puede prevenir
- riesgo con la clave maestra simétrica

El enfoque más seguro parece ser el token de sesión aleatorio almacenado, sin embargo, los costos & Los problemas relacionados con la base de datos devops realmente me hacen dudar.

¿Alguna ayuda sobre las mejores prácticas, y si los expertos en seguridad considerarán que el token de sesión criptográfico es una prueba de prueba? Tal vez una sugerencia de una solución más fuerte?

El enlace proporcionado aún reconoce que se usan ambos. Me pregunto si un experto en seguridad rechazará el token de criptografía para un sitio web bancario. ¿Dónde trazas la línea?

authentication risk-management session-management token

pregunta user3684457 20.09.2015 - 17:50

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication risk-management session-management token

Cómo evitar el almacenamiento de texto sin formato durante la autenticación CHAP Forensics hdparm command

score 2 · Accepted Answer

Hablando como consultor de seguridad, sí, definitivamente marcaría el segundo enfoque como una vulnerabilidad de seguridad. Una clave como esa corre mucho riesgo de que un atacante encuentre alguna forma de volcar o determinarla, y una vez que lo hacen, pueden hacerse pasar por cualquier usuario. Puede hacer que sea más difícil a través de una serie de trucos, pero al final del día confía en que el cliente realice la gestión de la sesión. No hagas eso, incluso cuando se supone que la información se supone es opaca para el cliente. Si nada más, la revocación es en sí misma un buen punto (especialmente si tus tokens tienen una vida útil no trivial).

Cachear datos pequeños, como un ID de sesión - > mapeo de ID de usuario, se puede hacer con bastante facilidad y con una sobrecarga mínima. Agregar nuevas asignaciones es relativamente poco frecuente: cada sesión se usará muchas veces por cada vez que se cree una, por lo que no tiene que optimizar la creación. No necesariamente tiene que ser persistido en nada; para un sitio web bancario ¡sus tokens deben ser de muy corta duración! En cuanto a "hacerlo bien", un token de longitud segura (128 bits es bueno) de un generador de números aleatorios criptográficamente seguro es un token de identificación excelente.