O Google Authenticator é insubstituível?

Muitos serviços online permitem (e às vezes até obrigam) que você configure a autenticação de dois fatores (2FA) com códigos únicos. O Google Authenticator é o aplicativo autenticador mais conhecido e utilizado com essa funcionalidade de geração de códigos. Quase todos os serviços são compatíveis com ele e alguns até fornecem um link para o aplicativo quando você configura o 2FA. Mas o Google Authenticator é a única opção ou você deve dar uma chance às alternativas disponíveis, como Microsoft Authenticator ou Twilio Authy?

Como essas alternativas existem e têm uma base de usuários, você pode presumir que elas podem ser substituições completas para o Google Authenticator. Mas quais são as armadilhas, se é que existem? Para quem não tem tempo de ler até o fim, aqui vai a resposta de cara: não se preocupe, o Google Authenticator é mais do que substituível. Mas se você está curioso sobre o que é, por que e como – continue lendo…

Como funcionam os autenticadores

Vamos começar por como os aplicativos de autenticação geralmente funcionam. Vários padrões abertos para autorização de acesso forte foram criados sob a égide da iniciativa para Open Authentication (na sigla em inglês, OATH, e tradução livre para Autenticação Aberta). Aplicativos autenticadores são baseados nesses padrões, junto com algumas outras coisas, mas que não são o tópico desta publicação.

OATH HOTP

Em 2005, o padrão de autenticação HOTP (senha de uso único baseada em hash) de OATH apareceu. Isso estabeleceu os fundamentos da autenticação usando códigos únicos que são gerados de forma síncrona nos lados do cliente e do servidor.

A ideia é que tanto o aplicativo quanto o serviço que você está usando se lembrem da mesma chave secreta. Em seguida, um algoritmo criptográfico é aplicado para gerar um código único baseado nessa chave e em um valor de contador. Um contador é essencialmente um número que aumenta cada vez que um novo código único é gerado. Os dados para calcular este código são os mesmos em ambos os lados, portanto, se tudo correr conforme o planejado, os dois códigos serão idênticos. Resta compará-los: se o código digitado corresponder ao gerado pelo servidor, a autenticação foi bem-sucedida.

Após cada pedido de uma sessão de geração, o valor do contador muda para que o código seja utilizado apenas uma vez. É usado um algoritmo que exclui a realização de cálculos reversos e a extração da chave secreta desse código. Portanto, mesmo que alguém intercepte o código único, não será capaz de calcular a chave secreta, reproduzir o autenticador e gerar novos códigos próprios.

Existem dois problemas principais com o HOTP. Primeiro, os valores do contador ficam facilmente fora de sincronia. Por exemplo, se você solicitar ao autenticador para gerar um código, mas não o usar, o autenticador do lado do cliente altera o valor do contador, enquanto no lado do serviço ele permanece o mesmo. Consequentemente, os códigos gerados não serão mais correspondentes. Em segundo lugar, o código permanece válido até que o valor do contador mude – potencialmente dando ao invasor tempo para usar o código interceptado se de alguma forma conseguir distrair a vítima.

OATH TOTP

Em 2011, um novo padrão foi apresentado, o TOTP (senha única baseada em tempo) de OATH, que usa o horário atual como um contador. O princípio permanece o mesmo: uma chave secreta conhecida por ambas as partes é usada para calcular um código único com o mesmo algoritmo criptográfico. E como o contador é baseado na Era Unix, o código muda automaticamente em intervalos regulares, independentemente de ser usado ou não.

Qualquer dispositivo conectado à internet agora sabe a hora exata, portanto, não há necessidade de se preocupar com códigos de uso único fora de sincronia. E como o intervalo após o qual o código muda é bastante curto (30 segundos por padrão), se uma combinação destas for interceptada, o invasor não terá muito tempo para usá-la.

Princípios básicos de autenticadores

Esses dois padrões são usados por aplicativos autenticadores. TOTP é o mais comum, claro, simplesmente porque é melhor em todos os aspectos, mas HOTP ainda pode ser encontrado em algumas implementações mais antigas.

Ao criar um autenticador, o cliente e o servidor devem definir um padrão comum e compartilhar a chave — este é o requisito mínimo para que o aplicativo de autenticação funcione. Parâmetros adicionais também podem ser definidos para criar tokens. Como o aplicativo e o serviço chegam a um acordo? Na maioria dos casos, por meio de um QR code. E isso nos leva à próxima pergunta: como funcionam esses códigos?

Conteúdo de QR code do autenticador

Pelo que sei, isso não está entre os padrões desenvolvidos pelo OATH, mas sim uma adesão voluntária ao formato definido pelo Google Authenticator. Mas de qualquer forma, os sistemas de autenticação baseados em aplicativos tendem a usar QR codes, nos quais um link (estritamente falando, um identificador uniforme de recurso ou URI) contendo todas as informações necessárias. Aqui está um exemplo de como fica:

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

