Etibarlı birdəfəlik kod niyə VPN girişində yenə uğursuz olur

VPN müştərisini açırsınız, parolu yazırsınız və autentifikasiya proqramından gələn altı rəqəm etibarsız kimi qayıdır — iki dəfə, sonra üçüncü dəfə. Hesabda dünəndən bəri heç nə dəyişməyib, ona görə ilk instinkt autentifikasiya proqramındakı qeydi silib yenidən skan etməkdir — adətən bu, səhv təmirdir. Birdəfəlik kod ikinci parol deyil: şlüz onu müəyyən addımda, müəyyən qeydiyyatdan keçmiş qeyddən, müəyyən pəncərə daxilində istəməlidir və rəddlərin çoxu rəqəmlər müqayisə olunmadan əvvəl baş verir. Qeydiyyata toxunmazdan əvvəl hansı addımda olduğunuzu müəyyənləşdirin.

Sorğu sırası hansı axında olduğunuzu göstərir

Demək olar ki, kodla bağlı hər VPN girişini üç forma əhatə edir. İkiaddımlı formada müştəri parolu göndərir, server çağırış yaradır və müştəri yenidən soruşur. Birləşdirilmiş formada şlüz parolu və kodu bir göndərişdə istəyir — bəzən bir-birinə qoşulmuş, bəzən yalnız operatorun sənədləşdirdiyi ayırıcıdan sonra. Brauzer formasında müştərinin heç bir sahəsi yoxdur: kod veb səhifəyə daxil edilir və ya təkan təsdiqi onu əvəz edir, masaüstü müştəri isə nəticəni gözləyir.

Formanı səhv tutmaq pis koda bənzəyir. Təzə kodu yalnız parol üçün nəzərdə tutulmuş sahəyə yapışdırın və server onu parolun hissəsi kimi oxuyacaq. Müştəri tərəfində OpenVPN 2.4 və sonrakı versiyalar fərqi görünən edir: AUTH_FAILED,CRV1: ilə cavab verən server çağırış cavabı gözləyir, ona görə profilə static-challenge və ya SCRV1: formatında parol faylı lazımdır. Yalnız auth-user-pass daşıyan köhnə profil parolu təsdiqləyib sonra dayanır, bu isə jurnalda OTP uğursuzluğu kimi görünür, halbuki heç bir kod göndərilməyib.

WireGuard-ı istisna kimi qeyd etmək lazımdır: o, insanları deyil, açar cütlərini autentifikasiya edir, ona görə kod üçün sahə yoxdur. Provayder belə bir şey elan edirsə, onu tuneldən kənarda bir şey qəbul edir.

Server altı rəqəmlə nə edir

Vaxta əsaslanan kodlar RFC 6238-ə uyğundur, o da RFC 4226-dakı köhnə sayğaca əsaslanan quruluşu əhatə edir: hərəkət edən amil üzərində HMAC, standart olaraq altı rəqəmə kəsilir. TOTP üçün hərəkət edən amil cari Unix vaxtının addıma bölünməsidir, operator dəyişməyibsə 30 saniyə. Yoxlayıcı heç vaxt rəqəmlərinizi saxlanılan dəyərlə müqayisə etmir; gözlənilən kodu ortaq toxumdan yenidən hesablayır və adətən qonşu addımları da qəbul edir, ona görə yavaş gediş-dönüş girişi uğursuz etmir.

İki nəticə gözdən qaçır. Telefonun saat qurşağının əhəmiyyəti yoxdur, çünki toxum heç vaxt yerli saat görmür — yalnız real UTC-dən sapma vacibdir və iki dəqiqə irəli işləyən aparat təmiz geri sayım göstərərkən hər kodu uğursuz edir. Kod isə dizaynına görə birdəfəlikdir: yoxlayıcı həmin toxum üçün qəbul etdiyi son sayğac dəyərini yadda saxlayır, ona görə eyni rəqəmlər yenidən göndərilərsə, hətta eyni pəncərə daxilində rədd edilir. Vaxt aşımından sonra yenidən cəhd edən müştəri təzəcə göndərdiyi kodu yandıra bilər.

Sayğaca əsaslanan tokenlər hər basışda sayğaclarını hərəkət etdirir, ona görə kodlar yaradılıb heç göndərilmədikdən sonra sinxronizasiyadan çıxırlar; adi təmir bir neçə dəyəri irəli qəbul edən yenidən sinxronlaşdırma pəncərəsidir. Operator HOTP qeydiyyatdan keçirib, tətbiqiniz isə TOTP göstərirsə, hər dəyər saat problemi kimi görünən şəkildə səhvdir. QR kodun arxasındakı təchizat URI-si növü, rəqəmləri, dövrü və heşi adlandırır.

Səhv koda bənzəyən uğursuzluqlar

