Bakit nabigo pa rin ang valid na one-time code sa pag-login sa VPN

Binubuksan mo ang VPN client, i-type ang password, at ang anim na digit mula sa iyong authenticator ay bumabalik na invalid — dalawang beses, tapos pangatlo. Walang nagbago sa account mula kahapon, kaya ang unang instinct ay tanggalin ang entry sa authenticator at i-scan itong muli — kadalasan ito ang maling pag-aayos. Ang one-time code ay hindi pangalawang password: kailangang hingin ito ng gateway sa isang partikular na hakbang, mula sa isang partikular na naka-enroll na entry, sa loob ng isang partikular na window, at karamihan sa mga pagtanggi ay nangyayari bago pa ihambing ang mga digit. Alamin kung anong hakbang ang kinaroroonan mo bago hawakan ang enrollment.

Sinasabi ng order ng prompt kung anong flow ang kinaroroonan mo

Tatlong hugis ang sumasaklaw sa halos lahat ng pag-login sa VPN na may code. Sa two-step na hugis, ipinapadala ng client ang password, naglalabas ang server ng challenge, at muling nagtatanong ang client. Sa pinagsamang hugis, gusto ng gateway ang password at code sa isang submission — kung minsan pinagsama, kung minsan pagkatapos ng separator na dokumentado lamang ng operator. Sa browser na hugis, wala talagang field ang client: pumapasok ang code sa isang web page, o pinapalitan ito ng push approval, at hinihintay ng desktop client ang resulta.

Ang maling hugis ay mukhang masamang code. I-paste ang bagong code sa field na para lamang sa password, at babasahin ito ng server bilang bahagi ng password. Sa panig ng client, ginagawang nakikita ng OpenVPN 2.4 at mas bago ang pagkakaiba: ang server na tumutugon ng AUTH_FAILED,CRV1: ay umaasa ng challenge response, kaya kailangan ng profile ang static-challenge o password file sa SCRV1: na anyo. Ang mas lumang profile na may auth-user-pass lamang ay nagpapatunay ng password at pagkatapos ay tumitigil, na sa log ay mukhang OTP failure kahit walang ipinadalang code.

Karapat-dapat banggitin ang WireGuard bilang exception: pinapatunayan nito ang mga key pair, hindi tao, kaya walang field para sa code. Kung may inaanunsiyo ang provider, may isang bagay sa labas ng tunnel ang tumatanggap nito.

Ano ang ginagawa ng server sa anim na digit

Ang mga code na nakabatay sa oras ay sumusunod sa RFC 6238, na bumabalot sa mas lumang construction na nakabatay sa counter mula sa RFC 4226: isang HMAC sa isang gumagalaw na factor, pinuputol sa anim na digit bilang default. Sa TOTP ang gumagalaw na factor ay ang kasalukuyang Unix time na hinati sa isang step, 30 segundo maliban kung binago ito ng operator. Hindi kailanman inihahambing ng verifier ang iyong mga digit sa isang naka-store na value; muling kinakalkula nito ang inaasahang code mula sa shared seed at karaniwang tinatanggap din ang mga kalapit na step, kaya ang mabagal na round trip ay hindi nagpapabigo sa login.

Dalawang kahihinatnan ang napapabayaan. Walang kinalaman ang time zone ng telepono, dahil hindi kailanman nakikita ng seed ang lokal na orasan — ang paglihis mula sa tunay na UTC lamang ang mahalaga, at ang device na dalawang minuto ang bilis ay nabibigo sa bawat code habang nagpapakita ng malinaw na countdown. At ang code ay one-time ayon sa disenyo: naaalala ng verifier ang huling counter value na tinanggap nito para sa seed na iyon, kaya ang parehong mga digit na isusumite muli ay tinatanggihan kahit sa loob ng parehong window. Ang client na muling sumubok pagkatapos ng timeout ay maaaring masunog ang code na ipinadala nito.

Ang mga token na nakabatay sa counter ay naglilipat ng counter sa bawat pagpindot, kaya lumalabas sa sync pagkatapos magawa ang mga code pero hindi kailanman naipadala; ang karaniwang pag-aayos ay isang resynchronization window na tumatanggap ng ilang value nang pasulong. Kung nag-enroll ang operator ng HOTP at ang app mo ay nagpapakita ng TOTP, mali ang bawat value sa paraang mukhang problema sa orasan. Pinangalanan ng provisioning URI sa likod ng QR code ang uri, digit, period at hash.

