Kial valida unufoja kodo tamen malsukcesas ĉe VPN-enskribiĝo

Vi malfermas la VPN-klienton, tajpas la pasvorton, kaj la ses ciferoj el via aŭtentikiga aplikaĵo revenas kiel nevalidaj — dufoje, poste trian fojon. Nenio ŝanĝiĝis en la konto ekde hieraŭ, do la unua impulso estas forigi la eron en la aŭtentikiga aplikaĵo kaj skani ĝin denove — kutime la malĝusta riparo. Unufoja kodo ne estas dua pasvorto: la pordego devas peti ĝin en difinita paŝo, el difinita registrita ero, ene de difinita fenestro, kaj plej multaj rifuzoj okazas antaŭ ol la ciferoj estas komparataj. Konstatu, en kiu paŝo vi estas, antaŭ ol tuŝi la registriĝon.

La ordo de la petoj montras, en kiu fluo vi estas

Tri formoj kovras preskaŭ ĉiun VPN-enskribiĝon kun kodo. En la dupaŝa formo la kliento sendas la pasvorton, la servilo eldonas defion, kaj la kliento demandas denove. En la kombinita formo la pordego volas pasvorton kaj kodon en unu sendo — foje kunligitaj, foje post apartigilo, kiun dokumentas nur la operatoro. En la retuma formo la kliento tute ne havas kampon: la kodo iras en retpaĝon, aŭ puŝa aprobo anstataŭas ĝin, kaj la surtabla kliento atendas la rezulton.

Malĝusta formo aspektas kiel malbona kodo. Algluu freŝan kodon en kampon nur por pasvorto, kaj la servilo legos ĝin kiel parton de la pasvorto. Ĉe la klienta flanko, OpenVPN 2.4 kaj pli novaj videbligas la diferencon: servilo, kiu respondas per AUTH_FAILED,CRV1:, atendas defian respondon, do la profilo bezonas static-challenge aŭ pasvortodosieron en formo SCRV1:. Pli malnova profilo portanta nur auth-user-pass validigas la pasvorton kaj poste haltas, kio en la protokolo aspektas kiel OTP-malsukceso, kvankam neniu kodo estis sendita.

WireGuard indas esti nomata la escepto: ĝi aŭtentikigas ŝlosilparojn, ne homojn, do ne ekzistas kampo por kodo. Se provizanto reklamas unu, io ekster la tunelo akceptas ĝin.

Kion la servilo faras kun la ses ciferoj

Tempobazitaj kodoj sekvas RFC 6238, kiu envolvas la pli malnovan konstruaĵon bazitan sur nombrilo el RFC 4226: HMAC super moviĝanta faktoro, defaŭlte tranĉita al ses ciferoj. Por TOTP la moviĝanta faktoro estas la nuna Unix-tempo dividita per paŝo, 30 sekundoj se la operatoro ne ŝanĝis ĝin. La kontrolilo neniam komparas viajn ciferojn kun konservita valoro; ĝi rekalkulas la atendatan kodon el la komuna semo kaj kutime akceptas ankaŭ la najbarajn paŝojn, do malrapida rondvojaĝo ne malsukcesigas la enskribiĝon.

Du sekvoj estas preteratentataj. La horzono de la telefono ne gravas, ĉar la semo neniam vidas lokan horloĝon — gravas nur la devio de la reala UTC, kaj aparato, kiu rapidas du minutojn, malsukcesas ĉe ĉiu kodo dum ĝi montras puran retronombradon. Kaj kodo estas unufoja laŭ konstruo: la kontrolilo memoras la lastan nombrilan valoron, kiun ĝi akceptis por tiu semo, do la samaj ciferoj senditaj denove estas rifuzataj eĉ ene de la sama fenestro. Kliento, kiu reprovas post tempolimo, povas forbruligi la kodon, kiun ĝi ĵus sendis.

Nombrilbazitaj ĵetonoj movas sian nombrilon ĉe ĉiu premado, do ili perdas sinkronon post kiam kodoj estas generitaj sed neniam senditaj; la kutima riparo estas resinkroniga fenestro, kiu akceptas kelkajn valorojn antaŭen. Se la operatoro registris HOTP kaj via aplikaĵo montras TOTP, ĉiu valoro estas malĝusta tiel, ke ĝi aspektas kiel horloĝa problemo. La proviza URI malantaŭ la QR-kodo nomas la tipon, ciferojn, periodon kaj haŝon.

Malsukcesoj, kiuj aspektas kiel malĝusta kodo

