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

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

Започнете от подканата, която клиентът ви действително показва

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

Преброете полетата, които действително са ви дадени. Едно поле за потребителско име плюс едно маскирано поле е обикновен вход с парола без никакво предизвикателство. Второ поле, което се появява след паролата, със свой собствен етикет, е клиентът, който реализира взаимодействието с предизвикателството.

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

Какво сървърът трябва вече да поддържа

Профилът описва какво клиентът трябва да събере. Той не включва проверка на сървъра и сървър без съответната интеграция за удостоверяване просто ще получи парола, която не разпознава. Затова някои разгръщания показват подканата и отхвърлят всеки код и затова отговорът на оператора кой механизъм извършва проверката е този, който има значение.

Попитайте оператора кой механизъм извършва проверката. Това може да е плъгин, който говори с PAM, скриптов hook, който проверява отговора срещу услуга за токени, или интеграция, базирана на управление, която сама анализира опакованата стойност. Всеки от тях очаква малко по-различен вход.

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

Кодираното поле, което изпраща интерфейсът за управление

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

Base64 е кодиране, не защита. То не скрива нищо от този, който може да прочете полето, и не превръща еднократен код в нещо за многократна употреба. Опакованата стойност заслужава същото отношение като парола: извън споделени профили, извън командни редове и извън диагностични журнали.

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

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

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

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

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

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

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

След това повторете връзката след повторно свързване, с акаунт, който не е регистриран, и през клиента, който вашите потребители действително използват. Появата на подканата е поведение на клиента; отказът на грешен код е сървърът, който налага нещо.