token de acceso frente a UserID + token de acceso

Sin un ID de usuario, el sistema puede atacar un millón de veces más rápido que con el ID de usuario. Eso me parece razón suficiente.

Con un ID de usuario, un atacante solo puede atacar un token a la vez. Sin ID de usuario, con un solo intento puede atacar a 1 millón a la vez.

El "ID de usuario" que pretende introducir suena como una autenticación de segundo factor.

Por lo tanto, para acceder a su sistema, un adversario debe poseer el dispositivo y también debe conocer la ID de usuario asociada con el dispositivo.

Agrega una segunda capa de seguridad, siempre que la ID de usuario no esté impresa en el propio dispositivo. Si es suficiente depende del valor del objetivo que está protegiendo y los agentes de amenaza asociados. La mayor seguridad conlleva un mayor inconveniente ya que todos los usuarios deben realizar un paso adicional para obtener acceso.

En última instancia, necesita encontrar un equilibrio entre la comodidad y la seguridad con el que se sienta cómodo.

Pensé que despejaría el aire para cualquiera que lea esto en el futuro. El problema con el token de acceso solo es no la entropía. Es que hace que sea mucho más fácil explotar una vulnerabilidad utilizando un timing attack .

Un ejemplo de esto sería si su aplicación busca el token de acceso directamente desde una llamada a la base de datos where access_token = '' . Esto no se compara de forma segura, sino que regresará lo más rápido posible. Por lo tanto, le dará a un atacante la oportunidad de construir sus cadenas basándose en los tiempos de las comparaciones que están enviando. Hay formas de mitigar esta vulnerabilidad, como esperar siempre durante el mismo período de tiempo antes de devolver el resultado.

Resumiendo, lo bueno de enviar un user_id también es que puede recorrer todos los tokens de ese usuario y verificar si alguno de ellos coincide utilizando una comparación segura. Lo que a su vez, no le da al atacante ninguna información útil para sondas futuras.