¿Es irremplazable Google Authenticator?

Muchos servicios online te permiten (y en ocasiones te exigen) configurar la autenticación en dos pasos (2FA) con códigos de un solo uso. Google Authenticator es la aplicación de autenticación más conocida y utilizada para la generación de este tipo de códigos, ya que es compatible con casi todos los servicios.

De hecho, algunos incluso brindan un enlace a la aplicación cuando configuras la 2FA. Pero, ¿es Google Authenticator la única opción o deberías darle una oportunidad a alguna de las muchas alternativas, como Microsoft Authenticator o Twilio Authy?

Dado que estas alternativas existen y claramente tienen una base de usuarios, podrían parecer un reemplazo total de Google Authenticator. Pero ¿dónde está la trampa, si es que la hay? Si no tienes tiempo para leer hasta el final, aquí está la respuesta: no te preocupes, Google Authenticator es totalmente reemplazable. Pero si tienes curiosidad por descubrir todos los detalles, sigue leyendo…

Cómo funcionan los autenticadores

Comencemos por cómo funcionan las aplicaciones de autenticación en general. Se han creado varios estándares abiertos para una autenticación fuerte bajo el paraguas de la Iniciativa para la Autenticación Abierta (OATH por sus siglas en inglés) en los que se basan las aplicaciones, junto con algunas otras cosas, pero que no son el tema de esta publicación.

El HOTP de la OATH

Allá por el 2005, apareció el estándar de autenticación HOTP (contraseña de un solo uso basada en hash) de la OATH, que estableció los fundamentos de la autenticación utilizando códigos de un solo uso que se generan en sincronización desde el lado del cliente y del servidor.

La idea es que tanto la aplicación como el servicio que estés utilizando recuerden la misma clave secreta. A continuación, se aplica un algoritmo cifrado para generar un código único basado en esta clave y un valor de contador, que es básicamente un número que se incrementa cada vez que se genera un nuevo código único. Los datos para calcular este código son los mismos en ambos lados, por lo que, si todo sale según lo planeado, los dos códigos serán idénticos. Ya solo queda compararlos: si el código que has introducido coincide con el generado por el servidor, habrás conseguido la autenticación.

Después de cada solicitud de una sesión de generación, el valor del contador cambia para que el código sea único. Se utiliza un algoritmo que descarta los cálculos inversos y la extracción de la clave secreta de este código. Por tanto, aunque alguien intercepte este código único, no podrá calcular la clave secreta, reproducir el autenticador y generar sus propios códigos nuevos.

Pero el HOTP presenta dos problemas principales. En primer lugar, los valores del contador se desincronizan fácilmente. Por ejemplo, si solicitas al autenticador que genere un código, pero no lo usas al final, el autenticador del lado del cliente cambiará el valor del contador, mientras que en el lado del servicio permanecerá igual. Como resultado, los códigos generados ya no coincidirán. En segundo lugar, el código sigue siendo válido hasta que cambia el valor del contador, lo que puede conceder tiempo al atacante para que use el código interceptado si de alguna forma lograra distraer a la víctima.

El TOTP de la OATH

En el 2011, se presentó un nuevo estándar: el TOTP (contraseña de un solo uso basada en el tiempo) de la OATH, que utiliza la hora actual como contador. El principio sigue siendo el mismo: se utiliza una clave secreta conocida por ambas partes para calcular un código de un solo uso con el mismo algoritmo cifrado. Y, como el contador se basa en el sistema de tiempo Unix, el código cambia automáticamente a intervalos regulares, independientemente de si se usa o no.

Ahora cualquier dispositivo conectado a Internet sabe la hora exacta, por lo que no hay que preocuparse de que los códigos de un solo uso no estén sincronizados. Y como el intervalo en el que cambia el código es bastante corto (30 segundos por defecto), si se intercepta un código único, el atacante no tendrá mucho tiempo para usarlo.

Principios básicos de los autenticadores

Estos dos estándares son los que utilizan las aplicaciones de autenticación. El TOTP es el más común, por supuesto, simplemente porque es mejor en todos los sentidos, pero el HOTP todavía se puede encontrar en algunas implementaciones prehistóricas.

A la hora de crear un autenticador, el cliente y el servidor deben establecer un estándar común y compartir la clave; este es el mínimo absoluto requerido para que funcione la aplicación del autenticador. También se pueden establecer parámetros adicionales para crear tokens. Pero, ¿cómo llegan a un acuerdo la aplicación y el servicio? En la mayoría de los casos, mediante un código QR, lo que nos lleva a la siguiente pregunta: ¿cómo funcionan estos códigos?

Contenido del código QR del autenticador

Hasta donde yo sé, no se encuentra entre los estándares desarrollados por la OATH, sino más bien como una adhesión voluntaria al formato establecido por Google Authenticator. Pero, de cualquier forma, los sistemas de autenticación basados en aplicaciones tienden a usar códigos QR, en los que se codifica un enlace (estrictamente hablando, un identificador de recursos uniforme o URI) que contiene toda la información necesaria, por ejemplo:

otpauth://totp/Google:alanna@gmail.com?secret=IN2XE2LPOVZSYIDBOJSW4J3UEB4W65J7&issuer=Google&algorithm=SHA1&digits=6&period=30

