VPN MFA pieprasījums noraidīts: kas klientam jādara

Noraidīts MFA pieprasījums izskatās pēc tīkla problēmas, bet tā nav. Serveris pieprasīja otru faktoru, faktors atgriezās noraidošs vai nekad nepienāca, un sesija tika noraidīta, pirms pastāvēja jebkurš tunelis. Tas, kas notiek tālāk, ir klienta uzvedības jautājums: parādīt kļūdu un ļaut lietotājam sākt tīru mēģinājumu, vai atkārtot tādos veidos, kas rada vairāk pieprasījumu un beigu beigās izraisa konta aizsardzību. Otrais ceļš ir tas, kā viens nepareizi ievadīts kods kļūst par bloķētu kontu.

Pārbaudiet, kurš pieprasījums neizdevās

Sāciet ar to, kura pieprasījums neizdevās, noteikšanu. Push paziņojums, TOTP kods, FIDO apliecinājums un SAML plūsma katrs neizdodas savādāk, un klients parasti zina, kuru no tiem pieprasīja. Noraidījums, beidzies izaicinājums un piegādes kļūda, kas nekad nesasniedza ierīci, visi beidzas ar vienu un to pašu vispārīgo kļūdu, tāpēc atšķirība bieži saglabājas tikai paša klienta stāvoklī.

Šo stāvokli ir vērts precīzi reģistrēt. Reģistrējiet izaicinājuma identifikatoru vai darījuma atsauci, faktora tipu, laika zīmogu un rezultātu, bet nekad kodu vai apliecinājumu. Izaicinājuma identifikators ir tas, kas ļauj administratoram atrast notikumu identitātes nodrošinātāja pusē; bez tā atbalsta saruna sākas ar «kaut kad pēdējās stundas laikā» un parasti tur arī beidzas. Uzskatiet to par diagnostikas metadatiem, nevis noslēpumu.

Mēģiniet vēlreiz vienreiz, apzināti, ar jaunu izaicinājumu

Atkārtotam mēģinājumam jābūt jaunam mēģinājumam ar jaunu izaicinājumu, nevis vecā atkārtojumam. Kad klients atkārtoti izmanto iepriekšējo izaicinājumu, identitātes nodrošinātājs to vai nu noraida kā novecojušu, vai, kas ir sliktāk, pieņem apstiprinājumu, kas bija paredzēts iepriekšējam mēģinājumam. Pieprasiet svaigu izaicinājumu, parādiet to un ļaujiet lietotājam rīkoties ar to, kas šobrīd ir ekrānā.

Divi mēģinājumi ar īsu pauzi starp tiem ir saprātīga noklusējuma vērtība; neierobežota cilpa nav. Ja otrais mēģinājums neizdodas tāpat, apstājieties un ziņojiet, nevis turpiniet.

Ko klientam nevajadzētu darīt

Klientam nevajadzētu darīt vairākas lietas, kas izskatās noderīgas un tādas nav. Tam nevajadzētu turpināt sūtīt push paziņojumus, līdz kāds pieskaras «apstiprināt», jo tas māca lietotājiem apstiprināt pieprasījumus, kurus viņi nav sākuši, un tieši uz šo uzvedību paļaujas phishing komplekti. Tam nevajadzētu atkāpties uz vājāku faktoru tāpēc, ka stiprais neizdevās, un nevajadzētu izslēgt servera identitātes pārbaudi, lai apietu sertifikāta sūdzību, kas parādījās tajā pašā laikā. Katrs no šiem trim īsceļiem pārvērš autentifikācijas kļūdu drošības incidentā.

Tam nevajadzētu arī klusējot norīt kļūdu. Klients, kas aizver savienojumu un rāda griezēju, atstāj lietotāju bez jebkādas nojausmas, vai mēģināt vēlreiz, gaidīt vai zvanīt atbalstam. Parādiet kļūdu ar faktora tipu un īsu kodu, turiet ziņojumu bez noslēpumiem un padariet atkārtošanas darbību skaidru, nevis automātisku.

Ja pieprasījumu neuzsāka persona pie tastatūras, pareizā darbība ir atstāt to noraidītu un ziņot par to pa pārbaudīto atbalsta ceļu. Pieprasījuma apstiprināšana, lai pārtrauktu troksni, ir kļūdas modelis, nevis risinājums.

Ko reģistrēt atbalstam

Atbalstam noderīgais ieraksts ir mazs. Aptuvenais laiks ar laika joslu, konts, klients un versija, faktora tips un katra mēģinājuma ne slepenais statuss: pieprasīts, noraidīts, beidzies, apstiprināts, bet politika noraidīja.

Ņemiet vērā arī klienta un servera pulksteņus. TOTP ir laika loga pārbaude, tāpēc ierīce ar novirzītu pulksteni ģenerē derīgus izskata kodus, kas katru reizi neizdodas, un klients, kas ziņo par nederīgu kodu, nenorādot novirzi, sūta cilvēkus atiestatīt akreditācijas datus, kas nekad nav bijuši nepareizi. Lietotājam, kura pieteikšanās atkārtoti neizdodas, pirms vairāk pieprasījumu ģenerēšanas jāpārbauda atbalstītā klienta versija, reģistrācijas stāvoklis un dokumentētā atkopšanas plūsma.

Atkopšanas ceļš ir pelnījis tādu pašu rūpību kā pieteikšanās ceļš. Darbplūsma pazudušai ierīcei pastāv tieši tāpēc, lai noraidījums nekļūtu par atļauju apiet autentifikāciju, un klientam vajadzētu saistīt ar organizācijas dokumentēto procesu, nevis izdomāt savu.

Noteikums, pret kuru jābūvē: noraidījums ir rezultāts, nevis šķērslis. Ziņojiet par to vienreiz, skaidri, ar pietiekamu kontekstu rīcībai, un ļaujiet nākamajam mēģinājumam būt jaunam. CISA norādījumi par phishing izturīgu MFA skaidro, kāpēc «jautāt, līdz apstiprina» modelis ir bīstams jau no paša sākuma, un tas ir avots, ko ir vērts citēt, kad kāds ierosina atkārtošanas cilpu. Viss, ko klients pievieno pēc noraidījuma, ir jāpadara cilvēkam nākamais lēmums vieglāks, nevis jāatņem viņam lēmums.