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

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

Питайте, хто завершує сеанс, а не чи сеанс зашифровано.

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

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

Спільнота OpenVPN документує це прямо: auth-user-pass-verify передає подані облікові дані скрипту або плагіну перевірки. Це навмисна передача між компонентами, і вона входить до моделі довіри як названа сторона.

Перевіряльник бачить пароль

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

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

Збережені хеші захищають інший етап

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

Тому добре хешоване сховище паролів і відкритий скрипт перевірки можуть без суперечності співіснувати в одному продукті.

Вибір методу, який звужує коло

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

Запишіть сторону, яка отримує пароль, сторону, яка його перевіряє, і форму, у якій він зберігається. Ці три відповіді належать до профілю з'єднання, бо переживають будь-який конкретний тунель.

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