Mga pagkabigo na mukhang maling code

Ang naka-enroll na entry ang pinakakaraniwang salarin. Nilalagyan ng label ng authenticator app ang mga entry ayon sa issuer at account, kaya ang sinumang may dalawang identity sa parehong VPN ay maaaring magkaroon ng dalawang entry na ang label ay nagkakaiba ng isang character. Ang code ay valid para sa seed na gumawa nito at wala nang iba. Ihambing ang label sa telepono sa username na itinatala ng server, hindi sa natatandaan mong itina-type mo.

Pangalawa, isang set ng parameter na hindi tugma. Ang seed na naka-enroll na may walong digit, 60 segundong period o SHA-256 ay nagbibigay ng mga code na tinatanggihan ng verifier na umaasa ng anim na digit, 30 segundo at SHA-1, at sa client ay hindi ito makikilala mula sa maling code. Lumilitaw ito pagkatapos ng migration kung saan idinagdag muli ang entry mula sa larawan ng QR code, o kung saan muling itinayo ang token record gamit ang mga default.

Pangatlo, hindi ito tungkol sa code. Karaniwang nagbabalik ang gateway ng isang generic na authentication failure para sa maling password, expired na code at disabled na account, sinasadya, para walang makapagsiyasat kung aling factor ang nabigo. Basahin ang log ng gateway o RADIUS sa halip na ang banner ng client: ang challenge na hindi kailanman inilabas, ang pagtanggi sa access na walang OTP attribute at ang pagtanggi ayon sa policy ay magkatulad ang hitsura sa screen at humahantong sa magkaibang susunod na hakbang.

Isang maikling sequence na nagpapaliit nito

Magsimula sa pinakamurang pagsusuri at huminto sa unang hakbang na hindi tumatayo.

1. Maghintay ng bagong code, isumite ito nang isang beses, at tandaan kung ang challenge ay lumilitaw bago o pagkatapos tanggapin ang password.
2. Itugma ang label sa authenticator sa username na iniimbak ng server.
3. Kumpirmahin na kayang tumugon ng profile sa isang challenge, tulad sa kaso ng CRV1 sa itaas.
4. Ihambing ang orasan ng device sa kilalang source ng oras; ang paglihis na lampas ng ilang sampung segundo ay sinira ang TOTP nang mag-isa.
5. Tanungin ang operator kung TOTP o HOTP ang token, at aling digit, period at hash ang naka-enroll.

Dalawang patakaran ang pumipigil na lumala ito. Huwag muling subukan nang maraming beses: maraming gateway ang nagbibilang ng pagkabigo kada account at nilo-lock ito o nagsisimulang magpabagal ng sagot, kaya ang isang bugso ay ginagawang support ticket ang maliit na configuration error. At huwag muling i-enroll ang token bilang diagnostic, dahil ginagawang invalid nito ang lumang seed; kung ang tunay na sira ay isang challenge na hindi kailanman ipinadala ng client, may dalawang pagbabago ka nang dapat ipaliwanag sa halip na isa.

Ilayo ang seed at recovery code sa loop

Ang anim na digit at ang secret sa likod nito ay hindi mapagpapalit. Ang provisioning QR code o Base32 seed ay gumagawa ng bawat susunod na code para sa account, kaya kabilang ito sa parehong kategorya ng password: hindi sa screenshot, hindi sa komento ng ticket, hindi sa chat ng sinumang naunang nag-contact sa iyo. Ang recovery code ay hiwalay na mekanismo — one-time, kadalasang nilalaktawan nang tuluyan ang code prompt, at ang paggastos ng isa para subukan ang account ay nag-aalis ng fallback na maaaring kailanganin mo mamaya.

Hindi rin ginagawang mapagkakatiwalaan ng code ang login page: ang OTP prompt sa katulad na domain ay nangongolekta ng valid na code at muling pinapatugtog ito sa loob ng window, at ang certificate pa rin ang nagsasabi kung saan ka nagta-type.

Kung ang sequence ay nagtapos sa isang profile na hindi kayang tumugon sa challenge, ayusin ang profile at muling subukan gamit ang isang bagong code. Kung nagtapos ito sa hindi tugmang enrollment parameter, hilingin sa operator na basahin ang token record bago may mag-scan ng anuman. Kung nagtapos ito sa lockout, hintayin itong matapos sa halip na magpalit ng client — ang estado ng account ang sagabal, hindi ang app.