Esquema de seguridad y autenticación de la aplicación web RESTful

Navega tus respuestas
4

Estoy creando una aplicación web donde el front-end es una aplicación de una sola página y el back-end la sirve a través de una API RESTful. Quiero asegurarme de implementar la autenticación de usuarios con las mejores prácticas de seguridad.

Estoy planeando un sistema que llevará a cabo los siguientes pasos para garantizar la seguridad de la autenticación:

Registrarse (o cambiar la contraseña):

  1. El usuario envía el nombre de usuario y la contraseña al servidor en texto sin formato a través de HTTPS
  2. La sal única se genera con la función urandom de Python (32 caracteres)
  3. Sal ante la contraseña
  4. La contraseña de Salt + está oculta con bcrypt
  5. Sal y hash almacenados en la tabla de la base de datos (base de datos SQL, más lenta que el valor clave, pero no me preocupa demasiado la velocidad excesiva para iniciar sesión)
  6. ID de sesión aleatoria generada con urandom (32 caracteres)
  7. ID de sesión almacenada en db clave-valor (¿Redis? Clave: id de sesión, valor: id de usuario) y se envía al cliente junto con el objeto de usuario (obviamente sin sal y hash)

Iniciar sesión:

  1. Al iniciar sesión, el usuario envía el nombre de usuario y la contraseña al servidor en texto sin formato a través de HTTPS
  2. El servidor recupera sal y hash de la entrada de los usuarios en la base de datos SQL
  3. Salt antepuesto a la contraseña y a través de bcrypt
  4. Si ambos hashes coinciden, la ID de sesión generada con urandom e ingresada en el db de clave-valor
  5. ID de sesión enviada al cliente con objeto de usuario

Cualquier otra solicitud al servidor:

  1. Solicitud y datos enviados a través de HTTPS, incluidos el ID de usuario y el ID de sesión
  2. db valor-clave buscado con id de usuario, si coinciden los ids de sesión, devuelve los datos solicitados junto con el objeto de usuario
  3. Si no coincide, devuelve el error 401

Manejo de sesiones:

  1. Permitir más de una sesión para el mismo usuario
  2. Establezca la caducidad de la sesión en 24 horas; cuando acceda, vuelva a ponerla en 24 horas
  3. Permitir la sesión persistente que caduca en 1 mes, cuando se accede también se vuelve a poner al tiempo de caducidad completo
  4. Al cerrar sesión, eliminar sesión de Redis

¿Será este un sistema seguro, escalable y rápido (cuando sea necesario)? Si no, ¿dónde están las fallas de seguridad? ¿Qué podría hacer para mejorar este proceso? ¿Es esto vulnerable a los ataques CSRF? ¿Mejora la seguridad al agregar la dirección IP del cliente y USER_AGENT a la sesión o esto es una exageración?

    
pregunta Tom Grant 30.01.2015 - 04:20
fuente

1 respuesta

0

La autenticación es un mecanismo complejo con una gran cantidad de posibles fallas de seguridad que deben solucionarse.

TLDR: use Open ID para la autenticación en lugar de implementar su propio mecanismo.

  1. Fuerza bruta: debe protegerse contra la fuerza bruta en la autenticación (número límite de intentos incorrectos de inicio de sesión) y también proteger contra la fuerza bruta de su ID de sesión. Si fuera un atacante simplemente forzaba el par de ID e ID de sesión hasta que no obtenga 401 ... ahora tengo una sesión válida. Debes bloquear eso después también. Puede utilizar un HMAC para firmar el ID de sesión. De esa manera, un atacante no puede adivinar su clave secreta utilizada para HMAC el ID de sesión y no puede forzarla.
  2. Robo de ID de sesión. No indicó cómo se devuelve la ID de sesión al usuario. Supongo que pretendía enviarlo para que el script del lado del cliente lo maneje y lo envíe con cada solicitud posterior. Eso hace que su ID de sesión sea susceptible de robo desde el lado del cliente (por ejemplo, XSS), la forma de protegerse contra esto es enviándolo en una cookie con el indicador "solo http" para que los scripts no puedan acceder a él ( y usted necesita asegurarse de que también el conjunto y límite de" seguro "para su dominio, etc ... )
  3. Su mecanismo no le permite al usuario el método de "recordarme", por lo que el usuario tendrá que volver a autenticarse cada vez que abra la aplicación, manteniendo el ID de sesión en una cookie también lo resolverá.
  4. CSRF: si la sesión se mantiene en una cookie persistente, se vuelve vulnerable a CSRF. La forma de protegerse contra esto es usar un token anti CSRF, también conocido como

Teniendo todo esto en cuenta ... mi recomendación final para ti es usar la ID abierta para autenticar a tus usuarios, mantener el trabajo duro de autenticación para los grandes y solo asegurarte de que lo estás utilizando correctamente, eso te ahorrará mucho. de dolor de cabeza y tiempo, y probablemente sería más seguro.

    
respondido por el aviv 30.01.2015 - 13:24
fuente

Lea otras preguntas en las etiquetas

Certificado de firma de correo: ¿Cuáles son los impactos cuando se revocan? El cambio de EIP en la tarea de desbordamiento de búfer fgetc ()