¿Por qué los tokens de acceso generados para las API son mucho más largos que las contraseñas?

Hay varias razones para eso.

Una razón es que las contraseñas memorables son demasiado cortas para el nivel de seguridad esperado. Se utilizan varios métodos para mitigar este problema, pero sería problemático aplicarlos para acceder a los tokens:

• Algunos servicios requieren un segundo factor de autenticación . Los tokens de acceso están destinados a ser utilizados sin la intervención del usuario, por lo que la mayoría de las otras formas de autenticación están fuera (no serían aplicables, por ejemplo, la biométrica, o solo darían como resultado un segundo token de acceso).
• Los servicios en línea protegen contra los ataques de fuerza bruta al imponer un retraso entre los intentos de autenticación. Esto es problemático porque puede bloquear al usuario legítimo y es una carga de implementación adicional.
• El almacenamiento de contraseñas utiliza hashes lentos . Esto cuesta mucho tiempo de CPU. Si un token de acceso lo suficientemente largo debe mantenerse en secreto y almacenarse en forma de hash, no es necesario tomar precauciones especiales. Del mismo modo, si una clave se deriva de un token de acceso.

Otra razón es que la longitud de los tokens de acceso normalmente la decide el autor de un protocolo o biblioteca, no el autor de los servicios que los utilizan. El costo de alargar un token de acceso es generalmente marginal. Por lo tanto, la longitud se establece en algo que proporciona el nivel de seguridad más alto que cualquiera requiere. Estás comparando la longitud del token de acceso con la longitud de contraseña mínima , pero una comparación más adecuada sería con la longitud máxima de la contraseña.

Algunos servicios usan tokens de acceso independientemente de las cuentas (es decir, como cookies de sesión en lugar de como un parámetro de autenticación que se combina con un parámetro de identificación). También puede haber muchos tokens de acceso para una sola cuenta con diferentes privilegios. Por lo tanto, el token de acceso debe tener más entropía para mantener la probabilidad de colisiones infinitesimal.

En pocas palabras, el token no está diseñado para ser memorizado, por lo que puede ser tan largo como lo deseen. Una contraseña está limitada en longitud a lo que una persona puede recordar de manera prácticamente confiable después de un corto período de memorización. Esto lo limita a 7-10 caracteres para la mayoría de las personas. El token está diseñado para ser copiado / pegado, solo una vez incluso (ya que es específico de la aplicación), por lo tanto, no existe ninguna penalización por ser largo, y la gran longitud permite que sea seguro y único (es decir, el token puede tener suficiente incrustado). información para vincular a una cuenta específica).

Supongo que una pregunta más precisa sería, ¿por qué las contraseñas no son más largas ;-)

Si necesita almacenar relativamente contraseñas cortas , hay una serie de precauciones que debe tomar:

1. Salar con una sal única lo suficientemente larga como para evitar ataques a la mesa del arco iris.
2. Estiramiento de las teclas, por lo que el cálculo necesita algo de tiempo, para dificultar el forzamiento brutal.

En el otro lado, si el token es lo suficientemente largo , puede almacenar solo un SHA-256 sin inconvenientes en la seguridad. Estas son las ventajas:

1. No hay necesidad de salazón. A diferencia de las contraseñas con sal, los hash de token se pueden buscar en una base de datos. Por lo tanto, si tiene un token, puede volver a marcarlo y consultar con una consulta SQL si el token es válido.
2. El cálculo es rápido y ligero en la CPU del servidor. Si bien necesitábamos una gran cantidad de energía de la CPU para las contraseñas de hash debido al estiramiento de las claves, el hash de la ficha es muy rápido.

En el caso de una aplicación que escribí recientemente, el token de acceso es una cadena cifrada simétricamente del formulario

nonce=123456789;userid=123;username=bob;login_expires=12345679;...

La cadena encriptada es la cookie y es bastante larga. Descifrarlo es rápido, y suponiendo que nadie robó la clave secreta del servidor, los datos son auténticos.

Los tokens se utilizan para acceder a las API mediante programación; las contraseñas son utilizadas por los usuarios que las escriben.

El forzado de contraseñas brutas se evita mediante estrategias como dividir la escritura del nombre de usuario y la contraseña en dos páginas diferentes, agregar campos de entrada secundarios como captchas y forzar un período de espera (o deshabilitar el ID de usuario) después de algunos intentos fallidos .

Mientras tanto, los tokens se utilizan sin todos estos mecanismos y deben soportar los intentos de acceso a la API que se ejecutan a toda velocidad. Por lo tanto, para evitar que los forzados brutos tengan que ser mucho más largos.

En otras palabras, una contraseña corta y estrategias defensivas le dan la misma seguridad que un token largo.