ولې سم یو ځلي کوډ بیا هم د 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 ښیي، هر ارزښت په داسې ډول غلط دی چې د ساعت ستونزه ښکاري. د QR کوډ شاته د چمتو کولو URI ډول، عددونه، موده او هش نوموي.

هغه ناکامۍ چې د غلط کوډ په څېر ښکاري

ثبت شوې ننوتنه تر ټولو عامه مجرمه ده. تصدیق کوونکي اپلیکیشنونه ننوتنې د صادروونکي او حساب له مخې لیبل کوي، نو هغه څوک چې په یوه VPN دوه هویتونه لري کېدای شي دوه ننوتنې ولري چې لیبلونه یې په یو توري توپیر لري. کوډ یوازې هغه تخم لپاره سم دی چې جوړ کړی یې دی، او د بل هېڅ شي لپاره نه. په تلیفون کې لیبل د هغه کارن نوم سره پرتله کړئ چې سرور یې ثبتوي، نه د هغه سره چې تاسو یاد دي لیکلي وي.

دویمه ناسمه د پارامترونو ټولګه ده. هغه تخم چې په اتو عددونو، 60 ثانیو موده یا SHA-256 ثبت شوی وي هغه کوډونه ورکوي چې شپږ عددونه، 30 ثانیې او SHA-1 ته انتظار کوونکی تصدیق کوونکی ردوي، او په کلاینټ کې دا له غلط کوډ څخه نه توپیر کېږي. دا د هجرتونو وروسته ښکاري چې ننوتنه د QR کوډ له عکس څخه بیا ورزیاته شوې، یا توکن ریکارډ په ډیفالټ ارزښتونو بیا جوړ شوی.

درېیمه د کوډ په اړه نه ده. دروازې معمولاً د غلط پټنوم، پای ته رسېدلي کوډ او ناغوښتي حساب لپاره یوه عمومي تصدیق ناکامي بیرته ورکوي، په قصد، چې هیڅوک ونه شي معلومول کوم عامل ناکام شو. د کلاینټ بینر پر ځای د دروازې یا RADIUS لاګ ولولئ: هغه ننګونه چې هېڅکله صادر شوې نه ده، پرته له OTP ځانګړنې د لاسرسي رد او د تګلارې رد په سکرین کې یو شان ښکاري او بېلو بلو ګامونو ته رسوي.

لنډ ترتیب چې دا تنګوي

له تر ټولو ارزانه کتنې پیل کړئ او په لومړي هغه ګام ودرېږئ چې نه ټینګېږي.

1. د تازه کوډ لپاره انتظار وکړئ، یو ځل یې ولېږئ، او یادښت وکړئ چې ننګونه د پټنوم له منلو دمخه راځي که وروسته.
2. په تصدیق کوونکي کې لیبل د سرور ساتل شوي کارن نوم سره سم کړئ.
3. ډاډ ترلاسه کړئ چې پروفایل هېڅکله هم د ننګونې ځواب ورکولی شي، لکه پورتنۍ CRV1 پېښه.
4. د وسیلې ساعت د یوې پېژندل شوې وخت سرچینې سره پرتله کړئ؛ له څو لسیزو ثانیو زیات انحراف TOTP پخپله ماتوي.
5. له عملیات کوونکي وپوښتئ چې ټوکن TOTP دی که HOTP، او کوم عددونه، موده او هش ثبت شوي.

دوه قاعدې دې ته نه پرېږدي چې حال خراب شي. ډېر ځله بیا هڅه مه کوئ: ډېری دروازې ناکامۍ د حساب له مخې شمېري او یا یې قفل کوي یا ځوابونه ورو کوي، نو یوه چټکه هڅه یوه کوچنۍ غلطه ترتیبه د ملاتړ ټکټ ته اړوي. او ټوکن د تشخیص لپاره بیا مه ثبتوئ، ځکه چې دا زوړ تخم باطلوي؛ که ریښتینی عیب هغه ننګونه وه چې کلاینټ هېڅکله ونه لېږله، اوس یوه پر ځای دوه بدلونونه لرئ چې تشریح یې کړئ.

تخم او د بیا رغولو کوډونه له چکر څخه بهر وساتئ

شپږ عددونه او هغه پټ راز چې تر شا یې دی د یو بل پر ځای نه شي کارېدلی. د چمتو کولو QR کوډ یا Base32 تخم د حساب هر راتلونکی کوډ جوړوي، نو په همدې کټګورۍ کې راځي لکه پټنوم: نه په سکرین شاټ کې، نه په ټکټ تبصره کې، او نه په هغه چا سره چټ کې چې لومړی له تاسو سره اړیکه کړې. د بیا رغولو کوډونه جلا میکانیزم دی — یو ځلی، ډېری وخت د کوډ غوښتنه بشپړه پرېږدي، او د حساب د ازموینې لپاره یو خرڅول هغه بدیله لار لرې کوي چې وروسته یې اړتیا پیښېدلی شي.

کوډ د ننوتلو پاڼه هم د باور وړ نه کوي: په ورته ښکارېدونکې ډومېن کې OTP غوښتنه سم کوډ ټولوي او د همدې کړکۍ په اوږدو کې بیا غږوي، او سند لا هم هغه دی چې وایي چېرته لیکئ.

که ترتیب هغه پروفایل ته ورسېد چې د ننګونې ځواب نه شي ورکولی، پروفایل سم کړئ او په یوه تازه کوډ بیا یې وآزموئ. که ناسم ثبت پارامترونو ته ورسېد، له دې مخکې چې څوک څه سکن کړي له عملیات کوونکي وغواړئ چې توکن ریکارډ ولولي. که قفل ته ورسېد، د کلاینټونو د بدلولو پر ځای انتظار وکړئ چې پای ته ورسېږي — خنډ د حساب حالت دی، نه اپلیکیشن.