Kwa nini msimbo halali wa matumizi ya mara moja bado unashindikana kwenye kuingia VPN

Unafungua kifaa cha VPN, unaandika nenosiri, na tarakimu sita kutoka kifaa chako cha uthibitishaji zinarudi kama batili — mara mbili, kisha mara ya tatu. Hakuna kilichobadilika kwenye akaunti tangu jana, kwa hiyo hisia ya kwanza ni kufuta ingizo kwenye kifaa cha uthibitishaji na kuliskani upya — kwa kawaida hilo ni urekebishaji usiofaa. Msimbo wa matumizi ya mara moja si nenosiri la pili: lango lazima liuombe katika hatua maalum, kutoka ingizo lililosajiliwa maalum, ndani ya dirisha maalum, na kukataliwa kwingi hutokea kabla tarakimu hazijalinganishwa. Tambua uko katika hatua gani kabla ya kugusa usajili.

Mpangilio wa maombi unakuambia uko katika mtiririko gani

Maumbo matatu hufunika karibu kila kuingia VPN kunakohusisha msimbo. Katika umbo la hatua mbili mteja hutuma nenosiri, seva hutoa changamoto, na mteja huuliza tena. Katika umbo la pamoja lango hutaka nenosiri na msimbo katika uwasilishaji mmoja — wakati mwingine zimeunganishwa, wakati mwingine baada ya kitenganishi ambacho mwendeshaji pekee hukiandika. Katika umbo la kivinjari mteja hana sehemu yoyote: msimbo unaingia kwenye ukurasa wa wavuti, au idhini ya msukumo huichukua nafasi, na mteja wa kompyuta husubiri matokeo.

Umbo lisilofaa huonekana kama msimbo mbaya. Bandika msimbo mpya kwenye sehemu ya nenosiri pekee, na seva itausoma kama sehemu ya nenosiri. Upande wa mteja, OpenVPN 2.4 na zaidi hufanya tofauti ionekane: seva inayojibu kwa AUTH_FAILED,CRV1: inatarajia jibu la changamoto, kwa hiyo profaili inahitaji static-challenge au faili la nenosiri katika umbo la SCRV1:. Profaili ya zamani inayobeba auth-user-pass pekee huthibitisha nenosiri kisha husimama, jambo ambalo kwenye kumbukumbu huonekana kama kushindikana kwa OTP ingawa hakuna msimbo uliotumwa.

WireGuard inafaa kutajwa kama isipokuwa: huthibitisha jozi za funguo, si watu, kwa hiyo hakuna sehemu ya msimbo. Iwapo mtoa huduma atatangaza moja, ni kitu nje ya handaki kinachokikubali.

Seva hufanya nini na tarakimu sita

Misimbo inayotegemea muda hufuata RFC 6238, ambayo hufunika muundo wa zamani unaotegemea kihesabu kutoka RFC 4226: HMAC juu ya kipengele kinachosogea, kikikatwa hadi tarakimu sita kwa chaguo-msingi. Katika TOTP kipengele kinachosogea ni muda wa Unix wa sasa ukigawanywa kwa hatua, sekunde 30 isipokuwa mwendeshaji ameibadilisha. Kithibitishaji hakiwahi kulinganisha tarakimu zako na thamani iliyohifadhiwa; huhesabu upya msimbo unaotarajiwa kutoka mbegu iliyoshirikiwa na kwa kawaida hukubali hatua jirani pia, kwa hiyo safari ya polepole haifanyi kuingia kushindikana.

Matokeo mawili hupuuzwa. Eneo la muda la simu halina umuhimu, kwa sababu mbegu haioni saa ya ndani kamwe — kupotoka kutoka UTC halisi pekee ndiko kunahusika, na kifaa kinachokwenda mbele kwa dakika mbili hushindikana kwa kila msimbo huku kikionyesha hesabu ya kushuka safi. Na msimbo ni wa matumizi ya mara moja kwa muundo: kithibitishaji hukumbuka thamani ya mwisho ya kihesabu iliyoikubali kwa mbegu hiyo, kwa hiyo tarakimu zilezile zinazowasilishwa tena hukataliwa hata ndani ya dirisha lilelile. Mteja anayejaribu tena baada ya muda kuisha anaweza kuchoma msimbo alioutuma hivi punde.

Ishara zinazotegemea kihesabu husogeza kihesabu chao kwa kila mbonyeo, kwa hiyo hutoka kwenye usawazishaji baada ya misimbo kuzalishwa lakini kutotumwa kamwe; urekebishaji wa kawaida ni dirisha la usawazishaji upya linalokubali thamani chache mbele. Iwapo mwendeshaji alisajili HOTP na programu yako inaonyesha TOTP, kila thamani si sahihi kwa namna inayofanana na tatizo la saa. URI ya utoaji nyuma ya msimbo wa QR huitaja aina, tarakimu, kipindi na heshi.

