¿Está utilizando el token JWT para "recordarme" menos seguro que el token de sesión aleatorio?

7

Estoy después de leer " enlace " y " enlace " (entre otros :-)) y lo que me gustaría evitar es usar a ciegas todas las medidas de seguridad que se puede pensar simplemente para sentirse más seguro. Algo como el hash de un hash "por si acaso".

Lo que tengo ahora (el 3er día de pasar por el ejemplo MEAN) - Tengo el token JWT (id del usuario) + la fecha de vencimiento. Así que el token no vivirá para siempre. Este token se almacena como una cookie para obtener la función "Recordarme".

Lo que me molesta aquí es la falta de datos aleatorios que el servidor agrega a la mezcla, por lo que es seguro, no seguro, pero es una configuración muy determinista (consulte el segundo artículo que vinculé).

Así que me pregunto si el token JWT es menos seguro que el token de sesión "clásico". Estoy pensando en tal configuración:

  • el usuario inicia sesión, el token JWT se crea como antes, el token de la sesión también (id + número aleatorio), el hash del número aleatorio se almacena en la base de datos (la fecha de caducidad se establece, por supuesto)
  • para trabajo normal Se usa token JWT (no se usa para "recordarme")
  • el token de sesión se usa para "recordarme", se almacena como una cookie

Y cuando el usuario regresa, "recordarme" se activa, en lugar de iniciar sesión, se utiliza una cookie con el token de sesión para autorizar al usuario, en caso de éxito, se crea JWT.

Entonces habría tres "capas":

  • inicio de sesión + contraseña: uso infinito en el tiempo
  • token de sesión ("recordarme"): uso a largo plazo
  • token JWT: uso a corto plazo, solo para el trabajo actual

Mi pregunta es: ¿es mi primer enfoque con JWT único menos seguro o no? O, en otras palabras, ¿está agregando "token de sesión" como describí anteriormente? ¿Hice esta configuración más segura o solo hice más desorden? :-)

    
pregunta greenoldman 08.07.2016 - 20:55
fuente

2 respuestas

7

JWT, si está hash y está lo suficientemente encriptado, es tan seguro como las sesiones y conlleva menores gastos generales. Solo asegúrate de mantenerlo pequeño (aunque si estás haciendo algo que requiere más de unos pocos KB de almacenamiento, probablemente estés haciendo algo mal ...). Sigue las mejores prácticas para la sesión con JWT y estarás bien.

Si utilizas un algoritmo lo suficientemente fuerte y una tecla lo suficientemente fuerte, entonces el usuario que intente descifrarlo estará MUCHO fuera de suerte. Y si lo hacen, entonces también tienen que encontrar una manera de robar las cookies JWT de otras personas para obtener esa información (el mismo tipo de ataque contra una sesión).

Si un JWT es menos seguro que una sesión, entonces lo has diseñado mal porque un JWT es una sesión del lado del cliente. Todo lo que almacenarías en una sesión se puede almacenar aquí. Diablos, incluso puedes almacenar un ID de sesión en él para hacer un seguimiento de cosas más grandes en la base de datos que no tendrían un lugar en el JWT.

    
respondido por el Robert Mennell 08.07.2016 - 21:07
fuente
7

Como dijo Robert, un jwt puede ser tan seguro como una sesión si está bien cifrado. Asegúrate de que el secreto que usas sea único.

ADVERTENCIA: Existe una vulnerabilidad con algunas bibliotecas de token web de json que usan claves asimétricas.

node-jsonwebtoken, pyjwt, namshi / jose, php-jwt o jsjwt con claves asimétricas (RS256, RS384, RS512, ES256, ES384, ES512). Estas son bibliotecas vulnerables y, para solucionarlo, asegúrese de tener las últimas actualizaciones para ellas.

Este sitio web es muy útil en jwt education and testing: enlace

Esta respuesta de desbordamiento de pila explica las claves asimétricas y simétricas: enlace

Esto es lo que uso los paquetes en mi aplicación MEAN.    "jsonwebtoken": "^ 5.7.0",     "pasaporte-jwt": "^ 2.0.0"

passport.js es para autenticación

    
respondido por el nd510 08.07.2016 - 22:07
fuente

Lea otras preguntas en las etiquetas