¿Son dos llaves de seguridad mejores que una?

Question

Acabo de implementar una función "recordarme" para el inicio de sesión de un usuario en un sitio web.La mayoría de los consejos fueron almacenar el ID de usuario en una cookie y luego tener una clave aleatoria larga e indescifrable.Si ambos coinciden, el usuario se considera autenticado.

¿Realmente ayuda tener dos cuerdas?¿Una llave más larga no haría exactamente lo mismo?

En otras palabras, ¿no son dos claves igualmente susceptibles a ataques que una clave más larga?(Me imagino que sería el largo total de las llaves, independientemente de cuantas tengas)

Nota: Aquí también puede haber algunos problemas de eficiencia de las consultas de la base de datos, por ejemplo, buscar un UUID grande en la base de datos no es tan fácil como buscar un número pequeño.(En una nota tangencial, Gmail utiliza un número de seis dígitos como token de inicio de sesión único junto con el nombre de usuario).

Answer 1

discusión robusta de que en este SO hilo .

  

... el usuario se considera autenticado.

Probablemente debería leer autenticado pero con authoriziation limitado.

Por comentario: Un poco más seguro, ya que es un uso del tiempo y es difícil de adivinar. Así que si se ve comprometida la cookie, el atacante tiene que actuar con rapidez o el token será invalidado por el usuario legítimo loging en mientras que el identificador de usuario no puede cambiar durante mucho tiempo.

Answer 2

No soy experto en criptografía, pero siempre y cuando comprueba si hay intentos de fuerza bruta, que debería ser capaz de utilizar una clave corta (como 6 dígitos de Gmail). La vulnerabilidad real es la gente que escucha cuando un usuario se conecta (por ejemplo. SideJacking).

Answer 3

En los sitios que he creado anteriormente hice uso de un user_id y un hash salado de la contraseña del usuario.La razón principal por la que utilicé dos campos para autenticar a un usuario es porque me ahorró la molestia de agregar otra tabla (y así complicar el diseño de la base de datos). user_id Además, al estar almacenado en la cookie, podría hacer una búsqueda indexada en la tabla de usuarios y hacer coincidir de manera eficiente el hash salado con el usuario.Por supuesto, puede concatenar tanto el ID de usuario como el hash en un valor y simplemente almacenarlo en la cookie.

Si solo tiene una cadena aleatoria que no se puede adivinar, entonces tendría que tener una tabla separada para asociar la cadena aleatoria con una identificación de usuario y realizar otra búsqueda para ese usuario en particular.