Kushindikana kunakoonekana kama msimbo mbaya

Ingizo lililosajiliwa ndilo lawama la kawaida zaidi. Programu za uthibitishaji huweka lebo kwenye ingizo kwa mtoaji na akaunti, kwa hiyo yeyote aliye na utambulisho miwili kwenye VPN moja anaweza kuishia na ingizo mbili ambazo lebo zake hutofautiana kwa herufi moja. Msimbo ni halali kwa mbegu iliouzalisha na si kwa kingine chochote. Linganisha lebo kwenye simu na jina la mtumiaji ambalo seva huliandika, si na ule unaokumbuka kuwa uliandika.

La pili ni seti ya vigezo isiyolingana. Mbegu iliyosajiliwa na tarakimu nane, kipindi cha sekunde 60 au SHA-256 hutoa misimbo ambayo kithibitishaji kinachotarajia tarakimu sita, sekunde 30 na SHA-1 huikataa, na kwa mteja hilo haliwezi kutofautishwa na msimbo mbaya. Huonekana baada ya uhamishaji ambapo ingizo liliongezwa tena kutoka picha ya msimbo wa QR, au ambapo rekodi ya ishara ilijengwa upya kwa thamani chaguo-msingi.

La tatu halihusiani na msimbo. Lango kwa kawaida hurudisha kushindikana kwa uthibitishaji kwa jumla kwa nenosiri baya, msimbo ulioisha muda na akaunti iliyozimwa, kwa makusudi, ili mtu yeyote asiweze kuchunguza ni kipengele gani kilishindikana. Soma kumbukumbu ya lango au ya RADIUS badala ya bango la mteja: changamoto ambayo haikutolewa kamwe, kukataliwa kwa ufikiaji bila sifa ya OTP na kukataliwa kwa sera huonekana sawa kwenye skrini na hupelekea hatua tofauti zinazofuata.

Mfululizo mfupi unaoibana

Anza na ukaguzi wa bei ndogo zaidi na simama kwenye hatua ya kwanza isiyoshikilia.

1. Subiri msimbo mpya, utume mara moja, na uangalie kama changamoto inaonekana kabla au baada ya nenosiri kukubaliwa.
2. Oanisha lebo kwenye kithibitishaji na jina la mtumiaji ambalo seva huhifadhi.
3. Thibitisha kwamba profaili inaweza kujibu changamoto hata kidogo, kama katika kisa cha CRV1 hapo juu.
4. Linganisha saa ya kifaa na chanzo cha muda kinachojulikana; kupotoka kwa zaidi ya makumi kadhaa ya sekunde huvunja TOTP yenyewe.
5. Uliza mwendeshaji kama ishara ni TOTP au HOTP, na ni tarakimu, kipindi na heshi gani zilisajiliwa.

Kanuni mbili huzuia hili kuzidisha. Usijaribu tena mara nyingi: lango nyingi huhesabu kushindikana kwa kila akaunti na ama huifungia au huanza kuchelewesha majibu, kwa hiyo kipindi kimoja hubadilisha hitilafu ndogo ya usanidi kuwa tiketi ya msaada. Na usisajili upya ishara kama uchunguzi, kwa sababu hilo hubatilisha mbegu ya zamani; iwapo hitilafu ya kweli ilikuwa changamoto ambayo mteja hakuituma kamwe, sasa una mabadiliko mawili ya kueleza badala ya moja.

Weka mbegu na misimbo ya urejeshaji nje ya mzunguko

Tarakimu sita na siri iliyo nyuma yao haziwezi kubadilishana. Msimbo wa QR wa utoaji au mbegu ya Base32 huzalisha kila msimbo ujao wa akaunti, kwa hiyo ni wa kundi lilelile la nenosiri: si kwenye picha ya skrini, si kwenye maoni ya tiketi, na si kwenye gumzo na mtu aliyekuwasiliana naye kwanza. Misimbo ya urejeshaji ni utaratibu tofauti — ya matumizi ya mara moja, mara nyingi huruka ombi la msimbo kabisa, na kutumia mmoja kujaribu akaunti huondoa njia mbadala ambayo unaweza kuihitaji baadaye.

Msimbo pia haufanyi ukurasa wa kuingia kuwa wa kuaminika: ombi la OTP kwenye kikoa kinachofanana hukusanya msimbo halali na kuucheza tena ndani ya dirisha, na cheti bado ndicho kinachokuambia unaandika wapi.

Iwapo mfululizo unaishia kwenye profaili isiyoweza kujibu changamoto, rekebisha profaili na ujaribu tena kwa msimbo mmoja mpya. Iwapo unaishia kwenye vigezo vya usajili visivyolingana, mwombe mwendeshaji asome rekodi ya ishara kabla ya mtu yeyote kuskani kitu. Iwapo unaishia kwenye kufungwa, subiri kumalizika badala ya kubadilisha wateja — kikwazo ni hali ya akaunti, si programu.