Requisitos de seguridad para el código / token de acceso único en la url

Question

Requisitos de seguridad para el código / token de acceso único en la url

#1 de Xander (3 votos)

3

Tengo una aplicación que enviará un recordatorio de SMS para el usuario que contiene una URL para iniciar sesión. Me gustaría evitar que el usuario escriba su nombre de usuario / contraseña e inicie sesión directamente. Para eso planeo usar un token de acceso y agregarlo a la url, por ejemplo:

www.mydomain.com?token=JFPIENBFIOHGDFGP3423432

Ahora que se trata de un SMS, no puedo ocultarlo detrás de la etiqueta "a". Así que me gustaría limitar la longitud del token tanto como sea posible para no asustar demasiado a los usuarios. Quizás también limite los símbolos solo a letras mayúsculas o algo así como a alguna otra forma de "embellecerlo".

Este es un enfoque adecuado para hacerlo y, en caso afirmativo, la seguridad debe aplicarse al token. Por lo que puedo ver, necesito esto:

Genere el token utilizando CSPRNG
Asegúrese de que sea suficiente entropía (mi aplicación no trata con información muy confidencial, por lo que supongo que 32 bits deberían ser suficientes, tal vez incluso menos, ya que el nombre de usuario / contraseña es solo el código de teléfono / pin digital)
Asegúrese de que el token sea de una sola vez o de corta duración (por ejemplo, 24 horas)

authentication url token sms

pregunta Ilya Chernomordik 15.04.2016 - 15:35

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication url token sms

explotando XSS en el selector jQuery ¿Es necesario desinfectar los datos que se pasan al hash_hmac en php?

score 3 · Accepted Answer

Eso es ciertamente un enfoque razonable. Como lo sugieres en tu publicación, lo limitaría a un token que es tanto con límite de tiempo como de uso único.

El tiempo que debe durar depende de la cantidad de entropía que crea que necesita introducir. Si fueras a embellecerlo usando solo mayúsculas y números, eso te dio un espacio de caracteres de 36 caracteres. Un token de 8 caracteres, elegido al azar de este espacio tendrá ~ 41.36 bits de entropía. Esto no es suficiente para una contraseña, pero podría ser potencialmente utilizable como un token. Sin embargo, dependiendo de cuántos se emitan y de cuántos intentos de validar su aplicación admita, esto podría no darle suficiente margen de seguridad. Un token de 12 caracteres, generado de manera completamente aleatoria, le ofrecería alrededor de 62 bits de entropía, y si quisiera ir a 16 caracteres, obtendría una fuerza de calidad de contraseña, con más de 82 bits de entropía.

Por lo tanto, definitivamente es un esquema viable con buena aleatoriedad, y la longitud de los tokens depende principalmente de la cantidad de margen de seguridad que desee. 8 caracteres son marginalmente factibles, 12 caracteres son probablemente un punto dulce bastante razonable, 16 si valora la seguridad más que la compacidad.