Вашата VPN парола е толкова лична, колкото е проверяващият ѝ

Разгледайте четири въпроса за всяко влизане във VPN: какво защитава паролата при пренос, кой компонент я получава, какво прави този компонент с нея и какво се съхранява след това. Всеки отговор е различен контрол и силният отговор на един въпрос не казва нищо за останалите. Грешката е да се отнасяме към шифроването на тунела, сякаш покрива и четирите. То покрива първия и само първия.

Питайте кой прекратява сесията, а не дали сесията е шифрована.

Шифрована за кого, точно?

TLS защитава паролата между клиента и това, което прекратява връзката. Ако тази крайна точка е VPN шлюзът, кодът за удостоверяване на шлюза вижда паролата в открит вид, проверява я и предава нататък нея или производна стойност. Това е предвиденият дизайн, а не изтичане. Мрежов наблюдател по пътя не научава нищо полезно, а компонентът, който извършва проверката, научава всичко, което му е нужно.

Общността на OpenVPN документира това изрично: auth-user-pass-verify предава подадените идентификационни данни на скрипт или плъгин за проверка. Това е умишлено предаване между компоненти и то принадлежи на модела на доверие като поименно посочена страна.

Проверяващият вижда паролата

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

Различните методи разкриват различен материал. Удостоверяването със сертификат доказва частен ключ, без да го изпраща, а федеративен поток може да задържи паролата при доставчика на идентичност, като издаде ограничено твърдение към VPN. Тези дизайни стесняват кръга; никой от тях не елиминира всички доверени страни.

Съхранените хешове защитават друг етап

Насоките на NIST разделят защитения пренос от устойчивото съхранение на проверяващия. Осоляването и схема за хеширане с цена се справят със заплахата от съхранен проверяващ — това е, което се случва след факта, ако база данни изтече. Те не правят нищо за компонент по време на изпълнение, който трябва да получи входа, за да го сравни. Да се четат насоките като обещание за тайна по време на изпълнение е категорийна грешка.

Добре хеширано хранилище за пароли и изложен скрипт за проверка следователно могат да съществуват заедно в един продукт без противоречие.

Избор на метод, който стеснява кръга

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

Запишете страната, която получава паролата, страната, която я проверява, и формата, в която се запазва. Тези три отговора принадлежат до профила на връзката, защото надживяват всеки конкретен тунел.

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