Каде оди кодот за статичен предизвик при најава на OpenVPN

Клиентот покажува второ поле по полето за лозинка, го внесувате кодот од хардверскиот токен, а најавата сѐ уште не успева со грешка при автентикација. Тоа поле постои, значи профилот го побарал. Дали серверот некогаш ја добил вредноста во форма што ја разбира е друго прашање, и токму на него прво треба да се одговори.

Започнете од поканата што вашиот клиент навистина ја покажува

Профилот може да носи директива за статичен предизвик со текст на покана и знаменце што контролира дали одговорот се прикажува додека пишувате. Поканата е она што го гледате во дијалогот; знаменцето е поставка за приказ за истиот внес. Ниту едно од двете не му кажува на серверот како да провери нешто.

Избројте ги полињата што навистина ви беа дадени. Едно поле за корисничко име плус едно маскирано поле е обична најава со лозинка без никаков предизвик. Второ поле што се појавува по лозинката, со своја ознака, е клиентот што ја спроведува интеракцијата на предизвикот.

Ако второто поле никогаш не се појави во клиентот што го користите, тој клиент можеби не ја спроведува интеракцијата, или ја спроведува само преку различен преден дел, како интерфејс за управување. Проверката на клиентот е поевтина од препишување на профилот, и обично токму таму е несовпаѓањето.

Што серверот веќе мора да поддржува

Профилот опишува што клиентот треба да собере. Тој не вклучува проверка на серверот, а сервер без соодветната интеграција за автентикација едноставно ќе добие лозинка што не ја препознава. Затоа некои распоредувања ја прикажуваат поканата и го одбиваат секој код, и затоа одговорот на операторот за тоа кој механизам ја врши проверката е одговорот што е важен.

Прашајте го операторот кој механизам ја врши проверката. Тоа може да биде додаток што зборува со PAM, скриптна кука што го проверува одговорот преку услуга за токени, или интеграција заснована на управување што самата ја разложува спакуваната вредност. Секој од нив очекува малку поинаков внес.

Тука треба да се калибрираат и очекувањата. Втората покана е механизам за внес, а не доказ дека се применува втор фактор, бидејќи применувањето се случува на страната на серверот и се гледа само кога тестирате погрешен код.

Кодираното поле што го праќа интерфејсот за управување

Кога предниот дел го води поврзувањето преку интерфејсот за управување, лозинката и одговорот на предизвикот се спакуваат во една вредност пред испраќањето. Упатството за интерфејсот за управување го документира форматот: префикс, потоа лозинката и одговорот како одделни Base64 компоненти.

Base64 е кодирање, не заштита. Тоа не крие ништо од оној што може да го прочита полето, и не претвора еднократен код во нешто што може повторно да се употреби. Спакуваната вредност заслужува ист третман како лозинката: надвор од споделени профили, надвор од командни линии и надвор од дијагностички дневници.

Тоа кодирање е и најчест извор на забуна, бидејќи сега постојат три форми што изгледаат слично и не се заменливи. Обична датотека со акредитиви содржи лозинка. Буквално спојување на лозинка и код содржи друга низа. Спакуван одговор на клиент за управување содржи трета. Потврдете која ја очекува вашата проверка пред да смените поле само затоа што грешката исчезна.

Статично наспроти динамично: различен момент

Статичниот предизвик е познат пред да се поднесат првите акредитиви, па клиентот може да го побара однапред. Динамичниот предизвик доаѓа подоцна, го праќа текот на автентикација откако размената веќе започнала, и му треба клиент што може да обработи барање среде разговор.

Поддршката на едното не ви го дава другото. Директива во профилот што поставува статична покана не спроведува предизвик инициран од серверот, а преден дел што обработува динамични барања може сѐ уште да не прикажува статичен. Читањето која страна го започнала барањето е најбрзиот начин да се разликуваат.

Работата без надзор е местото каде ова станува прашање на дизајн, а не на интерфејс. Зачуван код не е трајни акредитиви за подигање, и повторно поврзување по неколку часа ќе бара нов внес, освен ако распоредувањето не поддржува распоред на токени што операторот намерно го вклучил.

Тестирајте и успех и неуспех, не само дијалогот

Изведете ги двете половини од тестот. Точните акредитиви со валиден одговор треба да успеат; точните акредитиви со намерно погрешен одговор треба да бидат одбиени. Ако успеат двете, клиентот собира внес што ништо не го проверува, и дијалогот е заменет со контрола. Тој еден тест фаќа повеќе распоредувања од секое прегледување на профилот.

Потоа повторете го поврзувањето по повторно поврзување, со сметка што не е регистрирана, и преку клиентот што вашите корисници навистина го користат. Појавувањето на поканата е однесување на клиентот; одбивањето на погрешен код е серверот што нешто спроведува.