Барањето за MFA на VPN е одбиено: што треба да направи клиентот

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

Проверете кое барање не успеа

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

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

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

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

Два обиди со кратка пауза меѓу нив се разумно стандардно однесување; неограничен циклус не е. Ако вториот обид не успее на ист начин, запрете и пријавете наместо да продолжите.

Што не смее клиентот да направи

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

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

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

Што да се запише за поддршката

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

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

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

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