Dalawang kahilingan ng password ay hindi MFA: ano ang tinitiyak ng pag-log in sa VPN

Ang pahina ng pag-log in ay humihingi ng password, pagkatapos ng ikalawang lihim, at agad na inilalarawan ang deployment bilang multifactor. Minsan ay totoo ito. Kadalasan ito ay isang salik na kinolekta nang dalawang beses, dahil ang dalawang halaga ay kaalamang tina-type ng parehong tao mula sa parehong memorya o parehong tala. Hindi ito binabago ng malakas na cipher ng tunel, at hindi rin ng salitang „secure“ sa pangalan ng produkto.

Ang paghihiwalay ng pahayag sa mekanismo ay nangangailangan ng isang tanong: ano ang pinapatunayan ng bawat hakbang, at kanino?

Ang salik ay patunay, hindi patlang

Ang multifactor authentication ay nangangahulugang mahigit isang magkaibang uri ng patunay ang tinitiyak para sa parehong account: isang bagay na alam ng gumagamit, isang bagay na hawak niya, isang bagay na siya. Ang dalawang patlang na parehong kumokolekta ng natatandaang string ay isang uri ng patunay na hinihingi nang dalawang beses. Maaaring ito ay kapaki-pakinabang na kontrol, dahil ang dalawang malayang lihim ay mas mahirap hulaan kaysa isa, ngunit hindi ito ang inilalarawan ng termino at hindi dapat bilangin nang ganoon sa pagtatasa ng panganib.

Ang panig ng pagpapatunay ay kasinghalaga ng panig ng pagkolekta. Ang code na nabuo sa isang device ay nagpapatunay ng kontrol sa device na iyon lamang kung sinusuri ito ng server laban sa lihim na nakatali sa account na ito at tinatanggihan ang mga pag-uulit. Ang shared code na gumagana para sa lahat, code na walang limitasyon, o prompt na inaprubahan sa device na hindi kailanman nagpapakita kung ano ang inaprubahan ay lahat mas mahina kaysa ipinahihiwatig ng label.

Kaya kapag may nagtanong kung may MFA ang VPN, itanong kung ano ang pinapatunayan ng ikalawang hakbang at paano ito itinatali ng server. Kung ang sagot ay „ikalawang password mula sa parehong direktoryo“, mayroon kang isang salik at usapan tungkol sa patakaran, hindi ikalawang salik.

Ang kaso ng sertipiko ay kailangang basahin, hindi ipagpalagay

Ang sertipiko ng kliyente kasama ng password ay mukhang dalawang salik, at maaaring ganoon nga: ang sertipiko ay nasa imbakan o sa token, at ang password ay natatandaan. Maaari rin itong isa, kung ang file ng sertipiko ay nasa parehong direktoryo ng profile gaya ng naka-save na password nang walang proteksyon, o kung ang sertipiko ay inisyu sa device na pinagsasaluhan ng ilang tao nang walang indibidwal na pananagutan.

Ang tanong na kailangang lutasin ay kung sino o ano ang kinikilala ng sertipiko. Ang sertipiko ng device ay nagpapatunay na may managed machine na naroroon. Ang sertipiko ng gumagamit ay nagpapatunay ng pagkakakilanlan. Kung ang deployment ay naglalabas ng isang sertipiko bawat laptop at pagkatapos ay itinuturing ang presensya nito bilang patunay ng tao, ang ikalawang salik ay tahimik na naging katangian ng hardware na minamana ng sinumang humahawak ng laptop.

Wala sa mga ito ang gumagawa sa mga sertipiko na masamang ideya. Ginagawa nitong karapat-dapat isulat ang pagkakaiba ng assurance ng device at assurance ng gumagamit, dahil magkaiba ang sinasagot ng dalawa at ang spreadsheet ng pagsunod na binibilang sila bilang isa ay magpapalabis sa kung ano ang protektado.

Ang pagtitiwala sa gateway at pagtitiwala sa gumagamit ay magkaibang problema

Hindi ginagawang ligtas ng ikalawang salik ang pag-type ng mga kredensyal sa endpoint na hindi mo pa napapatunayan. Kailangang makilala ng kliyente ang nilalayong gateway, at para doon ang sertipiko ng server at ang configuration ng pagtitiwala ng kliyente. Gumagana ang phishing sa pamamagitan ng paglilipat ng pag-log in sa server na kontrolado ng attacker, at ang tamang one-time code na inilagay doon ay ipinapasa lamang sa tunay na serbisyo sa real time.

Iyon ang dahilan kung bakit binabago ng pagpili ng pamamaraan ang resulta nang higit kaysa sa mga salita ng kahilingan. Ang mga code na tina-type ng tao ay maaaring ipasa ng sinumang makapagpapakita ng kapani-paniwalang pahina, samantalang ang mga cryptographic na pamamaraan na nagtatakda ng authentication sa partikular na pinagmulan at session ay lumalaban sa pagpapasang iyon sa pamamagitan ng disenyo. Alin sa dalawa ang mayroon ka ay katangian ng pamamaraan, hindi bilang ng mga hakbang sa dialog.

Sundin ang sinusuportahang pagpaparehistro at daloy ng kliyente ng vendor sa halip na magkabit ng karagdagang kahilingan sa patlang ng password. Ang gawang-bahay na ikalawang hakbang ay kadalasang lumalapag sa gitna, nagdaragdag ng alitan nang walang pagkakatali na nagbibigay-kahulugan sa salik.

Ang pagbawi ay ang ikalawang harapang pinto

Ang bawat matibay na pag-log in ay may daan pabalik kapag nawala ang authenticator, at iyon ang daang kadalasang pinakamahina sa disenyo. Kung ang ahente ng suporta ay makapag-reset ng ikalawang salik pagkatapos ng tawag sa numerong nakatala, ang pinakamurang ruta para sa attacker ay ang help desk, hindi ang pahina ng pag-log in.

Itanong kung paano gumagana ang pagpapalit, sino ang nag-aapruba at anong ebidensya ang hinihingi. Pagkatapos ay tiyakin na ang materyal ng pagbawi gaya ng backup codes ay nakaimbak nang hiwalay sa pangunahing kredensyal, upang ang isang paglabag ay hindi magbigay ng pareho. Itinuturing ng gabay ng NIST sa digital na pagkakakilanlan ang pagtali ng verifier at ang lifecycle ng authenticator bilang bahagi ng pangangailangan, hindi bilang operasyonal na pag-iisip pagkatapos.

Ano ang isusulat sa pagtatasa

Ilarawan ang mga salik ayon sa uri, pangalanan kung ano ang pinapatunayan ng bawat isa at sabihin kung paano ito nakatali sa account. Itala kung lumalaban ang pamamaraan sa pagpapasa, at ilarawan ang daan ng pagbawi nang may parehong pag-iingat gaya ng pag-log in.

Pagkatapos ay sabihin nang tahasan kung ang deployment ay multifactor ayon sa kahulugang iyon. „Dalawang password at isang sertipiko ng makina“ ay isang tapat na pangungusap, at mas maraming sinasabi ito sa mambabasa kaysa sa checkbox na nagsasabing oo.