Cuando usa un "token de autenticación", la simple presentación de ese token por parte del cliente otorga acceso (siempre que el servidor lo considere válido). Si almacena los tokens "tal como están" en la base de datos de su servidor, entonces un atacante que podría echar un vistazo a su base de datos aprenderá inmediatamente todos los tokens, lo que le permitirá enviar solicitudes en nombre de todos los usuarios para los que todavía existe un token válido. en la base de datos Esto es malo. Por lo tanto, la recomendación de almacenar solo un hash del token de autenticación.
El consejo sobre bcrypt para tokens de autenticación está mal dirigido. Bcrypt, como todas las funciones dedicadas a hashing de contraseña , está destinado para ser utilizado para contraseñas . Las contraseñas son débiles; son vulnerables a los ataques de diccionario. Para hacer frente a su debilidad inherente, la función de hashing de contraseñas debe incluirse (para evitar ataques paralelos y tablas precomputadas) y también debe ser muy lenta (a través de un gran número de iteraciones internas). Esto hace que las funciones de hashing de contraseñas sean caras . Por lo tanto, no desea utilizar una función de hash de contraseña a menos que la necesite, por ejemplo. para codificar una contraseña.
Un token de autenticación no es una contraseña; es un valor aleatorio que fue generado y recordado por una computadora, sin ningún cerebro humano involucrado en el proceso. Como tal, si generó el token correctamente (al menos 128 bits, obtenido de un PRNG criptográficamente seguro ), entonces hay sin necesidad de sales o iteraciones; simplemente use una función hash simple (incluso MD5 estaría bien allí). Esto será más eficiente.
En cuanto al uso de un token de autenticación aleatorio en lugar de una contraseña de inicio de sesión para cada solicitud, existen dos razones principales para ello:
Rendimiento: como se explicó anteriormente, un token de autenticación puede verificarse de manera segura con un simple hash, que será mucho más eficiente que una llamada bcrypt pesada. Desea mantener sus preciados ciclos de CPU para cuando sean realmente útiles, en particular cuando aplique bcrypt a una contraseña real administrada por humanos.
Almacenamiento del lado del cliente: el token de autenticación se almacenará en el cliente como un valor de cookie. Si el inicio de sesión y la contraseña se envían con cada solicitud, se almacenan como una cookie en el cliente. La gente se pone nerviosa cuando sus contraseñas se escriben en archivos, y tal almacenamiento no es equivalente (desde un punto de vista de seguridad) al almacenamiento de un token de autenticación, porque los usuarios humanos tienen la (mala) costumbre de reutilizar sus contraseñas para múltiples sistemas, mientras que los tokens de autenticación son inherentemente específicos del servidor.