¿Por qué una ficha anti-falsificación necesita tantos bits?

Cuando comienzas a ver la probabilidad de éxito de un atacante en términos de tiempo en lugar del porcentaje, la recomendación de Google se vuelve mucho más razonable.

Tome la fórmula que se encuentra en enlace y descubrirá rápidamente que si desea mantener un atacante durante más de un año, necesitará más de 100 bits de entropía. 130 bits sigue siendo una locura, pero comienza a sonar un poco más razonable.

Gracias por indicarme la dirección correcta.

Su pregunta supone que no debe hacerse en el campo:

  

¿no podrías detectarlos y bloquearlos después de algunos intentos

?

Sí, en un buen ambiente de trabajo debería haber un sistema como este en el lugar que limite las fallas de diversos tipos. Esto es bueno, pero nunca debe ser su primera o única línea de defensa . Si su modelo de seguridad se basa en una capa adicional como esta por su seguridad teórica, está introduciendo un punto de falla innecesario y un posible vector de ataque.

Al mantener las matemáticas teóricas que deben realizarse fuera de su alcance, reduzca el riesgo que plantean las cosas que pueden estar (o finalmente terminar) fuera de su control, como una implementación del limitador de velocidad defectuoso o un trabajo de ataque interno.

Algunos otros factores que contribuyen a la necesidad de tanta entropía y por qué pueden sugerir 30 caracteres:

En primer lugar, esto es para proteger la acción de inicio de sesión del lado de la aplicación, que luego creará su propia sesión autenticada independiente de la de Google. Lo importante es que depende de la aplicación almacenar el token y decidir cuándo dejar de aceptarlo. Si se mantiene en una sesión o en una tabla de base de datos, entonces puede continuar aceptando ese token por tiempo indefinido y Google no puede garantizar que las aplicaciones no lo hagan, por lo que es más fácil para ellos recomendar más entropía.

En segundo lugar, proponen el uso de rand () en PHP en ese ejemplo . Para ser honesto, esto me sorprende, porque esa función no produce números aleatorios criptográficamente seguros. De hecho, según los documentos, es posible que solo produzca números entre 0 y 32767 en algunos sistemas. Esto me sugiere que 30 caracteres no son absolutamente necesarios para garantizar la seguridad, sino que es simplemente una buena idea.

En tercer lugar, creo que "30 caracteres" es principalmente relevante para el contexto de su ejemplo, donde están usando rand () bombeado en md5 (). Dado que md5 () produce valores hexadecimales, solo hay 16 valores posibles por carácter. Además, los compendios de md5 tienen una longitud de 32 caracteres, pero si comienzas a truncar eso, será mucho más fácil encontrar una colisión.

En resumen:

1. Es más fácil sugerir una alta entropía en lugar de formas complicadas para que los desarrolladores de aplicaciones aseguren que los valores caduquen de forma segura y confiable.
2. Si las personas toman su código de ejemplo (es decir, md5 (rand ())) y comienzan a truncar el valor de 32 bits, es posible que un atacante solo tenga que encontrar todos los prefijos de n caracteres distintos de hashes md5 de los valores 0 a 32767 , donde n es lo que truncas. Esto probablemente producirá un conjunto de valores que podrían ser forzados en bruto dentro de un tiempo factible.

Mirando el código de ejemplo en esa página:

• El código PHP usa rand() , que en algunos sistemas tiene a lo sumo 15 bits y puede ser incluso menor porque rand() no es necesariamente un buen RNG.
• El código de Python utiliza 32 caracteres de un alfabeto de 36 (mayúsculas y dígitos), lo que equivale a aprox. 165 bits suponiendo que random.choice es perfecto. Puede que no sea así, pero aún estamos viendo más de 15 bits.
• El uso de 130 bits en el código Java se encuentra entre los dos. No veo ninguna motivación obvia para ello: el número se emite en la base 32, así que para seguir el consejo de "unos 30 caracteres" esperaría 150 bits en lugar de 130. ¡Posiblemente podría ser un error tipográfico!
• Lo que es constante entre los diferentes ejemplos presentados es que la cadena tiene "unos 30 caracteres" siempre que se indique (26 para Java, 32 para los demás). Este consejo constante no le dice mucho sobre seguridad, solo sobre la conveniencia de almacenarlo, transmitirlo y recibirlo.

Dudo que exista una respuesta definitiva a esta pregunta, aparte de averiguar cómo el autor del fragmento de código de Java en particular eligió el número 130. Si esta cantidad de entropía fuera realmente importante para El consejo de seguridad de Google, luego los ejemplos de Python y PHP también lo usarían. Que no lo hacen.

El principio general en funcionamiento es que es barato generar, almacenar y transmitir estas cantidades de datos. Como tal, no hay beneficio, y algún riesgo, de usar solo lo que realmente necesita. El resultado es recomendar "exceso", aunque el código PHP se queda corto.

Usted pregunta por qué no 1024 bits: bueno, codificado en base 64 que requeriría 172 caracteres, y quizás podría argumentar que comienza a tener un enfoque significativo en el peso de una página web, aunque Sería un tramo. No tengo conocimiento de ninguna razón por la que no pueda usar tokens CSRF tan grandes, simplemente no vale la pena recomendar a las personas que los usen. Elegir entre 130 y 1024 es una cuestión (basada en la experiencia) de la diferencia entre un exceso excesivo cómodo y la gula. Elegir entre 130 y 64 podría ser más un caso de la diferencia entre un exceso excesivo cómodo y una sensación molesta de que quizás estés en un orden de magnitud o dos de no estar realmente seguro de la fuerza bruta después de todo.

Entonces, al dar consejos generales sobre este tipo de elección, es bastante razonable analizar una situación en el peor de los casos, duplicar la respuesta (o más) y luego verificar que el resultado se encuentre dentro de los límites razonables de recursos. Si es así, solo úsalo. Como tal, no esperaría que hubiera algo especial en los números 30 o 130. Tal vez hubiera sido instructivo que Google mostrara su funcionamiento.

El objetivo es hacer que un ataque de fuerza bruta no sea factible, no solo difícil.

Sí, podría hacer que el token sea lo suficientemente largo como para que coincida con alguna probabilidad elegida arbitrariamente bajo ciertas suposiciones. ¿Pero por qué harías eso? ¿Por qué apostar con la seguridad de sus usuarios y su aplicación? No es como si un montón de bits seudoaleatorios fuera un factor de costo enorme.

Algo así como 128 bits es una opción muy común cuando las personas simplemente no quieren preocuparse por los ataques de fuerza bruta (o colisiones accidentales). Puede encontrar este "número mágico" en muchas aplicaciones diferentes como claves simétricas, sales hash, UUID, etc.