Заявка за MFA във VPN е отхвърлена: какво трябва да направи клиентът

Отхвърлената MFA заявка изглежда като мрежов проблем, но не е. Сървърът поиска втори фактор, факторът се върна отрицателен или така и не пристигна, и сесията беше отказана, преди да съществува какъвто и да е тунел. Това, което се случва след това, е въпрос на поведение на клиента: да покаже отказа и да остави потребителя да започне чист опит, или да повтаря по начини, които генерират още заявки и в крайна сметка задействат защитата на акаунта. Вторият път е как един сгрешен код се превръща в заключен акаунт.

Проверете коя заявка е неуспешна

Започнете с това да установите коя заявка е неуспешна. Push известие, TOTP код, FIDO удостоверение и SAML поток се провалят по различен начин и клиентът обикновено знае кой от тях е поискал. Отказ, изтекло предизвикателство и неуспешна доставка, която така и не е стигнала до устройството, всички завършват с една и съща обща грешка, затова състоянието на самия клиент често е единственото място, където разликата оцелява.

Това състояние си струва да се записва точно. Запишете идентификатора на предизвикателството или референцията на транзакцията, типа на фактора, времевата марка и резултата, но никога кода или удостоверението. Идентификаторът на предизвикателството е това, което позволява на администратора да намери събитието от страна на доставчика на идентичност; без него разговорът с поддръжката започва с „някъде през последния час“ и обикновено там приключва. Отнасяйте се към него като към диагностични метаданни, а не като към тайна.

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

Повторният опит трябва да е нов опит с ново предизвикателство, а не повторно изпълнение на старото. Когато клиентът използва отново предишното предизвикателство, доставчикът на идентичност или го отхвърля като остаряло, или, което е по-лошо, приема одобрение, предназначено за по-ранния опит. Поискайте ново предизвикателство, покажете го и оставете потребителя да действа по това, което е на екрана в момента.

Два опита с кратка пауза между тях са разумна настройка по подразбиране; неограничен цикъл не е. Ако вторият опит се провали по същия начин, спрете и докладвайте, вместо да продължавате.

Какво клиентът не бива да прави

Клиентът не бива да прави няколко неща, които изглеждат полезни, а не са. Не бива да продължава да изпраща push известия, докато някой не натисне „одобрявам“, защото това приучава потребителите да одобряват заявки, които не са започнали, и това е точно поведението, на което разчитат фишинг комплектите. Не бива да отстъпва към по-слаб фактор, защото силният се е провалил, и не бива да изключва проверката на самоличността на сървъра, за да заобиколи оплакване за сертификат, появило се по същото време. Всяка от тези три кратки пътеки превръща неуспеха на удостоверяването в инцидент по сигурността.

Също така не бива да поглъща отказа мълчаливо. Клиент, който затваря връзката и показва въртящ се индикатор, оставя потребителя без представа дали да опита отново, да изчака или да се обади на поддръжката. Покажете отказа с типа на фактора и кратък код, дръжте съобщението без тайни и направете действието за повторен опит явно, а не автоматично.

Ако заявката не е започната от човека пред клавиатурата, правилното действие е да я оставите отхвърлена и да я докладвате по проверения път за поддръжка. Одобряването на заявка, за да спре шумът, е моделът на провала, а не поправката.

Какво да запишете за поддръжката

За поддръжката полезният запис е малък. Приблизителното време с часовата зона, акаунтът, клиентът и версията, типът на фактора и несекретният статус на всеки опит: поискан, отказан, изтекъл, одобрен, но отхвърлен от политика.

Дръжте под око и часовниците на клиента и сървъра. TOTP е проверка на времеви прозорец, затова устройство с изместен часовник произвежда кодове, които изглеждат валидни и се провалят всеки път, а клиент, който съобщава за невалиден код, без да отбележи изместването, изпраща хората да нулират идентификационни данни, които никога не са били грешни. Потребител, чийто вход се проваля многократно, трябва да провери поддържаната версия на клиента, състоянието на записването и документирания поток за възстановяване, преди да генерира още заявки.

Пътят за възстановяване заслужава същото внимание като пътя за вход. Процес за изгубено устройство съществува именно за да не се превърне отказът в разрешение за заобикаляне на удостоверяването, и клиентът трябва да дава връзка към документирания процес на организацията, вместо да измисля свой.

Правилото, срещу което да се изгражда, е, че отказът е резултат, а не пречка. Докладвайте го веднъж, ясно, с достатъчно контекст за действие, и оставете следващият опит да бъде нов. Указанията на CISA за MFA, устойчива на фишинг обясняват защо моделът „питай до одобрение“ е опасен по начало, и това е препратката, която си струва да се цитира, когато някой предложи цикъл от повторни опити. Всичко, което клиентът добавя след отказ, трябва да прави следващото решение по-лесно за човека, а не да отнема решението от него.