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

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

Редослед захтева показује у ком току сте

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

Погрешан облик изгледа као лош код. Налепите свеж код у поље само за лозинку и сервер ће га прочитати као део лозинке. На страни клијента, 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 на сличном домену прикупи исправан код и поново га пусти унутар прозора, а сертификат је и даље оно што вам каже где куцате.

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