რატომ მაინც ვერ მუშაობს ვალიდური ერთჯერადი კოდი 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-ს აჩვენებს, ყველა მნიშვნელობა არასწორია ისე, რომ საათის პრობლემას ჰგავს. QR კოდის უკან არსებული მომარაგების URI ასახელებს ტიპს, ციფრებს, პერიოდსა და ჰეშს.

ჩავარდნები, რომლებიც არასწორ კოდს ჰგავს

რეგისტრირებული ჩანაწერი ყველაზე ხშირი დამნაშავეა. ავთენტიფიკატორის აპლიკაციები ჩანაწერებს გამომცემლისა და ანგარიშის მიხედვით ასახელებენ, ამიტომ ვისაც ერთ VPN-ზე ორი იდენტობა აქვს, შეიძლება ორი ჩანაწერი ჰქონდეს, რომელთა ეტიკეტებიც ერთი სიმბოლოთი განსხვავდება. კოდი ვალიდურია იმ თესლისთვის, რომელმაც შექმნა, და სხვა არაფრისთვის. შეადარეთ ტელეფონის ეტიკეტი სერვერის მიერ დაფიქსირებულ მომხმარებლის სახელს და არა იმას, რაც გახსოვთ, რომ აკრიფეთ.

მეორეა შეუსაბამო პარამეტრების ნაკრები. რვა ციფრით, 60 წამის პერიოდით ან SHA-256-ით დარეგისტრირებული თესლი იძლევა კოდებს, რომლებსაც ექვს ციფრს, 30 წამსა და SHA-1-ს მოლოდინში მყოფი გამმოწმებელი უარყოფს, და კლიენტთან ამისი არასწორი კოდისგან გარჩევა შეუძლებელია. ის ჩნდება მიგრაციების შემდეგ, როცა ჩანაწერი ხელახლა დაემატა QR კოდის ფოტოდან, ან როცა ტოკენის ჩანაწერი ნაგულისხმევი მნიშვნელობებით ხელახლა აშენდა.

მესამე კოდს არ ეხება. კარიბჭეები, როგორც წესი, არასწორი პაროლისთვის, ვადაგასული კოდისა და გამორთული ანგარიშისთვის ერთ საერთო ავთენტიფიკაციის ჩავარდნას აბრუნებენ, განზრახ, რომ ვერავინ გაარკვიოს, რომელი ფაქტორი ჩავარდა. წაიკითხეთ კარიბჭის ან RADIUS-ის ჟურნალი კლიენტის ბანერის ნაცვლად: არასდროს გაცემული გამოწვევა, OTP ატრიბუტის გარეშე წვდომის უარყოფა და პოლიტიკით უარყოფა ეკრანზე ერთნაირად გამოიყურება და სხვადასხვა შემდეგ ნაბიჯამდე მიგვიყვანს.

მოკლე მიმდევრობა, რომელიც ავიწროებს

დაიწყეთ ყველაზე იაფი შემოწმებით და გაჩერდით პირველ საფეხურზე, რომელიც არ დგას.

1. დაელოდეთ ახალ კოდს, გაგზავნეთ ერთხელ და დააფიქსირეთ, გამოწვევა პაროლის მიღებამდე ჩნდება თუ შემდეგ.
2. შეუსაბამეთ ავთენტიფიკატორის ეტიკეტი სერვერის შენახულ მომხმარებლის სახელს.
3. დაადასტურეთ, რომ პროფილს საერთოდ შეუძლია გამოწვევაზე პასუხი, როგორც ზემოთ CRV1 შემთხვევაში.
4. შეადარეთ მოწყობილობის საათი ცნობილ დროის წყაროს; რამდენიმე ათეულ წამზე მეტი გადახრა თავისთავად ამტვრევს TOTP-ს.
5. ჰკითხეთ ოპერატორს, ტოკენი TOTP-ია თუ HOTP, და რომელი ციფრები, პერიოდი და ჰეში დარეგისტრირდა.

ორი წესი ხელს უშლის ამის გაუარესებას. ნუ სცდილობთ ბევრჯერ: ბევრი კარიბჭე ანგარიშზე ჩავარდნებს ითვლის და ან ჩაკეტავს, ან პასუხების დაყოვნებას იწყებს, ამიტომ ნაკადი პატარა კონფიგურაციის შეცდომას მხარდაჭერის ბილეთად აქცევს. და ნუ დაარეგისტრირებთ ტოკენს ხელახლა დიაგნოსტიკისთვის, რადგან ეს ძველ თესლს ბათილად აქცევს; თუ ნამდვილი ხარვეზი გამოწვევა იყო, რომელიც კლიენტმა არასდროს გაგზავნა, ახლა ერთის ნაცვლად ორი ცვლილება გაქვთ ასახსნელი.

შეინახეთ თესლი და აღდგენის კოდები წრის გარეთ

ექვსი ციფრი და მათ უკან არსებული საიდუმლო ურთიერთშემცვლელი არ არის. მომარაგების QR კოდი ან Base32 თესლი ანგარიშის ყველა მომავალ კოდს ქმნის, ამიტომ ის პაროლის იმავე კატეგორიაშია: არა ეკრანის სურათში, არა ბილეთის კომენტარში, არა ჩატში იმასთან, ვინც პირველმა დაგიკავშირდათ. აღდგენის კოდები ცალკე მექანიზმია — ერთჯერადი, ხშირად კოდის მოთხოვნას საერთოდ გვერდს უვლიან, და ერთის დახარჯვა ანგარიშის შესამოწმებლად აშორებს სარეზერვო გზას, რომელიც მოგვიანებით შეიძლება დაგჭირდეთ.

კოდი არც შესვლის გვერდს ხდის სანდოს: მსგავს დომენზე OTP მოთხოვნა აგროვებს ვალიდურ კოდს და ფანჯრის შიგნით ხელახლა უკრავს მას, და სერტიფიკატი კვლავ არის ის, რაც გეუბნებათ, სად აკრეფთ.

თუ მიმდევრობა იმ პროფილზე მთავრდება, რომელსაც გამოწვევაზე პასუხი არ შეუძლია, გაასწორეთ პროფილი და ხელახლა გამოსცადეთ ერთი ახალი კოდით. თუ ის შეუსაბამო რეგისტრაციის პარამეტრებზე მთავრდება, სთხოვეთ ოპერატორს წაიკითხოს ტოკენის ჩანაწერი, სანამ ვინმე რამეს დაასკანერებს. თუ ის ჩაკეტვაზე მთავრდება, დაელოდეთ მის გასვლას კლიენტების შეცვლის ნაცვლად — დაბრკოლება ანგარიშის მდგომარეობაა და არა აპლიკაცია.