JS frontend para RESTful backend frente a autorización

1

Estoy construyendo una aplicación web. Y me preocupan los problemas de seguridad.

En el mundo hay muchas preguntas similares, pero muchas de ellas no tienen una respuesta realmente clara (consejo, sugerencia). Esta es la razón por la que hice esta pregunta.

Tengo página de inicio de sesión con nombre de usuario y contraseña. El usuario los POSTARÁ por HTTPS. El servidor lo comparará con el nombre de usuario y la contraseña de la base de datos y, si todo está bien, generará access_token usando un enfoque específico como: sha1(username + password + expiration_date) , btw, expiration_date es el tiempo de caducidad de Unix que el token. En consecuencia, expiration_date y access_token se escribirán en la base de datos al registro de usuario relacionado, access_token se enviará a la aplicación JavaScript del cliente por HTTPS sin duda.

Entonces, todas las solicitudes de la aplicación cliente se realizarán mediante HTTPS y access_token se incluirá en cada solicitud de encabezado. El lado del servidor debe autorizar esta solicitud y detectar la ID de usuario que ha enviado esta solicitud. El servidor hará la búsqueda en DB por access_token y verificará expiration_date ). Después de que se fundará access_token, debe verificar la siguiente condición: current_date <= expiration_date , si es verdadero, entonces está bien, si es falso, debemos regenerar access_token usando la nueva fecha de caducidad y guardarlas en la base de datos y enviar el nuevo access_token al cliente?

en caso afirmativo, ¿qué opina sobre el enfoque de seguridad?

    
pregunta web_dev 04.06.2012 - 14:49
fuente

1 respuesta

1

Suponiendo que al menos hash + saltea la contraseña de sus usuarios en la base de datos, su flujo de trabajo parece correcto.

Pero me gustaría agregar dos cosas:

  1. NO PONGA LA CONTRASEÑA DEL USUARIO EN TOKEN , no es seguro en absoluto y es totalmente inútil. El expiration_date también es inútil aquí. Simplemente coloca un sha1(username + 'randomly generated string') y estarás bien.
  2. Si el expiration_date ha caducado, no debería volver a enviar al usuario, sino pedirle que vuelva a iniciar sesión. Porque si haces lo que dices, ¿por qué usar un expiration_date entonces?

Para mi # 1, ya que su token es sha1 (nombre de usuario + contraseña + fecha de caducidad), como atacante, puedo saber el nombre de usuario, la fecha de caducidad y el access_token, los resultados de sha1.

Solo tengo que crear un sistema local de fuerza bruta que pruebe toda la combinación de la contraseña posible, y compare sha1 (nombre de usuario + "contraseña de prueba actual" + fecha de caducidad) con el access_token dado, y una vez que lo encuentre , Sabré la contraseña: /

    
respondido por el Cyril N. 04.06.2012 - 16:13
fuente

Lea otras preguntas en las etiquetas