¿Google Authenticator es irremplazable?

Varios servicios online te permiten (y te obligan en ocasiones a) configurar la autenticación en dos pasos (2FA) con códigos de un solo uso. La aplicación de autenticación más conocida y usada para generar este tipo de códigos es Google Authenticator, ya que es compatible con casi todos los servicios, de hecho, algunos hasta proporcionan un enlace a la aplicación cuando configuras la 2FA. Pero ¿Google Authenticator es la única opción o deberías darle una oportunidad a alguna de las diversas alternativas, como Microsoft Authenticator o Twilio Authy?

Ya que existen estas alternativas y es claro que tienen una base de usuarios, podrían parecer un total reemplazo de Google Authenticator. Pero ¿será que hay una trampa escondida? Si no tienes tiempo de leer todo, la respuesta está aquí: no te preocupes, Google Authenticator es completamente reemplazable. Pero si te da curiosidad descubrir todos los detalles, sigue leyendo…

Cómo funcionan los autenticadores

Empecemos por cómo funcionan en general estas aplicaciones de autenticación. 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 cuales las aplicaciones se basan, junto con algunas otras cosas, pero que no incumben para esta publicación.

El HOTP de la OATH

Corría el 2005 cuando el estándar de autenticación HOTP (contraseña de un solo uso basada en hash) de la OATH apareció, estableciendo los fundamentos de la autenticación mediante códigos de un solo uso que se generan en sincronización por parte del cliente y del servidor.

La idea es que tanto la app como el servicio que uses 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 básicamente es un número que crece cada vez que se genera un nuevo código único. Los datos para calcular este código son los mismos de ambas partes, por lo que, de acuerdo con lo planeado, ambos códigos serán idénticos. Ya solo queda compararlos: si el código que introduces coincide con el generado por el servidor, la autenticación se habrá logrado.

Tras cada solicitud de una sesión de generación, el valor del contador cambia para que el código sea único. Se usa un algoritmo que descarta cálculos inversos y la extracción de la clave secreta de este código. Por ende, incluso si alguien intercepta este código único, no podrá calcular la clave secreta, reproducir el autenticador y generar sus propios códigos nuevos.

Pero hay dos problemas principales con el HOTP. Primero, los valores del contador se desincronizan fácilmente. Por ejemplo, si solicitas al autenticador que genere un código, pero al final no lo usas, el autenticador del lado del cliente cambiará el valor del contador, mientras que en el lado del servicio seguirá siendo el mismo. Entonces, los códigos generados ya no empatarán. Segundo, el código sigue siendo válido hasta que cambia el valor del contador, lo que puede dar tiempo a un atacante para usar el código interceptado si es que lograra distraer a la víctima.

El TOTP de la OATH

En 2011, se presentó un nuevo estándar: el TOTP (contraseña de un solo uso basada en el tiempo) de la OATH, que como contador utiliza la hora actual. El principio es el mismo: una clave secreta conocida por ambas partes es usada 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 en intervalos regulares, Sin importar si se usa o no.

Cualquier dispositivo que se conecte a Internet tiene 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 tendrá poco tiempo para usarlo.

Los autenticadores y sus principios básicos

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

Al momento de crear un autenticador, el cliente y el servidor deben establecer un estándar común y compartir la clave; esto es lo mínimo que se requiere para que la aplicación del autenticador funcione. 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 cual nos lleva a la siguiente pregunta: ¿cómo funcionan dichos códigos?

Contenido del código QR del autenticador

Hasta donde sé, no se está entre los estándares desarrollados por la OATH, sino más bien como una adhesión voluntaria al formato establecido por Google Authenticator. Pero, como sea, los sistemas de autenticación basados en aplicaciones suelen usar códigos QR, en los cuales 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; TOTP en este caso.
• 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 mediante 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, una vez más, Google.
• El algoritmo usado para generar los códigos, en este caso, SHA1.
• La longitud de los códigos generados: usualmente son 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 revelar toda una serie de parámetros de token de autenticación

De hecho, como ya dijimos, podrían omitirse varios de estos parámetros. La etiqueta del token y el nombre de usuario pueden ser arbitrarios, mientras que el nombre del servicio no nada necesario; esta información no tiene impacto alguno 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 deben establecer el estándar (HOTP o TOTP) y compartir la clave secreta. Por ende, 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 pueden ser omitidos o tener 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 verdad es que cualquier aplicación de autenticación puede leer dichos códigos QR y convertirlos en tokens de autenticación, que, a su vez, generan los códigos de un solo uso. Por ende, en lugar de Google Authenticator, puedes utilizar la aplicación que más te guste de entre las decenas de alternativas que existen.

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

Por algún motivo desconocido, no toda la industria TI sigue estos estándares: hay quien prefiere crear los propios. Aquí 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 son generados mediante el sistema operativo en todos los dispositivos vinculados a una ID de Apple al mismo tiempo.
• Valve y Blizzard. Para la seguridad en Steam y Battle.net, los desarrolladores ofrecen una 2FA de propia: Steam Guard (integrada en las aplicaciones Steam para Android e iOS) y Battle.net Authenticator, respectivamente. Hasta donde 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 debes introducir código alguno: solo 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 alternativa sólida ante Google Authenticator. Por cierto, no es necesaria 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 debes tocar un botón, no hay que enviar código alguno. Teóricamente, la app admite también la creación de tokens para la autenticación en servicios de terceros. No obstante, 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, ¿debo usar Google Authenticator?

En realidad, no. Todos los servicios que funcionan con Google Authenticator te permitirán configurar la autenticación en dos pasos utilizando cualquier aplicación parecida. Es más, muchos de ellos presentan varias ventajas ante 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. Por último, si leíste este texto por completo, algo nos dice que podrían interesarte andOTP si usas Android y OTP auth para iOS.