La registrita ero estas la plej ofta kaŭzo. Aŭtentikigaj aplikaĵoj etikedas erojn laŭ eldoninto kaj konto, do iu kun du identecoj ĉe la sama VPN povas fini kun du eroj, kies etikedoj diferencas per unu signo. Kodo validas por la semo, kiu generis ĝin, kaj por nenio alia. Komparu la etikedon sur la telefono kun la uzantnomo, kiun la servilo registras, ne kun tio, kion vi memoras, ke vi tajpis.

Due, parametraro, kiu ne kongruas. Semo registrita kun ok ciferoj, periodo de 60 sekundoj aŭ SHA-256 donas kodojn, kiujn kontrolilo atendanta ses ciferojn, 30 sekundojn kaj SHA-1 rifuzas, kaj ĉe la kliento tio ne distingiĝas de malĝusta kodo. Ĝi aperas post migradoj, kie la ero estis denove aldonita el foto de la QR-kodo, aŭ kie la ĵetona rikordo estis rekonstruita kun defaŭltaj valoroj.

Trie, temas ne pri la kodo. Pordegoj kutime redonas unu ĝeneralan aŭtentikigan malsukceson por malĝusta pasvorto, eksvalidiĝinta kodo kaj malŝaltita konto, intence, por ke neniu povu sondi, kiu faktoro malsukcesis. Legu la protokolon de la pordego aŭ de RADIUS anstataŭ la klientan rubandon: defio neniam eldonita, alirrifuzo sen OTP-atributo kaj politika rifuzo ĉiuj aspektas same sur la ekrano kaj kondukas al malsamaj sekvaj paŝoj.

Mallonga sinsekvo, kiu mallarĝigas ĝin

Komencu per la plej malmultekosta kontrolo kaj haltu ĉe la unua paŝo, kiu ne teniĝas.

1. Atendu freŝan kodon, sendu ĝin unufoje, kaj notu, ĉu la defio aperas antaŭ aŭ post la akcepto de la pasvorto.
2. Kongruigu la etikedon en la aŭtentikigilo kun la uzantnomo, kiun la servilo konservas.
3. Konfirmu, ke la profilo entute povas respondi defion, kiel en la kazo CRV1 supre.
4. Komparu la horloĝon de la aparato kun konata tempa fonto; devio pli ol kelkaj dekduoj da sekundoj rompas TOTP per si mem.
5. Demandu la operatoron, ĉu la ĵetono estas TOTP aŭ HOTP, kaj kiuj ciferoj, periodo kaj haŝo estis registritaj.

Du reguloj malhelpas, ke tio plimalbonigu la situacion. Ne reprovu multajn fojojn: multaj pordegoj kalkulas malsukcesojn por konto kaj aŭ ŝlosas ĝin aŭ komencas prokrasti respondojn, do salvo transformas malgrandan misagordon en subtenan bileton. Kaj ne reregistru la ĵetonon kiel diagnozon, ĉar tio malvalidigas la malnovan semon; se la reala misfunkcio estis defio, kiun la kliento neniam sendis, vi nun havas du ŝanĝojn por klarigi anstataŭ unu.

Tenu la semon kaj la rehavajn kodojn ekster la ciklo

La ses ciferoj kaj la sekreto malantaŭ ili ne estas interŝanĝeblaj. Proviza QR-kodo aŭ Base32-semo generas ĉiun estontan kodon por la konto, do ĝi apartenas al la sama kategorio kiel la pasvorto: ne en ekrankopio, ne en bileta komento, ne en babilejo kun iu, kiu kontaktis vin unue. Rehavaj kodoj estas aparta mekanismo — unufojaj, ofte tute preterlasas la kodpeton, kaj elspezi unu por testi la konton forigas rezervan vojon, kiun vi eble bezonos poste.

Kodo ankaŭ ne igas enskribiĝan paĝon fidinda: OTP-peto sur similaspekta domajno kolektas validan kodon kaj reludas ĝin ene de la fenestro, kaj la atestilo ankoraŭ estas tio, kio diras al vi, kie vi tajpas.

Se la sinsekvo finiĝas ĉe profilo, kiu ne povas respondi defion, riparu la profilon kaj retestu per unu freŝa kodo. Se ĝi finiĝas ĉe neakordigeblaj registraj parametroj, petu la operatoron legi la ĵetonan rikordon antaŭ ol iu ajn skanu ion. Se ĝi finiĝas ĉe ŝloso, atendu ĝin anstataŭ ŝanĝi klientojn — la konta stato estas la baro, ne la aplikaĵo.