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

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

Пачніце з запыту, які кліент фактычна паказвае

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

Палічыце палі, якія вам фактычна далі. Адно поле для імя карыстальніка плюс адно замаскаванае поле — звычайны ўваход па паролі зусім без выкліку. Другое поле, якое з'яўляецца пасля пароля і мае свой подпіс, — гэта кліент, які рэалізуе ўзаемадзеянне выкліку.

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

Што сервер павінен ужо падтрымліваць

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

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

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

Кадаванае поле, якое дасылае інтэрфейс кіравання

Калі інтэрфейс кіруе злучэннем праз інтэрфейс кіравання, пароль і адказ на выклік пакуюцца ў адно значэнне перад адпраўкай. Даведка па інтэрфейсе кіравання апісвае фармат: прэфікс, затым пароль і адказ як асобныя кампаненты Base64.

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

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

Статычны супраць дынамічнага: розны час

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

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

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

Правярайце і поспех, і няўдачу, а не толькі дыялог

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

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