Como puedes ver, se transfieren toda una serie de parámetros en el código QR, que indican lo siguiente:

• El propósito del URI: la creación de un token de autenticación (para eso es el otpauth del principio).
• El estándar de autenticación: HOTP o TOTP; en este caso TOTP.
• La etiqueta del token que se mostrará dentro de la aplicación; en nuestro ejemplo, Google.
• El nombre de usuario, en este caso, alanna@gmail.com.
• La clave secreta a partir de la cual se generan los códigos (en formato Base32): la parte más importante, una larga cadena de caracteres aleatorios.
• El nombre del servicio que ha creado el URI; en nuestro ejemplo, Google nuevamente.
• El algoritmo utilizado para generar los códigos, en este caso, SHA1.
• La longitud de los códigos generados: habitualmente seis caracteres, como se muestra aquí, pero se aceptan otras variantes.
• El periodo de tiempo después del cual caduca el código, generalmente 30 segundos, pero se pueden configurar otros intervalos.

Así se ve el código QR correspondiente:

Los códigos QR pueden pasar un montón de parámetros de autenticación

De hecho, como ya hemos mencionado anteriormente, muchos de estos parámetros se podrían omitir. La etiqueta del token y el nombre de usuario pueden ser arbitrarios, mientras que el nombre del servicio no se necesita para nada; esta información no tiene ningún impacto en la generación de código y está ahí principalmente por conveniencia. Otros parámetros tampoco son obligatorios. El autenticador utiliza el algoritmo de generación de código predeterminado (SHA1) y genera un código de seis dígitos con un periodo de actualización de 30 segundos, a menos que se codifique de otra forma en el URI.

Básicamente, el servicio y el autenticador solo necesitan establecer el estándar (HOTP o TOTP) y compartir la clave secreta. Por tanto, el siguiente código URI y QR generaría exactamente el mismo token de autenticación en términos funcionales que la pareja anterior:

otpauth://totp/Whenever:Wherever?secret=IN2XE2LPOVZSYIDBOJSW4J3UEB4W65J7

Muchos parámetros de código QR se pueden omitir o establecer en valores arbitrarios; lo principal es compartir la clave secreta y establecer el estándar: HOTP o TOTP

La conclusión es que la mayoría de los servicios que utilizan códigos generados por aplicaciones funcionan con códigos QR y lo cierto es que cualquier aplicación de autenticación puede leer esos códigos QR y convertirlos en tokens de autenticación, que, a su vez, generan los códigos de un solo uso. Por tanto, en lugar de Google Authenticator, puedes elegir la aplicación que más te guste entre las decenas de alternativas que encuentres.

La excepción que confirma la regla: servicios incompatibles con los autenticadores comunes

Por algún motivo que desconozco, no toda la industria TI sigue los estándares anteriores: hay quien prefiere crear los suyos propios. Estas son algunas empresas cuyos servicios y programas no son compatibles con aplicaciones de autenticación de terceros (incluido Google Authenticator).

• Apple. Los de Cupertino, California, tienen su propio sistema 2FA, que no utiliza ninguna aplicación de terceros. En su lugar, los códigos de un solo uso se generan mediante el sistema operativo simultáneamente en todos los dispositivos vinculados a una ID de Apple.
• Valve y Blizzard. Para la seguridad en Steam y Battle.net, los desarrolladores ofrecen una 2FA de creación propia: Steam Guard (integrada en las aplicaciones Steam para Android e iOS) y Battle.net Authenticator, respectivamente. Hasta donde yo sé, solo hay una aplicación de autenticación de terceros compatible con estos sistemas: WinAuth.
• Microsoft. Para la autenticación de la cuenta de Microsoft, debes instalar Microsoft Authenticator. Lo bueno es que no tienes que introducir ningún código: simplemente hay que confirmar el inicio de sesión tocando un botón de la aplicación. Además, Microsoft Authenticator también genera tokens de autenticación estándar, lo que lo convierte en una sólida alternativa a Google Authenticator. Por cierto, no necesitas una cuenta de Microsoft para usarlo.
• Adobe. El desarrollador de software de diseño gráfico ofrece su propia aplicación de 2FA, Adobe Account Access, que funciona con una lógica similar a Microsoft Authenticator: para acreditar el inicio de sesión en tu cuenta de Adobe solo tienes que tocar un botón, nada de enviar ningún código. En teoría, la aplicación también admite la creación de tokens para la autenticación en servicios de terceros. Sin embargo, para que funcione el acceso a la cuenta de Adobe, primero debes vincular la aplicación a tu cuenta de Adobe, lo cual, basándonos en las reseñas de App Store y Google Play, no es nada recomendable.

Entonces, ¿tengo que usar Google Authenticator?

No necesariamente. Todos los servicios que funcionan con Google Authenticator te permitirán configurar la autenticación en dos pasos utilizando cualquier otra aplicación similar. Es más, muchos de ellos presentan importantes ventajas frente a la aplicación de Google.

Por cierto, en esta publicación de nuestro blog puedes leer sobre los autenticadores más interesantes para los principales sistemas operativos: Android, iOS, Windows y macOS. Y por último, si has leído este texto al completo, algo nos dice que podrían interesarte andOTP si usas Android y OTP auth para iOS.