Como funcionam os códigos TOTP
Um código TOTP é um número de 6 dígitos que uma aplicação de autenticação e um servidor calculam cada um por si, a partir das mesmas duas entradas: uma chave secreta partilhada e a hora atual, dividida em janelas de 30 segundos. O código em si nunca é transmitido durante a configuração e não transporta qualquer informação sobre o segredo, e mesmo assim ambas as partes chegam aos mesmos dígitos — porque TOTP não é magia nem aleatoriedade: é um algoritmo publicado (RFC 6238) aplicado às mesmas entradas. Este artigo percorre o cálculo do princípio ao fim, explica por que um «código errado» é quase sempre um problema de relógio e revê as regras de manuseamento que decidem se o seu segundo fator continua a ser um segundo fator. Pode executar cada passo você mesmo no gerador TOTP, que calcula os códigos localmente no seu navegador.
Duas entradas, um código: o segredo e o relógio
Quando ativa a autenticação de dois fatores, o serviço gera um segredo aleatório — tipicamente 20 bytes, mostrados como uma cadeia de caracteres Base32 e, por conveniência, codificados num código QR. Esse segredo é guardado em exatamente dois sítios: a base de dados do serviço e o seu autenticador. A partir desse momento, iniciar sessão é um cálculo sincronizado. Ambas as partes pegam na hora Unix atual, dividem-na pelo passo de tempo (30 segundos em quase todos os serviços) e alimentam o contador resultante, juntamente com o segredo, a uma função hash. Quem apresentar a saída correspondente é tratado como detentor do segredo.
A elegância do desenho está no que ele deixa de fora. Não há desafio para enviar, nem código para entregar, nem ida e volta pela rede, nem nada por início de sessão que um atacante possa intercetar: a propriedade de «uso único» vem do relógio, porque o contador muda a cada 30 segundos e as saídas antigas deixam de valer. Também significa que o sistema tem exatamente duas coisas que podem correr mal — o segredo e a hora. Quase todas as falhas de TOTP, e todos os roubos de TOTP, remontam a uma dessas duas.
O cálculo, passo a passo
O contador é primeiro escrito como um inteiro big-endian de 8 bytes — uma codificação de largura fixa em que ambas as partes concordam. Essa mensagem passa então por HMAC com o segredo como chave, usando o hash acordado: SHA-1 por defeito, com SHA-256 e SHA-512 definidos para os serviços que os escolherem. HMAC é uma construção com chave, não um hash simples: fazer hash apenas do contador permitiria a qualquer pessoa com o algoritmo reproduzir os códigos, enquanto as saídas de HMAC são infalsificáveis sem o segredo e não podem ser invertidas para o recuperar.
Um resumo tem 20 bytes ou mais; um campo de início de sessão quer 6 dígitos. A ponte é o corte dinâmico: o último meio byte do resumo seleciona um deslocamento, leem-se quatro bytes a partir desse deslocamento com o bit superior mascarado (para evitar ambiguidade de sinal) e o número de 31 bits resultante é reduzido módulo 10^dígitos — um milhão para os seis dígitos padrão —, preenchido com zeros à esquerda. Esse é o código que escreve. A janela seguinte recalcula do zero; não há cadeia a ligar um código ao seguinte, e é por isso que um código fotografado não vale nada trinta segundos depois.
Quando o código é rejeitado: geralmente é o relógio
Como o contador é derivado do tempo, o gerador e o servidor têm de concordar sobre qual é a janela atual de 30 segundos. A maioria dos servidores suaviza isto aceitando também as janelas vizinhas — um passo para cada lado —, o que absorve em silêncio pequenos desvios. Para lá disso, todos os códigos estão errados, por correto que seja o segredo, e a falha parece idêntica a um dígito mal escrito: uma rejeição seca, sem qualquer pista sobre qual entrada discordou.
Por isso, o primeiro diagnóstico para um autenticador que falha de repente nunca é o segredo; é o relógio do dispositivo que gera os códigos. Uma hora ajustada à mão, uma bateria CMOS a morrer, um telefone que passou um voo no modo de fuso horário errado — qualquer um deles pode desviar o dispositivo um minuto ou mais. O nosso gerador TOTP mostra um cartão de relógio ao vivo e compara o seu dispositivo com a hora do servidor exatamente por isto. Ative a data e hora automáticas e os códigos quase sempre voltam a funcionar — sem reinício, sem segredo novo, sem ticket de apoio.
O segredo é todo o jogo
Tirada a cerimónia, a segurança do TOTP é um só facto: quem tiver o segredo tem o segundo fator, para sempre, de qualquer lugar, sem forma de o serviço distinguir os seus códigos dos seus. O código QR que lê na configuração não é uma imagem de um código — é o próprio segredo, mais a etiqueta da conta e os parâmetros, formatado como um URI otpauth://. Uma captura de ecrã dele é uma cópia permanente do seu segundo fator.
É por isso que as regras de manuseamento são mais estritas do que para as palavras-passe. Uma palavra-passe é verificada pelo servidor e pode ser guardada com hash; um segredo TOTP tem de poder ser recuperado em bruto por ambas as partes, por isso não pode ser dissolvido com um hash, e cada cópia é uma cópia viva. Guarde a cópia mestra no seu autenticador ou num gestor de palavras-passe encriptado. Nunca o escreva num site que gera códigos no seu servidor — entregou a um estranho uma chave permanente — e nunca o cole num chat, como explica a secção seguinte.
Por que o segredo nunca deve ir para um chat
Colar um segredo 2FA num chat — uma conversa de apoio, um canal de equipa, um assistente de IA — parece inofensivo porque a cadeia parece disparatada e a conversa parece privada. Não é nenhuma das duas coisas. Os chats são registados, conservados, sincronizados com todos os dispositivos da conta, pesquisáveis e processados em servidores que não controla; os chats de IA juntam à lista os pipelines de treino e a retenção prolongada. No momento em que o segredo aterra ali, o seu segundo fator existe em sistemas concebidos para guardar e indexar texto.
O padrão seguro é que o segredo só deve existir em três tipos de sítios: a base de dados do serviço, o seu autenticador ou gestor de palavras-passe, e o cálculo local num dispositivo que controla — que é como o gerador TOTP deste site é construído, com o segredo guardado apenas na memória da página e destruído ao atualizar. Se um segredo já foi colado onde não devia, trate-o como queimado: desative e volte a ativar a autenticação de dois fatores no serviço para cunhar um novo, reinscreva o seu autenticador e, já que lá está, verifique a própria palavra-passe na verificação de fugas de palavras-passe.
O que o TOTP não impede
O TOTP derrota o roubo de palavras-passe, o credential stuffing e as fugas de bases de dados: saber a sua palavra-passe já não chega. Não derrota o phishing em tempo real. Uma página de início de sessão falsa que reencaminha as suas credenciais para o serviço real e lhe pede o código pode passá-lo dentro da sua janela de 30 segundos — o código prova a posse do segredo, não que esteja a falar com o site genuíno. O roubo do cookie de sessão contorna-o com a mesma completude, porque o código só é verificado uma vez.
É por isso que as passkeys e as chaves de segurança de hardware estão a deslocar o TOTP no topo de gama: ligam a prova à origem do site, sem deixar nada escrevível para um relé roubar. O TOTP continua a ser uma base forte e universal — muito superior aos códigos SMS, que herdam as fraquezas da rede telefónica —, mas deve ser implantado de olhos abertos: proteja o segredo como uma chave mestra, guarde os códigos de reserva noutro sítio, mantenha o relógio honesto e prefira uma passkey sempre que o serviço a ofereça.