MFA request sa VPN tinanggihan: ano ang dapat gawin ng kliyente

Ang tinanggihang MFA request ay mukhang problema sa network at hindi. Humingi ang server ng pangalawang factor, bumalik na negatibo ang factor o hindi dumating, at tinanggihan ang session bago pa man nagkaroon ng anumang tunnel. Ang susunod na mangyayari ay tanong ng pag-uugali ng kliyente: ilantad ang kabiguan at hayaang magsimula ang user ng malinis na pagtatangka, o ulitin sa mga paraang lumilikha ng mas maraming request at sa huli ay nagpapagana ng proteksyon ng account. Ang ikalawang landas ang paraan kung paano nagiging naka-lock na account ang isang maling na-type na code.

Suriin kung aling request ang nabigo

Magsimula sa pagkilala kung aling request ang nabigo. Ang push notification, TOTP code, FIDO assertion at SAML flow ay bawat isa ay nabigo nang iba, at karaniwang alam ng kliyente kung alin ang hiningi nito. Ang pagtanggi, nag-expire na challenge at bigong paghahatid na hindi umabot sa device ay lahat nagtatapos sa parehong generic na error, kaya ang estado ng kliyente mismo ang madalas na tanging lugar kung saan nananatili ang pagkakaiba.

Sulit na itala ang estadong iyon nang tumpak. Itala ang identifier ng challenge o reference ng transaksyon, uri ng factor, timestamp at resulta, ngunit huwag kailanman itala ang code o assertion. Ang identifier ng challenge ang nagpapahintulot sa administrator na mahanap ang kaganapan sa panig ng identity provider; kung wala ito, nagsisimula ang usapan sa suporta sa «kung saan sa nakaraang oras» at karaniwang doon nagtatapos. Tratuhin ito bilang diagnostic metadata, hindi bilang lihim.

Muling subukan nang isang beses, nang sadya, gamit ang bagong challenge

Ang muling pagtatangka ay dapat bagong pagtatangka na may bagong challenge, hindi pag-replay ng luma. Kapag ginamit muli ng kliyente ang nakaraang challenge, tinatanggihan ito ng identity provider bilang lipas o, mas malala, tinatanggap ang isang approval na para sa naunang pagtatangka. Humingi ng sariwang challenge, ipakita ito, at hayaang kumilos ang user sa isa na kasalukuyang nasa screen.

Dalawang pagtatangka na may maikling paghinto sa pagitan ang makatwirang default; ang walang hanggang loop ay hindi. Kung mabibigo ang ikalawang pagtatangka sa parehong paraan, huminto at mag-ulat sa halip na magpatuloy.

Ano ang hindi dapat gawin ng kliyente

Hindi dapat gawin ng kliyente ang ilang bagay na mukhang nakakatulong at hindi naman. Hindi dapat itong magpatuloy sa pagpapadala ng push notification hanggang may mag-tap ng «aprubahan», dahil tinuturuan nito ang mga user na aprubahan ang mga request na hindi nila sinimulan, at iyon ang eksaktong pag-uugaling inaasahan ng mga phishing kit. Hindi ito dapat bumalik sa mas mahinang factor dahil nabigo ang malakas, at hindi nito dapat i-disable ang server identity check para lampasan ang reklamo sa certificate na lumitaw sa parehong oras. Ang bawat isa sa tatlong shortcut na ito ay ginagawang insidente sa seguridad ang isang bigong authentication.

Hindi rin nito dapat lunukin ang kabiguan nang tahimik. Ang kliyenteng nagsasara ng koneksyon at nagpapakita ng spinner ay nag-iiwan sa user na walang ideya kung muling subukan, maghintay o tumawag sa suporta. Ipakita ang kabiguan kasama ang uri ng factor at maikling code, panatilihing walang lihim ang mensahe, at gawing tahasan ang aksyon ng muling pagtatangka sa halip na awtomatiko.

Kung ang request ay hindi sinimulan ng taong nasa keyboard, ang tamang aksyon ay iwanan itong tinanggihan at iulat sa pamamagitan ng beripikadong landas ng suporta. Ang aprubahan ang request para tumigil ang ingay ay ang pattern ng kabiguan, hindi ang lunas.

Ano ang itatala para sa suporta

Para sa suporta, ang kapaki-pakinabang na tala ay maliit. Ang tinatayang oras kasama ang time zone, account, kliyente at bersyon, uri ng factor, at hindi-lihim na kalagayan ng bawat pagtatangka: hiningi, tinanggihan, nag-expire, inaprubahan ngunit tinanggihan ng patakaran.

Bigyang-pansin din ang mga orasan ng kliyente at server. Ang TOTP ay pagsusuri sa time window, kaya ang device na naagapan ang orasan ay gumagawa ng mga code na mukhang wasto at bawat oras ay nabibigo, at ang kliyenteng nag-uulat ng di-wastong code nang hindi binabanggit ang pagkaagap ay nagpapadala ng mga tao para i-reset ang mga kredensyal na kailanman ay hindi mali. Ang user na paulit-ulit na nabigo sa pag-login ay dapat suriin ang sinusuportahang bersyon ng kliyente, katayuan ng enrollment at dokumentadong daloy ng pagbawi bago gumawa ng mas maraming request.

Ang landas ng pagbawi ay karapat-dapat sa parehong pag-aalaga gaya ng landas ng pag-login. Ang workflow para sa nawawalang device ay umiiral nang eksakto upang ang pagtanggi ay hindi maging pahintulot na laktawan ang authentication, at dapat i-link ng kliyente ang dokumentadong proseso ng organisasyon sa halip na mag-imbento ng sarili.

Ang tuntuning dapat pagtayuan ay ang pagtanggi ay resulta, hindi hadlang. Iulat ito nang isang beses, nang malinaw, may sapat na konteksto para kumilos, at hayaang bago ang susunod na pagtatangka. Ang gabay ng CISA tungkol sa MFA na lumalaban sa phishing ay nagpapaliwanag kung bakit mapanganib na simula pa lamang ang pattern na «magtanong hanggang maaprubahan», at iyon ang sangguniang sulit banggitin kapag may nagmungkahi ng loop ng muling pagtatangka. Lahat ng idinadagdag ng kliyente pagkatapos ng pagtanggi ay dapat gawing mas madali para sa tao ang susunod na desisyon, hindi bawiin ang desisyon sa kanila.