چرا یک کد یکبارمصرف معتبر هنوز در ورود به VPN شکست می‌خورد
کد ردشده معمولاً مشکل ترتیب درخواست، ثبت‌نام یا زمان است، نه کد اشتباه. پیش از ثبت‌نام دوباره هر چیزی، اینها را به ترتیب بررسی کنید.
کلاینت VPN را باز می‌کنید، رمز عبور را می‌نویسید و شش رقم برنامه احراز هویت به‌عنوان نامعتبر برمی‌گردد — دو بار، سپس بار سوم. از دیروز چیزی در حساب تغییر نکرده است، بنابراین اولین واکنش حذف ورودی برنامه احراز هویت و اسکن دوباره آن است — که معمولاً تعمیر اشتباهی است. کد یکبارمصرف رمز دوم نیست: دروازه باید آن را در گام مشخصی، از ورودی ثبت‌شده مشخصی، در پنجره زمانی مشخصی بخواهد، و بیشتر ردها پیش از مقایسه ارقام رخ می‌دهند. پیش از دست زدن به ثبت‌نام، مشخص کنید در کدام گام هستید.
ترتیب درخواست‌ها می‌گوید در کدام جریان هستید
سه شکل تقریباً هر ورود VPN همراه با کد را پوشش می‌دهد. در شکل دو مرحله‌ای کلاینت رمز عبور را می‌فرستد، سرور چالش صادر می‌کند و کلاینت دوباره می‌پرسد. در شکل ترکیبی دروازه رمز و کد را در یک ارسال می‌خواهد — گاهی به‌هم‌چسبیده، گاهی پس از جداکننده‌ای که تنها اپراتور مستندش می‌کند. در شکل مرورگر کلاینت هیچ فیلدی ندارد: کد در یک صفحه وب وارد می‌شود، یا تأیید فشاری جای آن را می‌گیرد و کلاینت رومیزی منتظر نتیجه می‌ماند.
اشتباه در شکل مانند کد بد به نظر می‌رسد. کد تازه را در فیلدی که فقط برای رمز عبور است بچسبانید و سرور آن را بخشی از رمز می‌خواند. در سمت کلاینت، OpenVPN 2.4 و نسخه‌های بعدی تفاوت را آشکار می‌کنند: سروری که با AUTH_FAILED,CRV1: پاسخ می‌دهد منتظر پاسخ چالش است، پس پروفایل به static-challenge یا فایل رمز به شکل SCRV1: نیاز دارد. پروفایل قدیمی‌تری که تنها auth-user-pass دارد رمز را تأیید می‌کند و سپس متوقف می‌شود، که در گزارش مانند شکست OTP دیده می‌شود هرچند هیچ کدی فرستاده نشده است.
WireGuard شایسته استثنا نامیده شدن است: این جفت‌کلیدها را احراز هویت می‌کند نه افراد، پس هیچ فیلدی برای کد وجود ندارد. اگر ارائه‌دهنده‌ای چنین چیزی تبلیغ کند، چیزی بیرون از تونل آن را می‌پذیرد.
سرور با شش رقم چه می‌کند
کدهای زمان‌محور از RFC 6238 پیروی می‌کنند که ساختار قدیمی‌تر مبتنی بر شمارنده از RFC 4226 را در بر می‌گیرد: یک HMAC روی عامل متحرک، به‌طور پیش‌فرض تا شش رقم بریده می‌شود. در TOTP عامل متحرک زمان یونیکس فعلی تقسیم بر یک گام است، 30 ثانیه مگر اینکه اپراتور آن را تغییر داده باشد. تأییدکننده هرگز ارقام شما را با مقدار ذخیره‌شده مقایسه نمی‌کند؛ کد انتظاری را از بذر مشترک دوباره محاسبه می‌کند و معمولاً گام‌های همسایه را هم می‌پذیرد، بنابراین رفت‌وبرگشت کند ورود را شکست نمی‌دهد.
دو پیامد نادیده گرفته می‌شود. منطقه زمانی گوشی بی‌معنی است، زیرا بذر هرگز ساعت محلی نمی‌بیند — تنها انحراف از UTC واقعی مهم است، و دستگاهی که دو دقیقه جلو باشد در هر کدی شکست می‌خورد در حالی که شمارش معکوس تمیزی نشان می‌دهد. و کد به‌طور طراحی یکبارمصرف است: تأییدکننده آخرین مقدار شمارنده‌ای را که برای آن بذر پذیرفته به یاد می‌آورد، پس همان ارقامی که دوباره ارسال شوند حتی در همان پنجره رد می‌شوند. کلاینتی که پس از پایان مهلت دوباره تلاش می‌کند می‌تواند کدی را که تازه فرستاده بسوزاند.
توکن‌های مبتنی بر شمارنده با هر فشار شمارنده را جابه‌جا می‌کنند، پس پس از تولید کدهایی که هرگز ارسال نمی‌شوند از همزمانی خارج می‌شوند؛ تعمیر معمول پنجره بازهمزمان‌سازی است که چند مقدار جلوتر را می‌پذیرد. اگر اپراتور HOTP ثبت کرده باشد و برنامه شما TOTP نشان دهد، هر مقدار به‌گونه‌ای غلط است که مانند مشکل ساعت به نظر می‌رسد. URI تأمین پشت کد QR نوع، ارقام، دوره و هش را نام می‌برد.
شکست‌هایی که مانند کد اشتباه به نظر می‌رسند
ورودی ثبت‌شده شایع‌ترین مقصر است. برنامه‌های احراز هویت ورودی‌ها را بر اساس صادرکننده و حساب برچسب می‌زنند، پس هرکس دو هویت روی یک VPN داشته باشد می‌تواند دو ورودی داشته باشد که برچسب‌هایشان در یک نویسه تفاوت دارد. کد برای بذری که آن را ساخته معتبر است و برای هیچ چیز دیگر. برچسب روی گوشی را با نام کاربری‌ای که سرور ثبت می‌کند مقایسه کنید، نه با آنچه یادتان می‌آید تایپ کرده‌اید.
دوم مجموعه‌ای از پارامترها که نمی‌خواند. بذری که با هشت رقم، دوره 60 ثانیه‌ای یا SHA-256 ثبت شده باشد کدهایی می‌دهد که تأییدکننده‌ای که شش رقم، 30 ثانیه و SHA-1 انتظار دارد رد می‌کند، و در کلاینت این از کد اشتباه قابل تشخیص نیست. پس از مهاجرت‌هایی ظاهر می‌شود که ورودی از عکسی از کد QR دوباره اضافه شده یا رکورد توکن با مقادیر پیش‌فرض بازسازی شده است.
سوم مربوط به کد نیست. دروازه‌ها معمولاً برای رمز اشتباه، کد منقضی و حساب غیرفعال یک شکست احراز هویت عمومی واحد برمی‌گردانند، به‌عمد، تا کسی نتواند بررسی کند کدام عامل شکست خورده است. به‌جای پیام کلاینت، گزارش دروازه یا RADIUS را بخوانید: چالشی که هرگز صادر نشده، رد دسترسی بدون ویژگی OTP و رد سیاست همه روی صفحه یکسان دیده می‌شوند و به گام‌های بعدی متفاوتی می‌رسند.
دنباله کوتاهی که آن را محدود می‌کند
با ارزان‌ترین بررسی شروع کنید و در نخستین گامی که برقرار نیست بایستید.
- منتظر کد تازه بمانید، یک بار ارسالش کنید و توجه کنید چالش پیش از پذیرش رمز ظاهر می‌شود یا پس از آن.
- برچسب در برنامه احراز هویت را با نام کاربری‌ای که سرور ذخیره می‌کند تطبیق دهید.
- تأیید کنید که پروفایل اصلاً می‌تواند به چالش پاسخ دهد، مانند مورد
CRV1در بالا. - ساعت دستگاه را با منبع زمان شناخته‌شده مقایسه کنید؛ انحراف بیش از چند ده ثانیه خودش TOTP را می‌شکند.
- از اپراتور بپرسید توکن TOTP است یا HOTP، و کدام ارقام، دوره و هش ثبت شده‌اند.
دو قاعده نمی‌گذارد این وضع بدتر شود. بارها تلاش نکنید: بسیاری از دروازه‌ها شکست‌ها را به‌ازای هر حساب می‌شمارند و یا آن را قفل می‌کنند یا پاسخ‌ها را به تأخیر می‌اندازند، پس یک هجوم کوچک یک تنظیم اشتباه کوچک را به تیکت پشتیبانی تبدیل می‌کند. و توکن را به‌عنوان تشخیص دوباره ثبت نکنید، زیرا بذر قدیمی را باطل می‌کند؛ اگر عیب واقعی چالشی بود که کلاینت هرگز نفرستاد، حالا دو تغییر برای توضیح دارید نه یکی.
بذر و کدهای بازیابی را از چرخه بیرون نگه دارید
شش رقم و رازی که پشت آنهاست قابل جایگزینی نیستند. کد QR تأمین یا بذر Base32 هر کد آینده حساب را می‌سازد، پس در همان دسته رمز عبور قرار می‌گیرد: نه در تصویر صفحه، نه در نظر تیکت، نه در گفت‌وگو با کسی که اول با شما تماس گرفته است. کدهای بازیابی سازوکاری جداگانه‌اند — یکبارمصرف، اغلب درخواست کد را کاملاً رد می‌کنند، و خرج کردن یکی برای آزمایش حساب یک راه جایگزین را که بعداً ممکن است لازم شود حذف می‌کند.
کد همچنین صفحه ورود را قابل‌اعتماد نمی‌کند: درخواست OTP روی دامنه‌ای شبیه، کدی معتبر جمع می‌کند و آن را در همان پنجره دوباره پخش می‌کند، و همچنان گواهی است که می‌گوید کجا تایپ می‌کنید.
اگر دنباله به پروفایلی رسید که نمی‌تواند به چالش پاسخ دهد، پروفایل را درست کنید و با یک کد تازه دوباره آزمایش کنید. اگر به پارامترهای ثبت‌نام ناخوانا رسید، پیش از آنکه کسی چیزی را اسکن کند از اپراتور بخواهید رکورد توکن را بخواند. اگر به قفل رسید، بگذارید تمام شود به‌جای عوض کردن کلاینت — وضعیت حساب مانع است، نه برنامه.