Qeydiyyatdan keçmiş qeyd ən çox rast gəlinən səbəbdir. Autentifikasiya proqramları qeydləri emitent və hesabla adlandırır, ona görə eyni VPN-də iki şəxsiyyəti olan hər kəs adları bir simvolla fərqlənən iki qeydlə qala bilər. Kod onu yaradan toxum üçün etibarlıdır, başqa heç nə üçün deyil. Telefondakı adı serverin qeyd etdiyi istifadəçi adı ilə müqayisə edin, yazdığınızı xatırladığınızla deyil.

İkincisi uyğun olmayan parametr dəstidir. Səkkiz rəqəmlə, 60 saniyəlik dövrlə və ya SHA-256 ilə qeydiyyatdan keçmiş toxum, altı rəqəm, 30 saniyə və SHA-1 gözləyən yoxlayıcının rədd etdiyi kodlar verir və müştəridə bu, səhv koddan ayırd edilə bilmir. Bu, qeydin QR kodun fotoşəklindən yenidən əlavə edildiyi və ya token qeydinin standart dəyərlərlə yenidən qurulduğu miqrasiyalardan sonra görünür.

Üçüncüsü kodla bağlı deyil. Şlüzlər adətən səhv parol, vaxtı keçmiş kod və deaktiv hesab üçün bir ümumi autentifikasiya uğursuzluğu qaytarır, qəsdən, ki heç kim hansı amilin uğursuz olduğunu yoxlaya bilməsin. Müştəri banneri əvəzinə şlüz və ya RADIUS jurnalını oxuyun: heç yaradılmayan çağırış, OTP atributu olmayan giriş rəddi və siyasət rəddi ekranda tam eyni görünür və fərqli növbəti addımlara aparır.

Bunu daraldan qısa ardıcıllıq

Ən ucuz yoxlamadan başlayın və tutmayan ilk addımda dayanın.

1. Təzə kod gözləyin, onu bir dəfə göndərin və çağırışın parol qəbul edilməzdən əvvəl, yoxsa sonra göründüyünü qeyd edin.
2. Autentifikasiya proqramındakı adı serverin saxladığı istifadəçi adı ilə uyğunlaşdırın.
3. Profilin ümumiyyətlə çağırışa cavab verə bildiyini təsdiqləyin, yuxarıdakı CRV1 halında olduğu kimi.
4. Cihazın saatını tanınmış vaxt mənbəyi ilə müqayisə edin; bir neçə onlarla saniyədən çox sapma TOTP-ni özü pozur.
5. Operatordan tokenin TOTP, yoxsa HOTP olduğunu və hansı rəqəmlər, dövr və heşin qeydiyyatdan keçirildiyini soruşun.

İki qayda bunun işləri pisləşdirməsinin qarşısını alır. Çox dəfə yenidən cəhd etməyin: bir çox şlüz uğursuzluqları hesab üzrə sayır və ya hesabı kilidləyir, ya da cavabları gecikdirməyə başlayır, ona görə partlayış kiçik bir səhv konfiqurasiyanı dəstək biletiyə çevirir. Və tokeni diaqnoz məqsədilə yenidən qeydiyyatdan keçirməyin, çünki bu, köhnə toxumu etibarsız edir; əsl nasazlıq müştərinin heç göndərmədiyi çağırış idisə, indi bir əvəzinə iki dəyişikliyi izah etməli olacaqsınız.

Toxumu və bərpa kodlarını dövriyyədən kənarda saxlayın

Altı rəqəm və onların arxasındakı sirr bir-birini əvəz etmir. Təchizat QR kodu və ya Base32 toxumu hesab üçün bütün gələcək kodları yaradır, ona görə parolla eyni kateqoriyaya aiddir: nə ekran şəklində, nə bilet şərhində, nə də ilk sizinlə əlaqə saxlayan şəxslə söhbətdə. Bərpa kodları ayrı mexanizmdir — birdəfəlikdir, çox vaxt kod sorğusunu tamamilə atlayır və hesabı yoxlamaq üçün birini xərcləmək sonra lazım ola biləcək ehtiyat variantı aradan qaldırır.

Kod həm də giriş səhifəsini etibarlı etmir: oxşar domen üzərində OTP sorğusu etibarlı kod toplayıb pəncərə daxilində təkrar oynadır və harada yazdığınızı hələ də sertifikat deyir.

Ardıcıllıq çağırışa cavab verə bilməyən profildə dayanırsa, profili düzəldin və bir təzə kodla yenidən yoxlayın. Uyğun olmayan qeydiyyat parametrlərində dayanırsa, kimsə nəyisə skan etməzdən əvvəl operatordan token qeydini oxumasını xahiş edin. Kilidləmədə dayanırsa, müştəriləri dəyişmək əvəzinə onun bitməsini gözləyin — maneə tətbiq deyil, hesabın vəziyyətidir.