Porque um código de uso único válido ainda falha no início de sessão VPN

Abre o cliente VPN, escreve a palavra-passe, e os seis dígitos do autenticador voltam como inválidos — duas vezes, depois uma terceira. Nada mudou na conta desde ontem, por isso o instinto é apagar a entrada no autenticador e voltar a digitalizá-la — quase sempre a reparação errada. Um código de uso único não é uma segunda palavra-passe: a gateway tem de o pedir num passo concreto, a partir de uma entrada inscrita concreta, dentro de uma janela concreta, e a maioria das rejeições acontece antes de os dígitos serem comparados. Descubra em que passo está antes de mexer na inscrição.

A ordem dos pedidos diz-lhe em que fluxo está

Três formas cobrem quase todo o início de sessão VPN que envolve um código. Na forma de dois passos o cliente envia a palavra-passe, o servidor emite um desafio e o cliente volta a perguntar. Na forma combinada a gateway quer palavra-passe e código numa só submissão — às vezes concatenados, às vezes após um separador que só o operador documenta. Na forma de navegador o cliente não tem campo nenhum: o código vai para uma página web, ou uma aprovação push substitui-o, e o cliente de ambiente de trabalho espera pelo resultado.

A forma errada parece um código mau. Cole um código novo num campo só de palavra-passe e o servidor lê-o como parte da palavra-passe. Do lado do cliente, o OpenVPN 2.4 e seguintes tornam a diferença visível: um servidor que responde com AUTH_FAILED,CRV1: espera uma resposta ao desafio, pelo que o perfil precisa de static-challenge ou de um ficheiro de palavra-passe na forma SCRV1:. Um perfil mais antigo que só leva auth-user-pass valida a palavra-passe e depois encrava, o que no registo parece uma falha de OTP mesmo sem nenhum código ter sido enviado.

Vale a pena nomear o WireGuard como a exceção: autentica pares de chaves e não pessoas, pelo que não há campo para um código. Se um fornecedor anunciar um, é algo fora do túnel que o aceita.

O que o servidor faz com os seis dígitos

Os códigos baseados no tempo seguem o RFC 6238, que envolve a construção mais antiga baseada em contador do RFC 4226: um HMAC sobre um fator móvel, truncado a seis dígitos por predefinição. No TOTP o fator móvel é a hora Unix atual dividida por um passo, 30 segundos salvo se o operador o tiver alterado. O verificador nunca compara os seus dígitos com um valor guardado; recalcula o código esperado a partir da semente partilhada e normalmente aceita também os passos vizinhos, por isso uma ida e volta lenta não faz falhar o início de sessão.

Duas consequências passam ao lado. O fuso horário do telefone é irrelevante, porque a semente nunca vê um relógio local — só conta o desvio em relação ao UTC real, e um aparelho que adianta dois minutos falha em todos os códigos enquanto mostra uma contagem decrescente limpa. E um código é de uso único por conceção: o verificador memoriza o último valor de contador que aceitou para essa semente, pelo que os mesmos dígitos submetidos de novo são recusados mesmo dentro da mesma janela. Um cliente que tenta de novo após um tempo limite pode queimar o código que acabou de enviar.

Os tokens baseados em contador avançam o contador a cada pressão, pelo que se dessincronizam depois de serem gerados códigos que nunca chegam a ser enviados; a reparação habitual é uma janela de ressincronização que aceita alguns valores à frente. Se o operador inscreveu HOTP e a sua aplicação mostra TOTP, todos os valores estão errados de uma forma que parece um problema de relógio. O URI de aprovisionamento por trás do código QR indica o tipo, os dígitos, o período e o hash.

Falhas que parecem um código errado

A entrada inscrita é o culpado mais comum. As aplicações de autenticação rotulam as entradas por emissor e conta, pelo que quem tem duas identidades na mesma VPN pode acabar com duas entradas cujos rótulos diferem num caractere. Um código é válido para a semente que o gerou e para mais nada. Compare o rótulo no telefone com o nome de utilizador que o servidor registra, não com o que se lembra de ter escrito.

Segundo, um conjunto de parâmetros que não encaixa. Uma semente inscrita com oito dígitos, um período de 60 segundos ou SHA-256 produz códigos que um verificador que espera seis dígitos, 30 segundos e SHA-1 recusa, e no cliente isso é indistinguível de um código errado. Aparece após migrações em que a entrada foi acrescentada de novo a partir de uma fotografia do código QR, ou em que o registo do token foi reconstruído com valores predefinidos.

Terceiro, não é sobre o código. As gateways devolvem normalmente uma única falha genérica de autenticação para palavra-passe errada, código expirado e conta desativada, deliberadamente, para que ninguém possa sondar que fator falhou. Leia o registo da gateway ou do RADIUS em vez do aviso do cliente: um desafio nunca emitido, uma recusa de acesso sem atributo OTP e uma negação por política aparecem iguais no ecrã e levam a passos seguintes diferentes.

Uma sequência curta que o restringe

Comece pela verificação mais barata e pare no primeiro passo que não se verifique.

1. Espere por um código novo, submeta-o uma vez e registe se o desafio aparece antes ou depois de a palavra-passe ser aceite.
2. Faça corresponder o rótulo do autenticador ao nome de utilizador que o servidor guarda.
3. Confirme que o perfil consegue responder a um desafio, como no caso CRV1 acima.
4. Compare o relógio do dispositivo com uma fonte de tempo conhecida; um desvio superior a algumas dezenas de segundos quebra o TOTP por si só.
5. Pergunte ao operador se o token é TOTP ou HOTP, e que dígitos, período e hash foram inscritos.

Duas regras impedem que isto piore. Não tente repetidamente: muitas gateways contam falhas por conta e ou a bloqueiam ou começam a atrasar respostas, pelo que uma rajada transforma um pequeno erro de configuração num pedido de apoio. E não volte a inscrever o token como diagnóstico, porque isso invalida a semente antiga; se a falha real era um desafio que o cliente nunca enviou, agora tem duas alterações para explicar em vez de uma.

Mantenha a semente e os códigos de recuperação fora do circuito

Os seis dígitos e o segredo por trás deles não são intermutáveis. Um código QR de aprovisionamento ou uma semente Base32 gera todos os códigos futuros da conta, pelo que pertence à mesma categoria da palavra-passe: não numa captura de ecrã, não num comentário de um pedido, não numa conversa com alguém que o contactou primeiro. Os códigos de recuperação são um mecanismo à parte — de uso único, muitas vezes saltam por completo o pedido de código, e gastar um para testar a conta elimina uma via alternativa de que pode precisar mais tarde.

Um código também não torna uma página de início de sessão fidedigna: um pedido de OTP num domínio parecido recolhe um código válido e reprodu-lo dentro da janela, e o certificado continua a ser o que lhe diz onde está a escrever.

Se a sequência terminar num perfil que não consegue responder a um desafio, corrija o perfil e teste de novo com um código novo. Se terminar em parâmetros de inscrição que não encaixam, peça ao operador que leia o registo do token antes de alguém digitalizar o que quer que seja. Se terminar num bloqueio, aguarde que passe em vez de trocar de cliente — o estado da conta é o obstáculo, não a aplicação.