Testar uma integração 2FA
Está a desenvolver a ativação de dois fatores: gere um segredo, importe o URI na sua aplicação de autenticação e confirme que o servidor aceita os mesmos códigos.
Introduza ou gere um segredo Base32 de 160 bits, escolha SHA-1, SHA-256 ou SHA-512, 6 ou 8 dígitos e o período: o código TOTP atual atualiza-se com uma contagem decrescente, o URI otpauth:// fica pronto para uma aplicação de autenticação e pode verificar um código com uma tolerância de um período.
A chave partilhada mostrada sob o código QR de ativação (letras A-Z e algarismos 2-7).
A codificar num código QR para Google Authenticator, Microsoft Authenticator, Aegis ou 1Password.
Esta ferramenta calcula os códigos de utilização única TOTP, os que aparecem no Google Authenticator, no Microsoft Authenticator ou no 1Password, a partir de um segredo Base32. Ajuda os programadores que integram a autenticação de dois fatores a testar a sua implementação, e os administradores a verificar um segredo ou preparar um URI de registo.
O TOTP (RFC 6238) é a variante temporal do HOTP (RFC 4226). Calcula-se um contador T = floor(hora Unix / período), 30 segundos por predefinição, e depois HMAC(segredo, T) com SHA-1, SHA-256 ou SHA-512. Um «truncamento dinâmico» extrai 4 bytes do HMAC a partir de um deslocamento dado pelos seus 4 últimos bits, e o resultado módulo 10^6 (ou 10^8) é o código. Exemplo do RFC: com o segredo ASCII `12345678901234567890` (Base32 `GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ`), SHA-1 e o instante 59 s, o código de 8 dígitos é 94287082.
A ferramenta descodifica o segredo Base32 (ou gera um de 160 bits, 32 caracteres, com crypto.getRandomValues), calcula o código atual com a Web Crypto e atualiza-o com uma contagem decrescente até ao período seguinte. Constrói o URI `otpauth://totp/Emissor:conta?secret=…&issuer=Emissor&algorithm=SHA1&digits=6&period=30` que as aplicações importam, normalmente através de um código QR. Na verificação, compara o código introduzido com os do período anterior, atual e seguinte, o que absorve um pequeno desvio de relógio.
Cole um segredo Base32 ou gere um de 160 bits e escolha o algoritmo (SHA-1, SHA-256, SHA-512), o número de dígitos (6 ou 8) e o período (30 s por predefinição).
O código atual aparece com a sua contagem decrescente; indique o emissor e o nome da conta para obter o URI otpauth:// a importar numa aplicação.
Escreva um código recebido: a ferramenta indica se corresponde ao período atual, anterior ou seguinte.
Está a desenvolver a ativação de dois fatores: gere um segredo, importe o URI na sua aplicação de autenticação e confirme que o servidor aceita os mesmos códigos.
Compare o código esperado para um segredo com o da aplicação do utilizador para distinguir um segredo errado, um algoritmo diferente ou um relógio desacertado.
Construa o URI otpauth:// com o emissor e o nome de conta corretos e transforme-o num código QR para a equipa que tem de registar a conta.
A causa mais frequente é um relógio desacertado no telemóvel ou no servidor: bastam algumas dezenas de segundos para mudar de período. Seguem-se um segredo mal copiado e um algoritmo, número de dígitos ou período diferentes dos esperados pelo serviço. Ative a hora automática e compare o código desta ferramenta com o da aplicação.
O HOTP (RFC 4226) calcula o código a partir de um contador incrementado a cada utilização, que tem de se manter sincronizado entre cliente e servidor. O TOTP (RFC 6238) substitui esse contador pelo tempo dividido em períodos de 30 segundos, pelo que o código expira sozinho. Quase todas as aplicações 2FA de uso corrente utilizam TOTP.
O serviço apresenta-a quando ativa a 2FA, por baixo do código QR, muitas vezes com a indicação «chave de configuração» ou «introduzir o código manualmente». O próprio QR contém um URI otpauth:// cujo parâmetro secret é essa chave em Base32. Concluída a ativação, a maioria dos serviços deixa de a mostrar.
Não é garantido: a documentação histórica do formato de URI indica que o Google Authenticator ignorava algorithm, digits e period e gerava códigos SHA-1 de 6 dígitos que depois não coincidem. Aplicações como o 1Password ou o Authy aceitam SHA-256 e SHA-512. Para um serviço público, SHA-1 com 6 dígitos continua a ser a opção compatível, e é seguro na construção HMAC.
Um código corresponde a um período, 30 segundos por predefinição. Muitos servidores, tal como esta ferramenta na verificação, aceitam também o período anterior e o seguinte para compensar a latência e o desvio de relógio, o que dá uma janela efetiva de cerca de 90 segundos.
O segredo gera todos os seus códigos futuros: quem o tiver dispõe do seu segundo fator. Aqui, o cálculo é feito apenas no seu navegador com a Web Crypto e nada é transmitido. Ainda assim, evite colar o segredo de uma conta de produção real num dispositivo partilhado; prefira um segredo de teste.
Ferramentas relacionadas
Ferramentas semelhantes ou complementares a esta.
Gere tokens aleatórios seguros de 8 a 256 bytes em hexadecimal, Base64 ou Base64URL, com prefixo opcional.
Calcule um HMAC SHA-1, SHA-256, SHA-384 ou SHA-512 em hex ou Base64 e verifique uma assinatura de webhook.
Gere palavras-passe fortes e aleatórias de 8 a 128 caracteres, com a entropia indicada.
Saiba quando usar criptografia, hashing, HMAC ou PBKDF2 para confidencialidade, integridade, autenticação e senhas.
Entenda como OAuth 2.0, PKCE, JWT, JWK e JWKS se relacionam: autorização, tokens, chaves públicas e verificação.
Aprenda a construir uma CSP progressiva, compreender as suas diretivas e evitar políticas demasiado permissivas ou que quebram o site.