Por que un código dun só uso válido segue fallando ao iniciar sesión na VPN

Abres o cliente de VPN, escribes o contrasinal e os seis díxitos do autenticador volven como non válidos — dúas veces, logo unha terceira. Nada cambiou na conta desde onte, así que o instinto é borrar a entrada do autenticador e volver escaneala — normalmente a reparación equivocada. Un código dun só uso non é un segundo contrasinal: a pasarela ten que pedilo nun paso concreto, desde unha entrada rexistrada concreta, dentro dunha xanela concreta, e a maioría dos rexeitamentos ocorren antes de que se comparen os díxitos. Averigua en que paso estás antes de tocar o alta.

A orde das solicitudes diche en que fluxo estás

Tres formas cobren case todo inicio de sesión en VPN que inclúe un código. Na forma de dous pasos o cliente envía o contrasinal, o servidor emite un desafío e o cliente volve preguntar. Na forma combinada a pasarela quere contrasinal e código nun só envío — ás veces concatenados, ás veces tras un separador que só documenta o operador. Na forma de navegador o cliente non ten ningún campo: o código vai a unha páxina web, ou unha aprobación push substitúeo, e o cliente de escritorio espera o resultado.

Equivocarse de forma parece un código malo. Pega un código novo nun campo só de contrasinal e o servidor leráo como parte do contrasinal. No lado do cliente, OpenVPN 2.4 e posteriores fan visible a diferenza: un servidor que responde con AUTH_FAILED,CRV1: espera unha resposta ao desafío, así que o perfil necesita static-challenge ou un ficheiro de contrasinal en forma SCRV1:. Un perfil máis antigo que só leva auth-user-pass valida o contrasinal e despois detense, o que no rexistro parece un fallo de OTP aínda que non se enviase ningún código.

Paga a pena nomear WireGuard como a excepción: autentica pares de claves, non persoas, así que non hai campo para un código. Se un provedor anuncia un, algo fóra do túnel o acepta.

Que fai o servidor cos seis díxitos

Os códigos baseados en tempo seguen RFC 6238, que envolve a construción máis antiga baseada en contador de RFC 4226: un HMAC sobre un factor móbil, truncado a seis díxitos por defecto. Para TOTP o factor móbil é a hora Unix actual dividida por un paso, 30 segundos salvo que o operador o cambiase. O verificador nunca compara os teus díxitos cun valor gardado; recalcula o código esperado a partir da semente compartida e normalmente acepta tamén os pasos veciños, así que unha viaxe de ida e volta lenta non fai fallar o inicio de sesión.

Dúas consecuencias pasan por alto. A zona horaria do teléfono é irrelevante, porque a semente nunca ve un reloxo local — só conta a desviación respecto ao UTC real, e un dispositivo que vai dous minutos adiantado falla todos os códigos mentres mostra unha conta atrás limpa. E un código é dun só uso por deseño: o verificador lembra o último valor de contador que aceptou para esa semente, así que os mesmos díxitos enviados de novo rexeitanse mesmo dentro da mesma xanela. Un cliente que reintenta tras un tempo de espera pode queimar o código que acaba de enviar.

Os tokens baseados en contador moven o contador con cada pulsación, así que se desincronizan despois de que se xerasen códigos que nunca se envían; a reparación habitual é unha xanela de resincronización que acepta uns cantos valores por diante. Se o operador deu de alta HOTP e a túa aplicación mostra TOTP, todos os valores son incorrectos dunha forma que parece un problema de reloxo. A URI de aprovisionamento detrás do código QR indica o tipo, os díxitos, o período e o hash.

Fallos que parecen un código incorrecto

A entrada rexistrada é o culpable máis habitual. As aplicacións de autenticación etiquetan as entradas por emisor e conta, así que quen ten dúas identidades na mesma VPN pode acabar con dúas entradas cuxas etiquetas difiren nun carácter. Un código é válido para a semente que o xerou e para nada máis. Compara a etiqueta do teléfono co nome de usuario que rexistra o servidor, non co que lembras escribir.

Segundo, un conxunto de parámetros que non encaixa. Unha semente dada de alta con oito díxitos, un período de 60 segundos ou SHA-256 produce códigos que un verificador que espera seis díxitos, 30 segundos e SHA-1 rexeita, e no cliente iso é indistinguible dun código incorrecto. Aparece tras migracións nas que a entrada se volveu engadir a partir dunha foto do código QR, ou nas que o rexistro do token se reconstruíu con valores por defecto.

Terceiro, non vai do código. As pasarelas adoitan devolver un único fallo xenérico de autenticación para un contrasinal incorrecto, un código caducado e unha conta desactivada, a propósito, para que ninguén poida sondar que factor fallou. Le o rexistro da pasarela ou de RADIUS en lugar da mensaxe do cliente: un desafío que nunca se emitiu, un rexeitamento de acceso sen atributo OTP e unha denegación por política vense igual na pantalla e levan a pasos seguintes distintos.

Unha secuencia curta que o acouta

Comeza pola comprobación máis barata e detente no primeiro paso que non se cumpra.

1. Espera un código novo, envíao unha vez e fixate en se o desafío aparece antes ou despois de que se acepte o contrasinal.
2. Fai coincidir a etiqueta do autenticador co nome de usuario que garda o servidor.
3. Confirma que o perfil pode responder un desafío, como no caso CRV1 de antes.
4. Compara o reloxo do dispositivo cunha fonte de tempo coñecida; unha desviación de máis dunhas decenas de segundos rompe TOTP por si soa.
5. Pregunta ao operador se o token é TOTP ou HOTP, e que díxitos, período e hash se deron de alta.

Dúas regras evitan que isto empeore. Non reintentes moitas veces: moitas pasarelas contan os fallos por conta e ou a bloquean ou comezan a atrasar as respostas, así que unha ráfaga converte unha pequena configuración errónea nun ticket de soporte. E non volvas dar de alta o token como diagnóstico, porque invalida a semente antiga; se o fallo real era un desafío que o cliente nunca enviou, agora tes dous cambios que razoar en lugar de un.

Mantén a semente e os códigos de recuperación fóra do circuíto

Os seis díxitos e o segredo que hai detrás non son intercambiables. Un código QR de aprovisionamento ou unha semente Base32 xera todos os códigos futuros da conta, así que pertence á mesma categoría que o contrasinal: non nunha captura de pantalla, non nun comentario dun ticket, non nun chat con alguén que se puxo en contacto contigo primeiro. Os códigos de recuperación son un mecanismo aparte — dun só uso, a miúdo saltan a petición de código por completo, e gastar un para probar a conta elimina unha alternativa que podes necesitar máis adiante.

Un código tampouco fai fiable unha páxina de inicio de sesión: unha petición de OTP nun dominio de aspecto similar recolle un código válido e reprodúceo dentro da xanela, e o certificado segue sendo o que che di onde escribes.

Se a secuencia acaba nun perfil que non pode responder un desafío, arranxa o perfil e volve probar cun código novo. Se acaba en parámetros de alta que non encaixan, pide ao operador que lea o rexistro do token antes de que ninguén escanee nada. Se acaba nun bloqueo, espera a que pase en lugar de cambiar de cliente — o estado da conta é o obstáculo, non a aplicación.