¿Es seguro usar sal Bcrypt generado en la cookie para servir como token en lugar de una contraseña?

Question

¿Es seguro usar sal Bcrypt generado en la cookie para servir como token en lugar de una contraseña?

#1 de Lucas Kauffman (7 votos)
#2 de Stephen Touset (4 votos)
#3 de Jacco (0 votos)

8

Tengo un sitio web (hobby) que solo se ejecuta en SSL. El sitio no se ocupa de las finanzas, los números de seguridad social o cualquier cosa de ese nivel de importancia. Sin embargo, me gustaría asegurarlo tanto como sea razonablemente posible. Las cookies están marcadas como seguras y httponly. Las contraseñas se almacenan en el lado del servidor utilizando bcrypt.

Estoy intentando implementar "recordarme" para aquellos usuarios que quieran usarlo. Examinando este sitio, sé que no desea almacenar una contraseña en una cookie; más bien, desea almacenar un "token" que permita un uso no crítico, pero luego solicite la contraseña real para acciones críticas (por ejemplo, cambiar la contraseña).

En lugar de generar aleatoriamente un token, luego crear una base de datos (u otro método) de coincidencia, ¿es demasiado inseguro utilizar el sal generado aleatoriamente de bcrypt como el token en la cookie?

Las ventajas son:

Se genera al hashear la contraseña, por lo que no hay costo o código adicional
Almacenado con contraseña, por lo que puede encontrar y hacer coincidir según sea necesario
Único

Las desventajas pueden ser:

El token no cambia de sesión a sesión

Si la cookie es robada de alguna manera, solo permite el acceso no crítico al sitio. Es decir, no revela la contraseña real, la contraseña no se puede cambiar, el correo electrónico asociado con la cuenta no se puede cambiar.

¿Estoy pasando por alto algo serio en el esquema anterior?

passwords salt cookies bcrypt

pregunta RPW 29.09.2012 - 23:44

fuente

3 respuestas

Lea otras preguntas en las etiquetas passwords salt cookies bcrypt

Grieta simple RSA dado p, q y e ¿Hay alguna forma de rastrear físicamente el hardware robado?

score 7 · Answer 1

Mis dos centavos, no estás pasando por alto nada. Su esquema es correcto. Pero recuerda que lo que estás haciendo no es seguro. El identificador de sesión debe ser único para cada sesión. ¿Por qué puedes preguntar?

Bueno, sugiera que un atacante puede robar la cookie. Entonces él puede iniciar sesión como ese usuario. Hasta que el usuario cierre la sesión, porque entonces el identificador de sesión caduca. Sin embargo, si su ID de sesión permanece igual en todas sus sesiones, el atacante podrá seguir iniciando sesión como usuario, independientemente de si el usuario está desconectado o no.

En resumen, esto significa que, una vez que un atacante ha robado una cookie, tendrá una clave permanente para las sesiones de ese usuario (a menos que el usuario cambie la contraseña). Tenga en cuenta que esto se considera un alto riesgo. El impacto de tal ataque puede ser bastante alto.

score 4 · Answer 2

No hagas esto.

Si un atacante olfateara el ID de la sesión por el cable, el atacante ahora tiene un acceso efectivo a la cuenta del usuario. Igualmente malo, no tiene forma de expirar la sesión si sí sabe que esto ha sucedido ya que no puede regenerar el resumen de bcrypt sin tener la contraseña del usuario.

No trates de ser creativo. Genere un token aleatorio en cada nueva visita y vuelva a generarlo al iniciar sesión para evitar ataques de fijación de sesión (cuando un atacante establece el ID de sesión de un usuario en un valor que conoce, luego espera que el usuario inicie sesión antes de acceder al sitio con ese ID) .

score 0 · Answer 3

Además de las respuestas anteriores, al tratar la necesidad de que los tokens de sesión sean aleatorios y diferentes para cada sesión, también existe otro riesgo al exponer públicamente la sal de un hash de contraseña.

Si bien es cierto que una sal no debe ser secreta, al mismo tiempo no es una buena idea dar a conocer públicamente. Esto se debe a que un ataque que conoce la sal, puede construir una tabla de arco iris para esta sal en particular , antes de obtener una copia de las contraseñas con hash.

Cuando obtiene la copia de las contraseñas con hash (por ejemplo, mediante un ataque de inyección de SQL) ahora puede intentar buscar inmediatamente el valor del hash para el que ya construyó la tabla del arco iris. De este modo, se minimiza el tiempo entre el ataque y el uso malicioso real de los datos robados.

Polynomial ha respondido esto mejor que yo .