¿Cómo permanecen sincronizados los generadores de código en las aplicaciones de teléfonos inteligentes con el código del servidor para la autenticación de dos factores?

El proceso está bien documentado en las normas pertinentes doc. La autenticación de 2 factores implementada en Google Authenticator y aplicaciones similares, y utilizada por Google, LastPass, Evernote, Dropbox y otros se llama “OATH TOTP” y está documentada en IETF RFC 6238 en TOTP: Contraseña de un solo uso basada en el tiempo Algoritmo

El resumen TL; DR es que el código se calcula únicamente en función de la hora actual y una semilla secreta compartida. La mayoría de los dispositivos ahora tienen un conocimiento muy preciso de la hora actual, ya que pueden obtener la hora actual de la red de teléfonos celulares, del GPS u otro servicio GNSS y del Protocolo de hora de red (NTP). Pero los tokens de hardware de bajo costo y bajo consumo no pueden obtener el tiempo de ninguna de esas maneras, y probablemente no tengan un reloj altamente preciso a bordo, y por lo tanto se desviarán.

Entonces, lo que hace el servidor TOTP es calcular el código correcto para “verdadero ahora”, y también el código para un par de pasos hacia adelante y hacia atrás en el tiempo. Abrir esa ventana de tiempo demasiado es imprudente. La mayoría de los servidores permitirán 2 pasos, y funcionan en pasos de 30 segundos, por lo tanto, su reloj local puede estar sincronizado hasta un minuto.

Opcionalmente, el servidor TOTP puede decidir darse cuenta de que siempre está un paso temprano o siempre un paso tarde, y lo recordará y se ajustará para usted en consecuencia.

Además, opcionalmente, se le puede pedir al servidor TOTP que “vuelva a sincronizar”. Cuando se hace esto, el servidor TOTP le pedirá 2 códigos consecutivos, y luego buscará el desplazamiento de tiempo de su secreto compartido que genera esos dos códigos en fila, y de eso sabrá cuánto se ha desviado su reloj local. Dado que los códigos son típicamente de 6 dígitos decimales de largo, y el intervalo de paso es típicamente de 30 segundos, esa combinación de dos códigos, en promedio, aparecerá solo una vez cada 475321 años. El servidor puede estar bastante seguro de que al conocer esos dos códigos consecutivos conoce su compensación de tiempo.

Casi nunca necesitará volver a sincronizar un autentificador de token basado en un teléfono inteligente, pero espere tener que hacerlo de vez en cuando cuando use un pequeño autentificador de token de hardware independiente.

Por cierto, esto es parte de por qué el robo de los datos semilla para los tokens RSA SecurID (que usa un algoritmo patentado que es similar y no más fuerte que OATH TOTP) fue tan devastador, pero de eso EMC no hablará. Un atacante que tiene la base de datos inicial pero no conoce su ID de token, solo controlará su tráfico hasta que lo vea iniciar sesión dos veces, o puede interrumpir o falsificar su tráfico para que inicie sesión dos veces seguidas, tal vez pensando primero El intento no tuvo éxito. Con esos dos códigos de tu token, puede avanzar cada semilla hacia adelante a tiempo sobre “Nowish”, y luego buscar y encontrar la identificación y el secreto de tu token. Y al saber qué semilla de token se le asigna, puede generar el código de su token en cualquier momento en el futuro, y así suplantar su token e iniciar sesión en cualquier sitio que esté “protegido” por él.

Las aplicaciones 2FA (como Google Authenticator) no requieren conexión a Internet o de red. El único requisito es la sincronización horaria (para el algoritmo TOTP). El servidor y la aplicación conocen la misma clave secreta (un código alfanumérico único de 16 o 32 caracteres) y, en función de ello, la aplicación genera OTP y el servidor comprueba si son correctos.