Чаму сапраўдны аднаразовы код не праходзіць пры ўваходзе ў 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 на падобным дамене збірае сапраўдны код і паўтарае яго ў межах акна, а сертыфікат па-ранейшаму паказвае, дзе вы ўводзіце.

Калі паслядоўнасць прывядзе да профілю, які не можа адказаць на выклік, выпраўце профіль і праверце зноў адным свежым кодам. Калі яна прывядзе да несумяшчальных параметраў рэгістрацыі, папрасіце аператара прачытаць запіс токена, перш чым хтосьці нешта скануе. Калі яна ўпрэцца ў блакіроўку, перачакайце яе, а не мяняйце кліенты — стан уліковага запісу з'яўляецца перашкодай, а не дадатак.