Два запити пароля — ще не MFA: що перевіряє вхід у VPN

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

Відокремити заяву від механізму дає змогу одне питання: що доводить кожен крок і кому?

Фактор — це доказ, а не поле

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

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

Тож коли хтось питає, чи має VPN MFA, запитайте, що доводить другий крок і як сервер його прив’язує. Якщо відповідь — «другий пароль із того самого каталогу», у вас один фактор і розмова про політику, а не другий фактор.

Випадок із сертифікатом треба читати, а не припускати

Клієнтський сертифікат плюс пароль виглядають як два фактори, і це може бути так: сертифікат зберігається у сховищі або на токені, а пароль запам’ятовується. Це може бути й один, якщо файл сертифіката лежить без захисту в тому самому каталозі профілю, що й збережений пароль, або якщо сертифікат видано пристрою, яким кілька людей користуються без індивідуальної відповідальності.

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

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

Довіра до шлюзу і довіра до користувача — різні проблеми

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

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

Дотримуйтеся підтримуваного постачальником порядку реєстрації та клієнтського сценарію, а не прикручуйте додатковий запит до поля пароля. Саморобний другий крок зазвичай опиняється десь посередині, додаючи тертя без прив’язки, яка робить фактор осмисленим.

Відновлення — другі вхідні двері

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

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

Що написати в оцінці

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

Потім прямо скажіть, чи є розгортання багатофакторним за цим визначенням. «Два паролі й сертифікат машини» — чесна фраза, і вона повідомляє читачеві значно більше, ніж прапорець, що каже «так».