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

Разгледзьце чатыры пытанні пра любы ўваход у VPN: што абараняе пароль падчас перадачы, які кампанент яго атрымлівае, што гэты кампанент з ім робіць і што захоўваецца пасля. Кожны адказ — гэта асобная мера кантролю, і моцны адказ на адно пытанне нічога не кажа пра іншыя. Памылка — ставіцца да шыфравання тунеля так, быццам яно ахоплівае ўсе чатыры. Яно ахоплівае першае, і толькі першае.

Спытайце, хто завяршае сеанс, а не ці сеанс зашыфраваны.

Зашыфравана для каго, дакладна?

TLS абараняе пароль паміж кліентам і тым, хто завяршае злучэнне. Калі гэтая канцавая кропка — шлюз VPN, то код аўтэнтыфікацыі шлюза бачыць пароль у адкрытым выглядзе, правярае яго і перадае далей яго або вытворнае значэнне. Гэта прадугледжаная архітэктура, а не ўцечка. Назіральнік у сетцы на шляху не даведаецца нічога карыснага, а кампанент, які выконвае праверку, даведаецца ўсё, што яму трэба.

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

Правяральнік бачыць пароль

Пасля таго як кампанент атрымлівае пароль для праверкі, менавіта яго кантроль доступу, журналяванне і якасць кода вызначаюць, ці застанецца сакрэт унутры. Скрыпт, які запісвае ўліковыя даныя ў журнал, або плагін, які кэшуе іх, стварае значна большую экспазіцыю, чым стварыў пратакол. Доступ залежыць ад архітэктуры і роляў, а не ад тунеля, таму ўладальнік сэрвісу, які кантралюе правяральніка, належыць да ацэнкі.

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

Захаваныя хэшы абараняюць іншы этап

Рэкамендацыі NIST раздзяляюць абароненую перадачу і ўстойлівае захоўванне правяральніка. Саленне і схема хэшавання з выдаткамі вырашаюць пагрозу захаванага правяральніка — гэта тое, што адбываецца потым, калі база даных трапляе ў выцечку. Яны нічога не робяць для кампанента часу выканання, які павінен атрымаць увод, каб параўнаць яго. Чытаць рэкамендацыі так, быццам яны абяцаюць сакрэтнасць у час выканання, — гэта памылка катэгорыі.

Добра хэшаванае сховішча пароляў і адкрыты скрыпт праверкі могуць таму суіснаваць у адным прадукце без супярэчнасці.

Выбар метаду, які звужвае круг

Калі патрабаванне ў тым, каб шлюз ніколі не атрымліваў паўторна выкарыстоўваны пароль, выбірайце метад, які сапраўды гэта гарантуе; змена шыфра даных не стварае такой уласцівасці. Праверка сертыфіката сервера VPN паведамляе, да каго вы далучыліся; яна нічога не кажа пра тое, як гэты бок потым абыходзіцца з уліковымі данымі. Захоўвайце праверку сервера, выкарыстоўвайце асобныя ўліковыя даныя для кожнай паслугі і прытрымлівайцеся падтрыманага арганізацыяй патоку ідэнтычнасці.

Запішыце бок, які атрымлівае пароль, бок, які яго правярае, і форму, у якой ён захоўваецца. Гэтыя тры адказы належаць побач з профілем злучэння, бо яны перажываюць любы канкрэтны тунель.

Карыснае пытанне не ў тым, ці зашыфраваны пароль, а ад каго ён схаваны, які кампанент яго атрымлівае і якая форма застаецца пасля.