¿Cómo funciona Google Authenticator?

Google Authenticator es compatible con HOTP y TOTP algoritmos para generar contraseñas de un solo uso.

Con HOTP, el servidor y el cliente comparten un valor secreto y un contador, que se utilizan para calcular una contraseña única de forma independiente en ambos lados. Siempre que se genera y utiliza una contraseña, el contador se incrementa en ambos lados, lo que permite que el servidor y el cliente permanezcan sincronizados.

TOTP esencialmente utiliza el mismo algoritmo que HOTP con una diferencia importante. El contador utilizado en TOTP se reemplaza por la hora actual. El cliente ys siempre permanecen sincronizados siempre que los tiempos del sistema sigan siendo los mismos. Esto se puede hacer usando el protocolo de tiempo de red .

La clave secreta (así como el contador en el caso de HOTP) tiene para ser comunicado tanto al servidor como al cliente en algún momento. En el caso de Google Authenticator, esto se hace en forma de un URI codificado con QRCode. Consulte: KeyUriFormat para obtener más información.

Comentarios

• En el caso de HOTP, ¿cómo sabe Google Authenticator que he " utilizado " la contraseña sin sincronizarme con el servidor? Lo que hace Google Authenticator es que continúa mostrando diferentes claves y puedo usar cualquiera de ellas sin enviar comentarios a mi móvil.
• @MarioAwad La respuesta se puede encontrar en el HOTP RFC, sección 7.4 . ietf.org/rfc/rfc4226.txt
• Gracias por la respuesta bien definida y el seguimiento. Resumen rápido de la sección 7.4: La resincronización del contador de vez en cuando y una ventana de anticipación para el contador es lo que hace que las cosas funcionen sin necesidad de una sincronización instantánea.
• Como señaló @TerryChia, la clave secreta está en el código QR. Sea consciente de la sensibilidad del QRCode / Information. Escribí una publicación de blog hace un tiempo netknights.it/en/the-problem-with-the-google-authenticator

En funcionamiento:

Authenticator implementa el algoritmo de contraseña única basada en el tiempo (TOTP). Tiene los siguientes ingredientes:

• Un secreto compartido (una secuencia de bytes)

• Una entrada derivada de la hora actual

• Una función de firma

Secreto compartido: El secreto compartido es lo que necesita obtener para configurar la cuenta en su teléfono . O toma una foto de un código QR con su teléfono o puede ingresar el secreto manualmente.

Entrada (hora actual): El valor de tiempo de entrada que simplemente obtendrá de su teléfono, no se requiere más interacción con el servidor una vez que haya obtenido el secreto. Sin embargo, es importante que la hora de su teléfono sea precisa como el servidor Básicamente, repetirá lo que sucede en su teléfono usando la hora actual tal como la conoce el servidor.

Función de firma: La función de firma utilizada es HMAC-SHA1. HMAC significa código de autenticación de mensajes basado en Hash y es un algoritmo que utiliza una función hash unidireccional segura (SHA1 en este caso) para firmar un valor. El uso de un HMAC nos permite verificar la autenticidad: solo las personas que conocen el secreto pueden generar la misma salida para la misma entrada (la hora actual).

Algoritmo OTP :

Pseudo código:

original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret))) input = CURRENT_UNIX_TIME() / 30 // sets a constant value for 30 seconds hmac = SHA1(secret + SHA1(secret + input)) //apply hashing offset = hmac[len(hmac)-1] & 0x0F //Last nibble four_bytes = hmac[offset : offset+4] //takes a subset of 4 bytes from 20 bytes large_integer = INT(four_bytes) //Covert four bytes to integer small_integer = large_integer % 1,000,00 //gives 6 digit code 

Referencia: https://garbagecollected.org/2014/09/14/how-google-authenticator-works/

Consulte también este proyecto de github para la implementación de GO: https://github.com/robbiev/two-factor-auth/blob/master/main.go

Comentarios

• ¿No ' t el autenticador de Google también es compatible con HOTP?

Funcionará en una semilla en función del tiempo, por lo que es similar a la forma en que Los llaveros RSA funcionan. es decir, tampoco requieren ninguna conectividad.

Acabo de echar un vistazo y esto se responde aquí: https://stackoverflow.com/questions/8340495/how-rsa-tokens-works

Si uno strace es el sshd demonio, se puede ver cómo el servidor «sabe» acerca de la clave secreta, ya que lee el archivo de configuración del usuario:

#strace -f -v -e open /usr/sbin/sshd -p 2222 -dddd -f /etc/ssh/sshd_config 2>&1 | grep -i goog > > [pid 2105] open("/home/myuser/.google_authenticator", O_RDONLY) = 4 > > [pid 2105] open("/home/myuser/.google_authenticator~", > > O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_NOFOLLOW, 0400debug3: > > mm_sshpam_respond: pam_respond returned 1 [preauth] 

El teléfono móvil ya lo sabe; lo escaneó a través de QR o lo escribió.

Comentarios

• Este es un buen ejemplo de cómo demostrar que los tokens son no se envía al servidor, pero no ' realmente explica cómo funciona (que es lo que pidió OP)
• No ' t per se, pero aborda la falta de conectividad.