Запит MFA до VPN відхилено: що має зробити клієнт

Відхилений запит MFA виглядає як проблема мережі, але нею не є. Сервер запитав другий фактор, фактор повернувся негативним або не надійшов зовсім, і сеанс було відхилено ще до появи будь-якого тунелю. Подальше — питання поведінки клієнта: показати збій і дати користувачеві почати чисту спробу або повторювати так, що це породжує нові запити й зрештою вмикає захист облікового запису. Другий шлях — це те, як один неправильно введений код перетворюється на заблокований обліковий запис.

Перевірте, який запит не вдався

Почніть із визначення того, який запит не вдався. Push-повідомлення, код TOTP, твердження FIDO і потік SAML відмовляють кожен по-своєму, і клієнт зазвичай знає, що саме запитував. Відмова, прострочений виклик і збій доставки, що так і не дійшов до пристрою, закінчуються однією й тією ж загальною помилкою, тому різниця часто зберігається лише в стані самого клієнта.

Цей стан варто записувати точно. Зафіксуйте ідентифікатор виклику або посилання на транзакцію, тип фактора, позначку часу й результат, але ніколи — код або твердження. Ідентифікатор виклику дає змогу адміністратору знайти подію на боці постачальника ідентичності; без нього розмова з підтримкою починається зі слів «десь за останню годину» і зазвичай там же закінчується. Ставтеся до нього як до діагностичних метаданих, а не як до секрету.

Повторіть один раз, свідомо, з новим викликом

Повторна спроба має бути новою спробою з новим викликом, а не відтворенням старого. Коли клієнт повторно використовує попередній виклик, постачальник ідентичності або відхиляє його як застарілий, або, що гірше, приймає підтвердження, призначене для попередньої спроби. Запросіть свіжий виклик, покажіть його й дайте користувачеві діяти щодо того, що зараз на екрані.

Дві спроби з короткою паузою між ними — розумне значення за замовчуванням; необмежений цикл — ні. Якщо друга спроба завершується так само, зупиніться й повідомте, а не продовжуйте.

Чого клієнт не повинен робити

Клієнт не повинен робити кілька речей, які виглядають корисними й такими не є. Він не повинен продовжувати надсилати push-повідомлення, доки хтось не натисне «схвалити», бо це привчає користувачів схвалювати запити, які вони не ініціювали, і саме на таку поведінку розраховують фішингові набори. Він не повинен переходити до слабшого фактора через те, що сильний не спрацював, і не повинен вимикати перевірку автентичності сервера, щоб обійти скаргу на сертифікат, яка виникла водночас. Кожен із цих трьох обхідних шляхів перетворює збій автентифікації на інцидент безпеки.

Він також не повинен мовчки проковтнути збій. Клієнт, який закриває з’єднання й показує індикатор завантаження, залишає користувача без розуміння, чи повторювати спробу, чекати чи телефонувати до підтримки. Покажіть збій із типом фактора й коротким кодом, тримайте повідомлення вільним від секретів і зробіть дію повторної спроби явною, а не автоматичною.

Якщо запит ініціював не людина за клавіатурою, правильна дія — залишити його відхиленим і повідомити про нього перевіреним каналом підтримки. Схвалення запиту, щоб припинити шум, — це модель збою, а не рішення.

Що записати для підтримки

Для підтримки корисний запис невеликий. Приблизний час із часовим поясом, обліковий запис, клієнт і версія, тип фактора й несекретний статус кожної спроби: запитано, відхилено, минув термін, схвалено, але відхилено політикою.

Тримайте в полі зору й годинники клієнта та сервера. TOTP — це перевірка часового вікна, тому пристрій із зсунутим годинником видає коди, що виглядають чинними й щоразу не проходять, а клієнт, який повідомляє про недійсний код, не згадуючи зсув, відправляє людей скидати облікові дані, які ніколи не були неправильними. Користувачеві, у якого вхід раз у раз не вдається, слід перевірити підтримувану версію клієнта, стан реєстрації й задокументований порядок відновлення, перш ніж створювати нові запити.

Шлях відновлення заслуговує такої ж турботи, як шлях входу. Сценарій для втраченого пристрою існує саме для того, щоб відмова не стала дозволом обійти автентифікацію, і клієнтові слід посилатися на задокументований процес організації, а не вигадувати свій.

Правило, під яке треба будувати: відмова — це результат, а не перешкода. Повідомте про неї один раз, ясно, з достатнім контекстом для дій, і нехай наступна спроба буде новою. Настанова CISA щодо стійкої до фішингу MFA пояснює, чому схема «питати до схвалення» небезпечна від самого початку, і саме на неї варто посилатися, коли хтось пропонує цикл повторних спроб. Усе, що клієнт додає після відмови, має полегшувати людині наступне рішення, а не забирати рішення в неї.