درخواست MFA در VPN رد شد: کلاینت چه باید بکند
درخواست MFA ردشده یک ورود ناموفق است، نه حلقه تلاش دوباره. درخواست را شناسایی کنید، خطا را نمایان نگه دارید و آنچه پشتیبانی می‌پرسد را ثبت کنید.
درخواست MFA ردشده شبیه مشکل شبکه است و نیست. سرور عامل دوم را خواست، عامل منفی بازگشت یا هرگز نرسید، و نشست پیش از آنکه تونلی وجود داشته باشد رد شد. آنچه پس از آن رخ می‌دهد پرسشی درباره رفتار کلاینت است: خطا را نشان دهد و بگذارد کاربر تلاشی تازه آغاز کند، یا به روش‌هایی دوباره تلاش کند که درخواست‌های بیشتری بسازد و در نهایت حفاظت حساب را فعال کند. مسیر دوم همان راهی است که یک کد اشتباه تایپ‌شده را به حسابی قفل‌شده تبدیل می‌کند.
بررسی کنید کدام درخواست شکست خورده است
با شناسایی اینکه کدام درخواست شکست خورده آغاز کنید. اعلان پوش، کد TOTP، اثبات FIDO و جریان SAML هر یک به گونه‌ای متفاوت شکست می‌خورند و کلاینت معمولاً می‌داند کدام را خواسته است. رد شدن، چالش منقضی و خطای تحویلی که هرگز به دستگاه نرسید، همه به یک خطای عمومی یکسان می‌رسند، پس وضعیت خود کلاینت اغلب تنها جایی است که تفاوت در آن زنده می‌ماند.
آن وضعیت ارزش ثبت دقیق را دارد. شناسه چالش یا مرجع تراکنش، نوع عامل، برچسب زمانی و نتیجه را ثبت کنید، اما هرگز کد یا اثبات را نه. شناسه چالش همان چیزی است که به مدیر اجازه می‌دهد رویداد را در سمت ارائه‌دهنده هویت پیدا کند؛ بدون آن گفت‌وگوی پشتیبانی با «یک جایی در ساعت گذشته» شروع می‌شود و معمولاً همان‌جا تمام می‌شود. با آن مانند فراداده تشخیصی رفتار کنید، نه مانند یک راز.
یک بار، آگاهانه، با چالشی تازه دوباره تلاش کنید
تلاش دوباره باید کوششی تازه با چالشی تازه باشد، نه پخش دوباره چالش کهنه. وقتی کلاینت چالش پیشین را بازاستفاده می‌کند، ارائه‌دهنده هویت یا آن را کهنه می‌داند و رد می‌کند یا، بدتر، تأییدی را می‌پذیرد که برای تلاش پیشین در نظر گرفته شده بود. چالش تازه بخواهید، آن را نشان دهید و بگذارید کاربر روی همان چیزی که اکنون روی صفحه است عمل کند.
دو تلاش با مکثی کوتاه میان آن‌ها پیش‌فرض معقولی است؛ حلقه بی‌پایان نیست. اگر تلاش دوم به همان شکل شکست خورد، به جای ادامه دادن بایستید و گزارش دهید.
کلاینت نباید چه کارهایی بکند
کلاینت نباید چند کار را انجام دهد که سودمند به نظر می‌رسند و نیستند. نباید ارسال اعلان‌های پوش را ادامه دهد تا کسی «تأیید» را بزند، چون این کار کاربران را به تأیید درخواست‌هایی عادت می‌دهد که خودشان آغاز نکرده‌اند و همان رفتاری است که کیت‌های فیشینگ به آن تکیه می‌کنند. نباید چون عامل قوی شکست خورده به عامل ضعیف‌تر عقب‌نشینی کند، و نباید بررسی هویت سرور را غیرفعال کند تا از شکایت گواهی‌ای که همزمان ظاهر شده بگذرد. هر یک از این سه میانبر یک شکست احراز هویت را به حادثه امنیتی تبدیل می‌کند.
همچنین نباید شکست را بی‌صدا ببلعد. کلاینتی که اتصال را می‌بندد و یک نشانگر چرخان نشان می‌دهد، کاربر را بی‌درک اینکه باید دوباره تلاش کند، صبر کند یا با پشتیبانی تماس بگیرد رها می‌کند. شکست را همراه با نوع عامل و کد کوتاه نشان دهید، پیام را از رازها پاک نگه دارید و کنش تلاش دوباره را به جای خودکار، صریح کنید.
اگر درخواست را شخص پشت صفحه‌کلید آغاز نکرده است، کنش درست رها کردن آن به صورت ردشده و گزارش آن از مسیر تأییدشده پشتیبانی است. تأیید یک درخواست برای پایان دادن به سروصدا، الگوی شکست است، نه راه‌حل.
چه چیزی برای پشتیبانی ثبت کنیم
برای پشتیبانی، سابقه مفید کوچک است. زمان تقریبی با منطقه زمانی، حساب، کلاینت و نسخه، نوع عامل، و وضعیت غیرراز هر تلاش: خواسته شد، رد شد، مهلت گذشت، تأیید شد اما سیاست آن را رد کرد.
ساعت‌های کلاینت و سرور را هم در نظر بگیرید. TOTP یک بررسی پنجره زمانی است، بنابراین دستگاهی که ساعتش جابه‌جا شده کدهایی می‌سازد که معتبر به نظر می‌رسند و هر بار شکست می‌خورند، و کلاینتی که کد نامعتبر را بدون اشاره به جابه‌جایی گزارش می‌کند، افراد را به بازنشانی اعتبارنامه‌هایی می‌فرستد که هرگز اشتباه نبوده‌اند. کاربری که ورودش مکرراً شکست می‌خورد باید پیش از ساختن درخواست‌های بیشتر، نسخه پشتیبانی‌شده کلاینت، وضعیت ثبت‌نام و جریان بازیابی مستند را بررسی کند.
مسیر بازیابی همان اندازه مسیر ورود شایسته توجه است. جریان کاری دستگاه گمشده دقیقاً برای همین وجود دارد تا رد شدن به اجازه دور زدن احراز هویت تبدیل نشود، و کلاینت باید به فرایند مستند سازمان پیوند بدهد نه اینکه خودش یکی از خود درآورد.
قاعده‌ای که باید بر آن ساخت این است: رد شدن یک نتیجه است، نه یک مانع. یک بار، روشن، با زمینه کافی برای اقدام گزارشش دهید و بگذارید تلاش بعدی تازه باشد. راهنمای CISA درباره MFA مقاوم در برابر فیشینگ توضیح می‌دهد چرا الگوی «بپرس تا تأیید شود» از همان ابتدا خطرناک است، و همان مرجعی است که وقتی کسی حلقه‌ای از تلاش دوباره پیشنهاد می‌کند ارزش استناد دارد. هر چیزی که کلاینت پس از رد شدن اضافه می‌کند باید تصمیم بعدی را برای انسان آسان‌تر کند، نه اینکه تصمیم را از او بگیرد.