Per què un codi d'un sol ús vàlid encara falla en iniciar sessió a la VPN

Obres el client de VPN, escrius la contrasenya i els sis dígits de l'autenticador tornen com a no vàlids — dues vegades, després una tercera. Res no ha canviat al compte des d'ahir, així que l'instint és esborrar l'entrada de l'autenticador i tornar-la a escanejar — normalment és la reparació equivocada. Un codi d'un sol ús no és una segona contrasenya: la passarel·la l'ha de demanar en un pas concret, des d'una entrada donada d'alta concreta, dins d'una finestra concreta, i la majoria de rebuigs passen abans que es comparin els dígits. Esbrina en quin pas ets abans de tocar l'alta.

L'ordre de les peticions et diu en quin flux ets

Tres formes cobreixen gairebé tot inici de sessió a la VPN que inclou un codi. En la forma de dos passos el client envia la contrasenya, el servidor emet un repte i el client torna a preguntar. En la forma combinada la passarel·la vol contrasenya i codi en un sol enviament — de vegades concatenats, de vegades després d'un separador que només documenta l'operador. En la forma de navegador el client no té cap camp: el codi va a una pàgina web, o una aprovació push el substitueix, i el client d'escriptori espera el resultat.

Equivocar-se de forma sembla un codi dolent. Enganxa un codi nou en un camp només de contrasenya i el servidor el llegirà com a part de la contrasenya. Al costat del client, OpenVPN 2.4 i posteriors fan visible la diferència: un servidor que respon amb AUTH_FAILED,CRV1: espera una resposta al repte, així que el perfil necessita static-challenge o un fitxer de contrasenya en forma SCRV1:. Un perfil més antic que només porta auth-user-pass valida la contrasenya i després s'atura, cosa que al registre sembla una fallada d'OTP encara que no s'hagi enviat cap codi.

Val la pena esmentar WireGuard com a excepció: autentica parells de claus, no persones, així que no hi ha cap camp per a un codi. Si un proveïdor n'anuncia un, alguna cosa fora del túnel l'accepta.

Què fa el servidor amb els sis dígits

Els codis basats en temps segueixen RFC 6238, que embolcalla la construcció més antiga basada en comptador de RFC 4226: un HMAC sobre un factor mòbil, truncat a sis dígits per defecte. Per a TOTP el factor mòbil és l'hora Unix actual dividida per un pas, 30 segons tret que l'operador l'hagi canviat. El verificador mai compara els teus dígits amb un valor desat; recalcula el codi esperat a partir de la llavor compartida i normalment accepta també els passos veïns, així que una anada i tornada lenta no fa fallar l'inici de sessió.

Dues conseqüències es perden. La zona horària del telèfon és irrellevant, perquè la llavor no veu mai un rellotge local — només compta la desviació respecte de l'UTC real, i un aparell que va dos minuts avançat falla tots els codis mentre mostra un comptador enrere net. I un codi és d'un sol ús per disseny: el verificador recorda l'últim valor de comptador que va acceptar per a aquella llavor, així que els mateixos dígits enviats de nou es rebutgen fins i tot dins de la mateixa finestra. Un client que reintenta després d'un temps d'espera pot cremar el codi que acaba d'enviar.

Els testimonis basats en comptador mouen el comptador a cada pulsació, així que es desincronitzen després que s'hagin generat codis que mai s'envien; la reparació habitual és una finestra de resincronització que accepta uns quants valors endavant. Si l'operador va donar d'alta HOTP i la teva aplicació mostra TOTP, tots els valors són incorrectes d'una manera que sembla un problema de rellotge. L'URI d'aprovisionament darrere del codi QR indica el tipus, els dígits, el període i el hash.

Fallades que semblen un codi incorrecte

L'entrada donada d'alta és el culpable més habitual. Les aplicacions d'autenticació etiqueten les entrades per emissor i compte, així que qui té dues identitats a la mateixa VPN pot acabar amb dues entrades les etiquetes de les quals difereixen en un caràcter. Un codi és vàlid per a la llavor que el va generar i per a res més. Compara l'etiqueta del telèfon amb el nom d'usuari que registra el servidor, no amb el que recordes haver escrit.

Segon, un conjunt de paràmetres que no encaixa. Una llavor donada d'alta amb vuit dígits, un període de 60 segons o SHA-256 produeix codis que un verificador que espera sis dígits, 30 segons i SHA-1 rebutja, i al client això és indistingible d'un codi incorrecte. Apareix després de migracions en què l'entrada es va tornar a afegir a partir d'una foto del codi QR, o en què el registre del testimoni es va reconstruir amb valors per defecte.

Tercer, no va del codi. Les passarel·les solen tornar una única fallada genèrica d'autenticació per a una contrasenya incorrecta, un codi caducat i un compte desactivat, deliberadament, perquè ningú no pugui provar quin factor ha fallat. Llegeix el registre de la passarel·la o de RADIUS en lloc del missatge del client: un repte que mai no s'ha emès, un rebuig d'accés sense atribut OTP i una denegació per política es veuen igual a la pantalla i porten a passos següents diferents.

Una seqüència curta que ho acota

Comença per la comprovació més barata i atura't al primer pas que no es compleixi.

1. Espera un codi nou, envia'l un cop i fixa't si el repte apareix abans o després que s'accepti la contrasenya.
2. Fes coincidir l'etiqueta de l'autenticador amb el nom d'usuari que desa el servidor.
3. Confirma que el perfil pot respondre un repte, com en el cas CRV1 d'abans.
4. Compara el rellotge del dispositiu amb una font de temps coneguda; una desviació de més d'unes desenes de segons trenca TOTP per si sola.
5. Pregunta a l'operador si el testimoni és TOTP o HOTP, i quins dígits, període i hash es van donar d'alta.

Dues regles eviten que això empitjori. No reintentis moltes vegades: moltes passarel·les compten les fallades per compte i o el bloquegen o comencen a retardar les respostes, així que una ràfega converteix una petita configuració errònia en un tiquet de suport. I no tornis a donar d'alta el testimoni com a diagnòstic, perquè invalida la llavor antiga; si la fallada real era un repte que el client mai no va enviar, ara tens dos canvis per raonar en lloc d'un.

Mantén la llavor i els codis de recuperació fora del circuit

Els sis dígits i el secret que hi ha darrere no són intercanviables. Un codi QR d'aprovisionament o una llavor Base32 genera tots els codis futurs del compte, així que pertany a la mateixa categoria que la contrasenya: no en una captura de pantalla, no en un comentari d'un tiquet, no en un xat amb algú que s'hagi posat en contacte amb tu primer. Els codis de recuperació són un mecanisme a part — d'un sol ús, sovint s'altllen la petició de codi del tot, i gastar-ne un per provar el compte elimina una alternativa que et pot caldre més endavant.

Un codi tampoc no fa fiable una pàgina d'inici de sessió: una petició d'OTP en un domini d'aspecte similar recull un codi vàlid i el reprodueix dins de la finestra, i el certificat continua sent el que et diu on escrius.

Si la seqüència acaba en un perfil que no pot respondre un repte, arregla el perfil i torna a provar amb un codi nou. Si acaba en paràmetres d'alta que no encaixen, demana a l'operador que llegeixi el registre del testimoni abans que ningú escanegi res. Si acaba en un bloqueig, espera que passi en lloc de canviar de client — l'estat del compte és l'obstacle, no l'aplicació.