Два запроса пароля — ещё не MFA: что проверяет вход в VPN

Страница входа просит пароль, затем второй секрет, и развёртывание сразу описывают как многофакторное. Иногда так и есть. Часто это один фактор, собранный дважды, потому что оба значения — знания, которые один и тот же человек набрал из одной и той же памяти или одной и той же заметки. Стойкий шифр туннеля этого не меняет, и слово «безопасный» в названии продукта тоже.

Отделить заявление от механизма позволяет один вопрос: что доказывает каждый шаг и кому?

Фактор — это доказательство, а не поле

Многофакторная аутентификация означает, что для одной и той же учётной записи проверяется более одного различного вида доказательств: то, что пользователь знает, то, чем он владеет, то, чем он является. Два поля, которые оба собирают запомненную строку, — это один вид доказательства, запрошенный дважды. Это может быть полезной мерой контроля, поскольку два независимых секрета угадать труднее, чем один, но это не то, что описывает термин, и в оценке рисков это не должно считаться таковым.

Сторона проверки не менее важна, чем сторона сбора. Код, сгенерированный на устройстве, доказывает контроль над этим устройством лишь в том случае, если сервер сверяет его с секретом, привязанным к этой учётной записи, и отклоняет повторы. Общий код, который работает для всех, код без ограничения попыток или запрос, одобренный на устройстве, которое никогда не показывает, что именно одобряется, — всё это слабее, чем подразумевает ярлык.

Поэтому когда кто-то спрашивает, есть ли у VPN MFA, спросите, что доказывает второй шаг и как сервер его привязывает. Если ответ — «второй пароль из того же каталога», у вас один фактор и разговор о политике, а не второй фактор.

Случай с сертификатом нужно читать, а не предполагать

Клиентский сертификат плюс пароль выглядят как два фактора, и это может быть так: сертификат хранится в хранилище или на токене, а пароль запоминается. Это может быть и один, если файл сертификата лежит без защиты в том же каталоге профиля, что и сохранённый пароль, или если сертификат выдан устройству, которым несколько человек пользуются без индивидуальной ответственности.

Вопрос, который нужно решить, — кого или что идентифицирует сертификат. Сертификат устройства доказывает, что управляемая машина присутствует. Пользовательский сертификат доказывает личность. Если развёртывание выдаёт по сертификату на ноутбук, а затем трактует его наличие как доказательство личности, второй фактор тихо стал свойством аппаратуры, которое наследует любой, кто держит этот ноутбук.

Ничто из этого не делает сертификаты плохой идеей. Это делает различие между гарантией устройства и гарантией пользователя достойным записи, потому что оба отвечают на разные вопросы, а таблица соответствия, которая считает их одним, завысит то, что защищено.

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

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

Поэтому выбор метода меняет результат сильнее, чем формулировка запроса. Коды, которые набирает человек, может передать любой, кто способен показать убедительную страницу, тогда как криптографические методы, привязывающие аутентификацию к конкретному источнику и сеансу, противостоят такой передаче по замыслу. Что именно у вас — свойство метода, а не число шагов в диалоге.

Следуйте поддерживаемому поставщиком порядку регистрации и клиентскому сценарию, а не прикручивайте дополнительный запрос к полю пароля. Самодельный второй шаг обычно оказывается где-то посередине, добавляя трение без привязки, которая делает фактор осмысленным.

Восстановление — вторая входная дверь

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

Спросите, как работает замена, кто её утверждает и какие доказательства требуют. Затем проверьте, что материал восстановления, например резервные коды, хранится отдельно от основного учётного данного, чтобы одна компрометация не отдала оба. Рекомендации NIST по цифровой идентификации рассматривают привязку верификатора и жизненный цикл аутентификатора как часть требования, а не как операционную запоздалую мысль.

Что написать в оценке

Опишите факторы по видам, назовите, что доказывает каждый, и укажите, как он привязан к учётной записи. Отметьте, противостоит ли метод передаче, и опишите путь восстановления с той же тщательностью, что и вход.

Затем прямо скажите, является ли развёртывание многофакторным по этому определению. «Два пароля и сертификат машины» — честная фраза, и она сообщает читателю гораздо больше, чем галочка, которая говорит «да».