Como você pode ver, vários parâmetros são transferidos no QR code, indicando o seguinte:

• A finalidade do URI — criação de um token de autenticação (é para isso que serve o otpauth no início).
• O padrão do autenticador, HOTP ou TOTP; neste caso, TOTP.
• A identificação do token a ser exibido dentro do aplicativo — em nosso exemplo, Google.
• O usuário — nesse caso, alanna@gmail.com
• A chave secreta a partir da qual os códigos são gerados (no formato Base32) — a parte mais importante, uma longa sequência de caracteres aleatórios.
• O nome do serviço que criou o URI — em nosso exemplo, Google novamente.
• O algoritmo utilizado para gerar os códigos — neste caso, SHA1.
• O comprimento dos códigos gerados — geralmente seis caracteres conforme apresentado aqui, mas outras variantes são aceitáveis
• O período de tempo de expiração do código — geralmente 30 segundos, mas outros intervalos podem ser definidos.

Abaixo está disponível o QR correspondente:

QR codes podem revelar vários parâmetros de token de autenticação

De fato, como mencionamos acima, muitos desses parâmetros podem ser omitidos. A identificação do token e o usuário podem ser arbitrários, enquanto o nome do serviço não é necessário – essas informações não têm impacto na geração de código e estão lá basicamente por conveniência. Alguns outros parâmetros também não são obrigatórios. O autenticador usa o algoritmo padrão de dispersão seguro (SHA1) e gera um código de seis dígitos com um período de atualização de 30 segundos, a menos que seja codificado de outra forma no URI.

Essencialmente, o serviço e o autenticador precisam apenas definir o padrão (HOTP ou TOTP) e compartilhar a chave secreta. Assim, o URI e o QR code a seguir produziriam exatamente o mesmo token de autenticação do anterior em termos funcionais:

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

Muitos parâmetros do QR code podem ser omitidos ou definidos com valores arbitrários; o principal é compartilhar a chave secreta e definir um padrão (HOTP ou TOTP)

O ponto principal é que a maioria dos serviços que usam códigos gerados por aplicativos para autenticação operam com esses QR codes. Qualquer aplicativo autenticador, por sua vez, tem suporte para ler esses QR codes e convertê-los em tokens de autenticação, que, por sua vez, geram os códigos únicos. Assim, em vez do Google Authenticator, você pode escolher qualquer uma das dezenas de alternativas de sua preferência.

Algumas exceções: serviços incompatíveis com autenticadores mais comuns

Por alguma razão que está além da minha compreensão, nem todos na indústria de TI seguem os padrões acima: alguns preferem criar seus próprios. Aqui estão algumas empresas cujos serviços e programas não são compatíveis com aplicativos autenticadores de terceiros (incluindo o Google Authenticator).

• Apple. Os caras da Cupertino têm seu próprio sistema 2FA, que não usa nenhum aplicativo de terceiros. Em vez disso, os códigos únicos são gerados pelo sistema operacional simultaneamente em todos os dispositivos vinculados a um ID Apple.
• Valve e Blizzard. Para segurança no Steam e Battle.net, os desenvolvedores oferecem 2FA de sua própria criação: Steam Guard (acoplado nos aplicativos Steam para Android e iOS) e Battle.net Authenticator, respectivamente. Pelos meus conhecimentos, há apenas um aplicativo autenticador de terceiros que suporta esses sistemas: WinAuth.
• Microsoft. Para acessar a conta da Microsoft, deve-se instalar o Microsoft Authenticator. Por outro lado, não há necessidade de inserir nenhum código: basta confirmar o login clicando em um botão no aplicativo. Como bônus, o Microsoft Authenticator também gera tokens de autorização padrão, o que o torna uma alternativa sólida ao Google Authenticator. Importante ressaltar que uma conta da Microsoft não é necessária para usá-lo.
• Adobe. O desenvolvedor de software gráfico oferece seu próprio aplicativo para 2FA – Adobe Account Access – que funciona com lógica semelhante ao Microsoft Authenticator: o login na sua conta da Adobe é autenticado tocando em um botão, não enviando um código. Em teoria, o app também suporta a criação de tokens para autenticação em serviços de terceiros. No entanto, para que o Adobe Account Access funcione, você deve primeiro vincular o aplicativo à sua conta da Adobe, o que, com base nas análises da App Store e do Google Play, não é recomendado.

Então, devo usar o Google Authenticator?

Não necessariamente. Todos os serviços que funcionam com o Google Authenticator permitem que você configure a autenticação de dois fatores usando qualquer aplicativo similar. Além do mais, muitos deles têm vantagens significativas sobre a criação do Google.

Aliás, temos uma publicação sobre os autenticadores mais interessantes para cada sistema operacional popular — Android, iOS, Windows e macOS. E, finalmente, se você leu este texto na íntegra, então algo nos diz que você pode estar interessado em andOTP se utilizar Android e OTP auth para iOS.