Зошто валиден еднократен код сѐ уште не успева при најава на VPN

Ја отворате VPN-клиентот, ја внесувате лозинката, и шесте цифри од автентикаторот се враќаат како невалидни — двапати, потоа трет пат. На сметката ништо не е сменето од вчера, така што првиот инстинкт е да го избришете записот во автентикаторот и повторно да го скенирате — обично тоа е погрешната поправка. Еднократниот код не е втора лозинка: портата мора да го побара во одреден чекор, од одреден регистриран запис, во одреден прозорец, и повеќето одбивања се случуваат пред цифрите да се споредат. Утврдете во кој чекор сте пред да ја допрете регистрацијата.

Редоследот на барањата покажува во кој тек сте

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

Погрешната форма изгледа како лош код. Залепете свеж код во поле само за лозинка и серверот ќе го прочита како дел од лозинката. На страната на клиентот, OpenVPN 2.4 и поновите верзии ја прават разликата видлива: сервер што одговара со AUTH_FAILED,CRV1: очекува одговор на предизвик, па профилот бара static-challenge или датотека со лозинка во форма SCRV1:. Постар профил што носи само auth-user-pass ја проверува лозинката и потоа застанува, што во дневникот изгледа како OTP неуспех иако не е пратен код.

WireGuard вреди да се спомене како исклучок: тој автентификува парови клучеви, а не луѓе, па нема поле за код. Ако давател рекламира таков, нешто надвор од тунелот го прифаќа.

Што прави серверот со шесте цифри

Временските кодови следат RFC 6238, кој ја обвиткува постарата конструкција со бројач од RFC 4226: HMAC над подвижен фактор, стандардно скратен на шест цифри. Кај TOTP подвижниот фактор е тековното Unix време поделено со чекор, 30 секунди освен ако операторот не го сменил. Проверувачот никогаш не ги споредува вашите цифри со зачувана вредност; тој го пресметува очекуваниот код од заедничкото семе и обично ги прифаќа и соседните чекори, така што бавното патување не ја руши најавата.

Две последици се пропуштаат. Временската зона на телефонот е неважна, бидејќи семето никогаш не гледа локален часовник — важна е само отстапката од вистинското UTC, а уредот што брза две минути не успева при секој код додека покажува чисто одбројување. И кодот е еднократен по дизајн: проверувачот ја памети последната вредност на бројачот што ја прифатил за тоа семе, па истите цифри поднесени повторно се одбиваат дури и во истиот прозорец. Клиентот што повторно ќе се обиде по истекот на времето може да го изгори кодот што штотуку го пратил.

Токените со бројач го поместуваат бројачот при секое притискање, па излегуваат од синхронизација откако кодовите се генерирани, но никогаш не се пратени; вообичаената поправка е прозорец за ресинхронизација што прифаќа неколку вредности напред. Ако операторот регистрирал HOTP, а вашата апликација покажува TOTP, секоја вредност е погрешна на начин што изгледа како проблем со часовникот. URI-то за обезбедување зад QR-кодот ги именува типот, цифрите, периодот и хешот.

Неуспеси што изгледаат како погрешен код

Регистрираниот запис е најчестиот виновник. Апликациите за автентикација ги означуваат записите по издавач и сметка, па секој што има два идентитета на истиот VPN може да заврши со два записи чии ознаки се разликуваат за еден знак. Кодот важи за семето што го генерирало и за ништо друго. Споредете ја ознаката на телефонот со корисничкото име што серверот го запишува, а не со она што се сеќавате дека сте го внеле.

Второ е несовпаѓачки сет параметри. Семе регистрирано со осум цифри, период од 60 секунди или SHA-256 дава кодови што проверувач што очекува шест цифри, 30 секунди и SHA-1 ги одбива, а кај клиентот тоа не може да се разликува од погрешен код. Се појавува по миграции каде записот е повторно додаден од фотографија на QR-кодот, или каде записот на токенот е повторно изграден со стандардни вредности.

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

Кратка низа што го стеснува

Започнете со најевтината проверка и застанете на првиот чекор што не држи.

1. Почекајте свеж код, поднесете го еднаш и забележете дали предизвикот се појавува пред или по прифаќањето на лозинката.
2. Споредете ја ознаката во автентикаторот со корисничкото име што серверот го чува.
3. Потврдете дека профилот воопшто може да одговори на предизвик, како во случајот CRV1 погоре.
4. Споредете го часовникот на уредот со познат извор на време; отстапка поголема од неколку десетици секунди сама го крши TOTP.
5. Прашајте го операторот дали токенот е TOTP или HOTP, и кои цифри, период и хеш се регистрирани.

Две правила спречуваат ова да го влоши. Не обидувајте се многу пати: многу порти бројат неуспеси по сметка и или ја заклучуваат, или почнуваат да ги одложуваат одговорите, па налетот претвора мала грешка во конфигурацијата во тикет за поддршка. И не регистрирајте го токенот повторно како дијагностика, бидејќи тоа го прави старото семе неважечко; ако вистинската дефект бил предизвик што клиентот никогаш не го пратил, сега имате две промени да објасните наместо една.

Држете го семето и кодовите за обновување надвор од кругот

Шесте цифри и тајната зад нив не се заменливи. QR-кодот за обезбедување или Base32 семето генерира секој иден код за сметката, па припаѓа на истата категорија како лозинката: не на слика од екран, не во коментар на тикет, не во разговор со некого што прв ве контактирал. Кодовите за обновување се одделен механизам — еднократни, често целосно го прескокнуваат барањето код, а трошењето на еден за тестирање на сметката отстранува резервен пат што можеби ќе ви треба подоцна.

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

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