Se alguma vez se perguntou o que são realmente aqueles códigos de 6 dígitos que rodam na sua app de autenticação - e porque é que alguns tokens de hardware se comportam de forma diferente - a resposta resume-se a duas normas estreitamente relacionadas: TOTP e HOTP.
Novo na autenticação de dois fatores em geral? Comece por o que é a 2FA e como protege as suas contas.
Resposta curta
TOTP é baseado no tempo: o código é derivado da hora atual e roda (e expira) a cada 30 segundos. HOTP é baseado num contador: o código é derivado de um contador que incrementa sempre que um código é usado, e permanece válido até ser usado. Ambos são normas OATH/IETF construídas sobre HMAC. A sua app de autenticação usa quase de certeza TOTP - é o que implementam o Google Authenticator, o Authy, o Aegis, o Bitwarden Authenticator e a maioria dos sites. O HOTP aparece sobretudo em certos tokens de hardware.
HOTP: baseado num contador (RFC 4226)
HOTP - HMAC-based One-Time Password - é o algoritmo OATH original, definido na RFC 4226 (2005). Cada código é calculado a partir de dois elementos:
- Um segredo partilhado (uma semente fornecida uma vez, normalmente através de um QR code)
- Um contador que começa em zero e incrementa de um sempre que um código é consumido
O dispositivo executa HMAC-SHA1 (a predefinição) sobre o segredo e o contador, depois trunca o resultado num código numérico curto - 6 dígitos por predefinição, 8 opcionais.
A propriedade que define o HOTP é que o código não tem expiração. Permanece válido até ao uso efetivo; o contador só avança quando um código é aceite. É prático quando não há um relógio fiável, mas tem uma falha bem conhecida: a dessincronização. Se os códigos forem gerados no cliente sem serem submetidos (alguém carrega várias vezes no botão de um token), o contador do cliente adianta-se ao do servidor e os dois deixam de corresponder. Para recuperar, os servidores implementam uma janela de look-ahead - testam os valores de contador seguintes, e se um deles corresponder, avançam o seu contador para se ressincronizar.
TOTP: baseado no tempo (RFC 6238)
TOTP - Time-based One-Time Password - está definido na RFC 6238 (2011) e compreende-se melhor como um caso particular de HOTP. Em vez de um contador de eventos, o TOTP usa o tempo atual dividido por um passo de tempo (o passo predefinido é de 30 segundos) como contador. Insira esse contador derivado do tempo na mesma construção HMAC e obtém um código que muda automaticamente a cada 30 segundos e expira quando a janela vira.
Como o contador é o relógio e não as suas ações, o TOTP nunca se dessincroniza por causa de códigos não usados - não há o problema do tipo "carreguei demasiadas vezes no botão". A contrapartida é que exige que os relógios do cliente e do servidor estejam mais ou menos sincronizados. Os servidores absorvem um ligeiro desvio com uma pequena janela de tolerância, aceitando tipicamente o passo de tempo anterior e o seguinte, além do atual.
Tudo o resto decalca o HOTP: HMAC-SHA1 por predefinição (SHA-256 ou SHA-512 também são permitidos), 6 dígitos por predefinição (8 opcionais) e o segredo fornecido através de um URI otpauth:// dentro de um QR code. Se quiser comparar as apps que geram estes códigos, veja a nossa comparação das melhores apps de autenticação.
Tabela comparativa
| Propriedade | HOTP (RFC 4226) | TOTP (RFC 6238) |
|---|---|---|
| Fator móvel | Contador (baseado em evento) | Tempo (hora atual / passo) |
| O código expira? | Não - válido até ao uso | Sim - a cada ~30 segundos |
| Passo de tempo predefinido | Não aplicável | 30 segundos |
| Falha principal | Dessincronização do contador (ressync look-ahead) | Desvio de relógio (janela de tolerância) |
| Algoritmo | HMAC-SHA1 (SHA-256/512 opcional) | HMAC-SHA1 (SHA-256/512 opcional) |
| Dígitos | 6 predefinidos (8 opcionais) | 6 predefinidos (8 opcionais) |
| Precisa de rede? | Não | Não |
| Uso típico | Alguns tokens de hardware, offline/sem relógio | Apps de autenticação, a maioria dos sites |
Qual usa a sua 2FA
Na prática, raramente escolhe - é o serviço que decide. E o serviço escolhe quase sempre TOTP. O código de 6 dígitos rotativo no Google Authenticator, Authy, Aegis, Bitwarden Authenticator ou Microsoft Authenticator é TOTP. Tal como o código em praticamente todos os ecrãs de configuração de 2FA do tipo "digitalize este QR code" que encontra na web.
HOTP é a exceção. Encontrá-lo-á sobretudo em tokens de hardware - uma YubiKey pode, por exemplo, ser configurada para OATH-HOTP - ou em ambientes em que não se pode garantir uma sincronização de hora fiável, ou seja, exatamente o cenário em que um contador vence um relógio. Uma YubiKey sabe, aliás, fazer várias destas coisas: OATH-TOTP, OATH-HOTP e o bem mais robusto FIDO2. Se quiser o panorama completo, veja o nosso guia completo de YubiKey e FIDO2.
Segurança: qual é mais seguro
O TOTP é geralmente preferido por uma razão concreta: os seus códigos expiram. Um código TOTP capturado por um atacante só é útil durante os segundos que restam até a janela virar, o que mantém curta a janela de interceção-e-reutilização. Um código HOTP, por outro lado, permanece válido até ao uso, pelo que um código HOTP intercetado mas não usado dá ao atacante uma janela de reutilização mais longa.
Mas nenhum dos algoritmos é uma solução mágica. Tanto o TOTP como o HOTP são suscetíveis a phishing. Se uma página de início de sessão falsa o levar a digitar um código válido, um atacante pode reencaminhar esse código para o serviço real em tempo real antes de expirar. A expiração do TOTP encurta essa janela mas não a fecha. É o limite estrutural de todos os esquemas de OTP com segredo partilhado.
Os únicos fatores amplamente implementados realmente resistentes ao phishing são FIDO2 e as passkeys, porque ligam a autenticação à origem do site real: uma credencial reencaminhada simplesmente não funciona no domínio do atacante. Se quiser subir na escala de segurança, leia o que é uma passkey.
Conclusão
TOTP e HOTP são a mesma mecânica HMAC com um fator móvel diferente: o HOTP conta eventos, o TOTP conta o tempo. Os códigos do HOTP nunca expiram mas o seu contador pode dessincronizar-se; os códigos do TOTP expiram a cada 30 segundos mas o seu relógio tem de se manter mais ou menos alinhado. O mundo optou pelo TOTP na 2FA baseada em apps porque códigos que expiram são a predefinição mais segura, e o HOTP sobrevive sobretudo nos tokens de hardware e nos cenários offline. Seja qual for o que um serviço lhe entrega, lembre-se do limite comum: ambos podem ser alvo de phishing. Para as contas que mais importam, uma chave FIDO2 ou uma passkey resistentes ao phishing são a camada mais sólida.
Para definições em linguagem clara de TOTP, HOTP, 2FA, passkey e chave de hardware, veja o glossário de autenticação da PwdFortress.
A PwdFortress explica normas de autenticação com base nas RFC publicadas e na documentação pública. Não inventamos resultados de testes nem estatísticas.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Um gestor com 2FA e passkeys integrados → NordPassGuarde TOTP e passkeys · XChaCha20 · plano gratuito→Perguntas frequentes
Qual é a diferença entre TOTP e HOTP?
Ambos são normas OATH/IETF de palavra-passe de uso único construídas sobre HMAC. **HOTP** (RFC 4226) deriva cada código de um segredo partilhado mais um **contador** que incrementa sempre que um código é usado - o código permanece válido até ser usado, sem limite de tempo. **TOTP** (RFC 6238) é HOTP em que o contador é o **tempo atual dividido por um passo de tempo** (30 segundos por predefinição), pelo que o código muda e expira a cada 30 segundos. Em resumo: HOTP = baseado em evento/contador, TOTP = baseado no tempo.
Qual usa a minha app de autenticação, TOTP ou HOTP?
Quase de certeza **TOTP**. O Google Authenticator, o Authy, o Aegis, o Bitwarden Authenticator, o Microsoft Authenticator e a grande maioria dos sites usam TOTP - o código de 6 dígitos que muda a cada 30 segundos. O HOTP é muito mais raro; vê-se sobretudo em alguns tokens de hardware (por exemplo uma YubiKey configurada para OATH-HOTP) ou em contextos em que não há uma sincronização de hora fiável disponível.
TOTP ou HOTP, qual é mais seguro?
O TOTP é geralmente preferido porque os seus códigos **expiram ao fim de cerca de 30 segundos**, encurtando a janela em que um código intercetado pode ser reutilizado. Os códigos HOTP permanecem válidos até serem usados, pelo que um código intercetado mas não usado tem uma janela de reutilização mais longa. Dito isto, **ambos são suscetíveis a phishing** - um atacante pode levá-lo a introduzir um código válido num site falso e reencaminhá-lo em tempo real. Só FIDO2/passkeys resistem ao phishing.
Porque é que o HOTP se dessincroniza?
O HOTP baseia-se num contador que o cliente e o servidor incrementam cada um. Se gerar códigos no cliente sem nunca os submeter (por exemplo carregando repetidamente no botão de um token de hardware), o contador do cliente adianta-se ao do servidor e os códigos deixam de corresponder. Para recuperar, os servidores usam uma **janela de look-ahead**: testam os valores de contador seguintes, e se um corresponder, ressincronizam-se. O TOTP evita isto porque o contador é o relógio, não as suas ações.
O TOTP precisa de ligação à internet?
Não. Um código TOTP é calculado localmente a partir do segredo partilhado e da hora atual, pelo que a geração funciona totalmente offline. Exige, no entanto, que os relógios do cliente e do servidor estejam mais ou menos sincronizados; os servidores costumam aceitar uma pequena janela de tolerância (muitas vezes mais ou menos um passo de tempo) para absorver um ligeiro desvio de relógio.
Como é partilhado o segredo OTP no início?
Durante a configuração, o serviço mostra um QR code que codifica um URI `otpauth://` contendo o segredo partilhado, o algoritmo (HMAC-SHA1 por predefinição, por vezes SHA-256/512), o número de dígitos (6 por predefinição, por vezes 8) e o tipo (`totp` ou `hotp`). A sua app de autenticação digitaliza-o e guarda o segredo. A partir daí ambos os lados calculam o mesmo HMAC e comparam o código resultante.
