Захтев за MFA за VPN је одбијен: шта клијент треба да уради

Одбијен захтев за MFA изгледа као мрежни проблем и није. Сервер је затражио други фактор, фактор се вратио негативно или никада није стигао, и сесија је одбијена пре него што је постојао било какав тунел. Оно што се дешава затим је питање понашања клијента: показати неуспех и пустити корисника да започне чист покушај, или понављати на начине који стварају више захтева и на крају активирају заштиту налога. Други пут је како један погрешно унесен код постаје закључан налог.

Проверите који захтев није успео

Почните утврђивањем који захтев није успео. Push обавештење, TOTP код, FIDO тврдња и SAML ток не успевају сваки на другачији начин, и клијент обично зна који је затражио. Одбијање, истекао изазов и грешка у испоруци која никада није стигла до уређаја сви завршавају истом општом грешком, па разлика често преживљава само у стању самог клијента.

То стање вреди прецизно забележити. Забележите идентификатор изазова или референцу трансакције, тип фактора, временску ознаку и исход, али никада код или тврдњу. Идентификатор изазова је оно што омогућава администратору да пронађе догађај на страни добављача идентитета; без њега разговор са подршком почиње са „негде у последњем сату“ и обично се ту и завршава. Третирајте га као дијагностичке метаподатке, а не као тајну.

Покушајте поново једном, намерно, са новим изазовом

Понављање треба да буде нови покушај са новим изазовом, а не репродукција старог. Када клијент поново користи претходни изазов, добављач идентитета га или одбија као застарео или, што је горе, прихвата одобрење намењено претходном покушају. Затражите нови изазов, прикажите га и пустите корисника да делује на оном који је тренутно на екрану.

Два покушаја са кратком паузом између њих су разумно подразумевано понашање; неограничена петља није. Ако други покушај не успе на исти начин, зауставите се и пријавите уместо да наставите.

Шта клијент не сме да ради

Клијент не сме да ради неколико ствари које изгледају корисне, а нису. Не сме да настави да шаље push обавештења док неко не додирне „одобри“, јер то учи кориснике да одобравају захтеве које сами нису започели, и то је управо понашање на које се ослањају phishing комплети. Не сме да се врати на слабији фактор зато што јаки није успео, и не сме да искључи проверу идентитета сервера да би заобишао жалбу на сертификат која се појавила у исто време. Свака од те три пречице претвара неуспех аутентикације у безбедносни инцидент.

Не сме ни тихо да прогута неуспех. Клијент који затвори везу и прикаже индикатор који се окреће оставља корисника без представе да ли да покуша поново, сачека или позове подршку. Прикажите неуспех са типом фактора и кратким кодом, држите поруку без тајни и учините радњу поновног покушаја експлицитном уместо аутоматском.

Ако захтев није започео човек пред тастатуром, исправна радња је да остане одбијен и да се пријави преко провереног пута подршке. Одобравање захтева да би бука престала је образац неуспеха, не решење.

Шта забележити за подршку

За подршку, корисни запис је мали. Приближно време са временском зоном, налог, клијент и верзија, тип фактора и не-тајни статус сваког покушаја: затражено, одбијено, истекло, одобрено али одбијено политиком.

Држите на оку и сатове клијента и сервера. TOTP је провера временског прозора, тако да уређај са помереним сатом ствара кодове који изгледају важећи и не успевају сваки пут, а клијент који пријави неважећи код без помена помераја шаље људе да ресетују акредитиве које никада нису биле погрешне. Корисник чија пријава изнова не успева треба да провери подржану верзију клијента, стање регистрације и документовани ток опоравка пре него што створи више захтева.

Пут опоравка заслужује исту пажњу као пут пријаве. Радни ток за изгубљени уређај постоји управо зато да одбијање не постане дозвола за заобилажење аутентикације, и клијент треба да повеже документовани процес организације уместо да измишља свој.

Правило на коме треба градити је да је одбијање резултат, а не препрека. Пријавите га једном, јасно, са довољно контекста за деловање, и пустите да следећи покушај буде нов. Смернице CISA о MFA отпорној на phishing објашњавају зашто је образац „питај док се не одобри“ опасан од самог почетка, и то је извор који вреди цитирати када неко предложи петљу поновних покушаја. Све што клијент дода после одбијања треба да учини следећу одлуку лакшом за човека, а не да му одузме одлуку.