¿Este esquema de token de API es lo suficientemente seguro?

Navega tus respuestas
4

Estoy diseñando una API REST para una aplicación móvil y tengo algunas dudas sobre la seguridad del acceso a las cuentas.

Estoy escribiendo el servidor de API en nodeJS y lo consumirá principalmente un cliente móvil (aunque se puede agregar un cliente web en el futuro)

Hay 2 aspectos secundarios principales que deseo incorporar en el proceso de autenticación:

  1. El ID de los usuarios está codificado en el token (para reducir el estrés en la base de datos)
  2. El usuario solo puede tener 1 token válido a la vez (el inicio de sesión anula cualquier token anterior)

Aquí está mi diseño inicial (todos los puntos finales están sobre SSL):

Iniciar sesión

  1. usuario POST es su nombre de usuario y amp; contraseña para '/ login'
  2. El servidor verifica que los usuarios existen y la contraseña coincide con el hash bcrypt en la Db
  3. El servidor genera un uuid v4 para el usuario y lo almacena en Rojos con el ID de los usuarios como clave
  4. Los usuarios uuid y el ID de usuario se codifican en un token web de Json con una caducidad de 1 semana
  5. El JWT se envía de vuelta a los usuarios como su token de autenticación

Ruta protegida

  1. El usuario envía la solicitud GET '/ users / me' con su token configurado como Autorización: encabezado del portador
  2. El servidor verifica el JWT y envía las respuestas de error apropiadas si falla la verificación
  3. El servidor luego consulta el almacén Redis y verifica que el uuid almacenado para el usuario coincida con el uuid codificado en el JWT
  4. Si los uuids coinciden, el ID de los usuarios se establece en req.user y la solicitud se procesa, si no, el mensaje de error se devuelve

¿Esto parece una buena estrategia de autenticación o estoy muy lejos?

    
pregunta Ross J 20.03.2014 - 11:41
fuente

1 respuesta

6

Encuentro dos fallas posibles.

Los UUID en general no garantizan la criptografía aleatoria. Dependiendo de la implementación, puede ser posible dar una conjetura calificada acerca de qué otros UUID han sido generados por un generador, dado algo de la salida. Debe usar una longitud de salida adecuada de un generador de números aleatorios criptográficos como token de sesión.

Cuando se extiende a un cliente web, debe protegerse contra la falsificación de solicitudes entre sitios, es decir, cualquier solicitud de cambio de datos en el servidor debe tener un token que no sea una cookie como parte de la solicitud; de lo contrario, la solicitud puede provenir de otro sitio web abierto en la computadora de los usuarios.

Otra cosa, si desea reducir el estrés en la base de datos, puede almacenar la información de la sesión en la memoria de proceso en el nodo. Solo necesita la base de datos para las cosas que deben persistir durante un bloqueo.

    
respondido por el aaaaaaaaaaaa 20.03.2014 - 13:54
fuente

Lea otras preguntas en las etiquetas

Intoxicación de caché de DNS en LAN sin MITM ¿Todas las suites de cifrado con rc4 tienen fallas intrínsecas?