Защо валиден еднократен код все още се проваля при вход във 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 на подобен домейн събира валиден код и го преиграва в рамките на прозореца, а сертификатът все още е това, което ви казва къде въвеждате.

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