Pregunta:
¿Por qué Google paraliza el módulo 2FA Google Authenticator PAM?
Akshay Kumar
2013-11-06 23:50:43 UTC
view on stackexchange narkive permalink

Si habilita 2FA para Google Apps, el secreto compartido es de 160 bits. El módulo PAM google_authenticator , por otro lado, parece usar 80 bits para el secreto compartido.

Según RFC 4226:

R6 - El algoritmo DEBE utilizar un secreto compartido fuerte. La longitud del secreto compartido DEBE ser de al menos 128 bits. Este documento
RECOMIENDA una longitud de secreto compartido de 160 bits.

Nota "DEBE" no "DEBE". Eso hace que Google Authenticator no sea compatible.

¿Cuál es la razón de ser de esto?

¡Gran pregunta! Abrí un problema en la página del proyecto del autenticador de Google sobre esto. https://code.google.com/p/google-authenticator/issues/detail?id=340&can=4
Solo puedo especular que alguien lo consideró lo suficientemente bueno como una compensación para obtener el beneficio de encajar el secreto dentro de un código QR más pequeño. Por supuesto, eso no responde a la pregunta de por qué uno se arriesgaría a sacrificar la seguridad por conveniencia.
Traté de ponerme en contacto con el equipo de sec de Google sobre esto hace unos años cuando estábamos buscando implementaciones de OTP y recibimos una respuesta 'por diseño'. No me importaría tanto, pero la página de Wikipedia parece reclamar perpetuamente el cumplimiento de RFC 4226 y / o 6238, cuando esto simplemente no es cierto.
Dos respuestas:
Thomas Pornin
2013-12-23 20:26:29 UTC
view on stackexchange narkive permalink

La confirmación inicial de este código ya incluye la longitud de la clave secreta de "80 bits". No se cambió después.

Ahora analicemos las cosas de manera más crítica. HOTP se especifica en RFC 4226. La autenticación utiliza un "secreto compartido", que es el valor del que estamos hablando. ¿Qué dice RFC 4226 al respecto? Básicamente, hay un requisito en la sección 4:

  R6: el algoritmo DEBE utilizar un secreto compartido fuerte. La longitud del secreto compartido DEBE ser de al menos 128 bits. Este documento RECOMIENDA una longitud de secreto compartido de 160 bits.  

Y luego la sección 7.5 explica en detalle varios métodos para generar el secreto compartido.

Ahora, el código google_authenticator genera un secreto compartido de 80 bits con / dev / urandom y luego procede a codificar este secreto con Base32: esta codificación asigna cada grupo de 5 bits a un carácter imprimible. Por tanto, la cadena resultante consta de 16 caracteres, que se escriben "tal cual" en un archivo, con codificación ASCII, lo que significa que en el archivo el secreto compartido tiene una longitud ... 16 bytes , es decir, 128 bits. Por lo tanto, es posible que la confusión inicial provenga de eso: lo que se almacena tiene una longitud que se puede ver, de alguna manera, para cumplir con el requisito R6 de RFC 4226.

Por supuesto, el RFC habla sobre el "secreto compartido" llamándolo " K " en la sección 5.1 y luego procede a usarlo como clave para HMAC ( sección 5.3, paso 1). Con el secreto compartido generado con la herramienta de línea de comandos en google_authenticator , lo que ingresa a HMAC es realmente una secuencia de 80 bits, no 128 bits, aunque estos 80 bits estén codificados como 128 bits cuando se almacenan (pero se decodifican de nuevo a 80 bits cuando se usan). Por lo tanto, este secreto de 80 bits no puede realmente, de manera legalista, cumplir con el requisito R6 de RFC 4226. Sin embargo, la confusión sobre "longitud" (después o antes de la codificación) puede explicar esta función de google_authenticator .

Tenga en cuenta, sin embargo, que esto es solo para la herramienta de línea de comandos que se puede usar para generar el secreto como paso inicial. El resto del código admite valores secretos más largos.

(Otra teoría es que el autor quería probar su código y, en particular, probar la situación en la que no hay un código QR. En ese caso, el usuario debe escribir el código, y un secreto de 80 bits es más fácil de escribir que un secreto de 128 o 160 bits. Posiblemente, el autor utilizó primero un secreto breve para facilitar el desarrollo y, posteriormente, después me olvidé de volver a ajustarlo a su longitud nominal. Este tipo de percance ocurre con bastante frecuencia.)


¿Es crítico? Con mi sombrero de criptógrafo, debo responder : No. Una clave secreta de 80 bits sigue siendo bastante fuerte contra la fuerza bruta, porque incluso con una gran cantidad de GPU, las evaluaciones de 279 de HMAC / SHA-1 aún requerirán bastante tiempo (con una clave de 80 bits, el costo promedio de la fuerza bruta es el de probar la mitad de las claves posibles, es decir, 279 evaluaciones). De hecho, HMAC / SHA-1 se considera "criptográficamente fuerte", lo que significa que el ataque más conocido es la fuerza bruta sobre la clave. Pongamos cifras:

