Ваш пароль VPN приватен ровно настолько, насколько приватен его проверяющий

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

Спрашивайте, кто завершает сеанс, а не шифруется ли сеанс.

Зашифрован для кого, если точно?

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

Сообщество OpenVPN документирует это прямо: auth-user-pass-verify передаёт представленные учётные данные скрипту или плагину проверки. Это намеренная передача между компонентами, и она входит в модель доверия как названная сторона.

Проверяющий видит пароль

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

Разные методы раскрывают разный материал. Аутентификация по сертификату доказывает закрытый ключ, не отправляя его, а федеративный поток может оставить пароль у поставщика идентичности, выдавая VPN ограниченное утверждение. Такие схемы сужают круг; ни одна из них не устраняет все доверенные стороны.

Сохранённые хеши защищают другой этап

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

Поэтому хорошо хешированное хранилище паролей и открытый скрипт проверки могут без противоречия сосуществовать в одном продукте.

Выбор метода, который сужает круг

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

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

Полезный вопрос не в том, зашифрован ли пароль, а в том, от кого он скрыт, какой компонент его получает и какая форма остаётся после.