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

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

Почните од поруке коју ваш клијент заиста приказује

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

Избројте поља која сте заиста добили. Једно поље за корисничко име плус једно маскирано поље је уобичајена пријава лозинком без икаквог изазова. Друго поље које се појави после лозинке, са сопственом ознаком, је клијент који спроводи интеракцију изазова.

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

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

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

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

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

Кодирано поље које шаље сучеље за управљање

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

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

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

Статично против динамичког: различито време

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

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

Рад без надзора је место где то постаје питање дизајна, а не сучеља. Сачувани код није трајни акредитив за подизање система, а поновно повезивање сатима касније захтеваће свеж унос, осим ако распоређивање не подржава распоред токена који је оператер намерно омогућио.

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

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

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