HMAC / SHA-1 usa dos invocaciones SHA-1. Por lo tanto, el costo del ataque es, en promedio, el costo que implica llamar a SHA-1 280 veces. Esta página muestra puntos de referencia a 2,5 billones de llamadas SHA-1 por segundo para una buena GPU. Si está montando una granja de craqueo, generalmente usará una GPU de "rango medio", no un modelo de primera, porque obtendrá más potencia por dólar de esa manera. Supongamos que usa una GPU de $ 100 que puede hacer 231 SHA-1 por segundo (eso es un poco más de 2 mil millones). Con un presupuesto de mil millones de dólares , puede tener diez millones de GPU, y ejecutarán el ataque en un promedio de ... 652 días.

Por supuesto, 10 millones de GPU ocupan bastante espacio y, lo que es más importante, utilizan una cantidad sustancial de energía. Si suponemos que cada GPU puede funcionar en 50W (una cifra bastante optimista), entonces cada ejecución de ataque necesitará un poco menos de 8 TW.h (teravatios-hora). Vivo en Canadá, provincia de Québec, donde se sabe que la electricidad es muy barata debido a las enormes represas y las importantes subvenciones gubernamentales, lo que da como resultado un precio de aproximadamente 0,05 dólares por kW.h (consulte los precios). . Con este precio, cada ejecución de ataque costará alrededor de 400 millones de dólares solo en electricidad. Esto no incluye los precios de refrigeración, porque toda esta energía se convertirá en calor y tendrá que ser disipada (hasta cierto punto, un invierno canadiense puede ayudar). Además, tenga en cuenta que todas las GPU consumirán colectivamente 500 MW, una cantidad no discreta (eso es aproximadamente la mitad de una planta de energía nuclear ...).

Esto equivale a lo siguiente: en la práctica, una clave de 80 bits es lo suficientemente fuerte . Me pondría nervioso si una clave de 80 bits protegiera el código de lanzamiento de misiles nucleares; sin embargo, si la disuasión estratégica estuviera protegida por 2FA de Google, también estaría bastante nervioso por ... otras razones.

Entonces podemos decir que si bien este secreto de 80 bits no cumple con los requisitos y académicamente es "un poco corto", todavía es bastante fuerte y no exige acciones inmediatas y drásticas. Sería genial si el código fuera arreglado; el mundo no dejará de girar si no es así.

No es solo HMAC / SHA-1, sino un módulo 10 ^ 6 del hash real. El escenario de ataque para un token HOTP que genera códigos de 6 dígitos es un atacante que usa códigos previamente conocidos para llegar al secreto compartido, lo que, considerando este truncamiento, dificulta aún más el trabajo del atacante debido a una mayor probabilidad de colisiones.
"* El resto del código admite valores secretos más largos. *" Para ser explícito: no existe tal límite en el módulo * PAM * en sí, aceptará cualquier (> 1 byte y estará sujeto a un tamaño de archivo máximo de verificación de cordura de 64 kB) tamaño secreto compartido. Es solo la herramienta de generación de secretos locales la que tiene este límite (trivialmente modificable). FWIW, la fuente más reciente (v2.21) para la aplicación de Android tiene un límite * inferior * de 80 bits (`MIN_KEY_BYTES`).
user10211
2013-12-18 16:26:58 UTC
view on stackexchange narkive permalink

Como mencioné en mi comentario, ya abrí un problema en el repositorio de Google Authenticator. Sin embargo, no ha habido respuestas oficiales de los desarrolladores al respecto. Parece que la actividad en el repositorio está bastante estancada.

Aunque probablemente no haya una buena explicación de por qué Google optó por 80 bits en lugar de los 160 bits recomendados según el RFC, hay una solución bastante fácil si este es un tema importante.

Hasta donde yo sé, el tamaño del secreto se define únicamente en libpam / google-authenticator.c en la línea 39.

  #define SECRET_BITS 80 // Debe ser divisible por ocho  

Cambiar el valor de 80 a 160 funciona y no rompe nada por lo que puedo decir. Esto podría ser viable si realmente desea que el módulo PAM cumpla con el RFC.

Adnan, estás siendo demasiado duro aquí. Tal como está actualmente su pregunta, solo puede ser respondida por el empleado de Google que estuvo involucrado en esto. En cuanto a la recompensa ... 50 rep no complacerá a ningún representante ...
Las reglas de @Lekensteyn son reglas. Solo porque Terry es nuestro amigo y nos agrada, no significa que miremos para otro lado cuando él da una no respuesta como respuesta. Si la pregunta solo puede ser respondida por un empleado de Google, entonces probablemente no sea mejor hacerla aquí y debería cerrarse y no responder sin respuesta.


Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...