واژه «نرم‌افزار Authenticator» امروز تقریباً مترادف امنیت شده است؛ اما این برنامه فقط یک کلاینت سبک است: جایی که یک راز مشترک نگه داشته می‌شود و از روی آن، کدی چندرقمی ساخته می‌شود. تصمیم مهم اینجا انتخاب «برنامه» نیست، انتخاب «روش احراز هویت» است. اگر این تفکیک را از دست بدهید، ممکن است لایه‌ای اضافه کنید که هم کاربر را آزار می‌دهد و هم در برابر حمله‌ی واقعی سودی ندارد.
سه ستون احراز هویت، و یک اشتباه رایج
هر روش احراز هویت در نهایت به یکی از این سه تکیه می‌کند:
- چیزی که می‌دانید: رمز عبور، پین، پاسخ پرسش امنیتی.
- چیزی که دارید: گوشی، کلید امنیتی سخت‌افزاری، کارت هوشمند.
- چیزی که هستید: اثر انگشت، چهره، عنبیه.
اشتباه رایج، جمع‌کردن چند مرحله از یک ستون و نامیدن آن «احراز هویت چندعاملی (Multi-Factor Authentication)» است. رمز عبور به‌علاوه‌ی پرسش امنیتی، دو مرحله است اما یک عامل؛ چون هر دو در ذهن کاربر جا دارند و هر دو با یک روش، یعنی فریب کاربر، دزدیده می‌شوند. چندعاملی واقعی وقتی شکل می‌گیرد که یک عامل «دانش» با یک عامل «دارایی» یا «ویژگی زیستی» ترکیب شود.
نکته‌ی ظریفی که کمتر گفته می‌شود: اسکن اثر انگشت روی گوشی به سرور اثبات نمی‌شود؛ فقط قفل محلی را باز می‌کند. بنابراین بیومتریک به‌همراه گوشی در عمل یک عامل («چیزی که دارید») حساب می‌شود، نه دو عامل.
چرا پیامک یک کد یکبارمصرف ضعیف‌تر است؟
کد یکبارمصرف پیامکی (SMS OTP) پرکاربردترین و در عین حال سست‌ترین گزینه است. دلیلش فنی است، نه سلیقه‌ای:
- پیام کوتاه از مسیر زیرساخت مخابراتی عبور می‌کند؛ امنیت آن به اپراتور و پروتکل‌های قدیمی شبکه وابسته است، نه به شما.
- حمله‌ی «جابه‌جایی سیم‌کارت (SIM Swap)» عملی و کم‌هزینه است: مهاجم با مهندسی اجتماعی شماره را به سیم‌کارت خودش منتقل می‌کند و همه‌ی کدها را دریافت می‌کند.
- اگر گوشی قفل باشد، متن پیام روی صفحه‌ی قفل خوانده می‌شود؛ یعنی یک نگاه اتفاقی هم می‌تواند کانال را لو بدهد.
پس اگر مجبور به پشتیبانی از پیامک هستید، آن را «گزینه‌ی بازیابی» بدانید، نه عامل اصلی. و اگر کسی بتواند با پیامک رمز را بازنشانی کند، بقیه‌ی تدابیر امنیتی تقریباً بی‌اثر می‌شوند.
داخل نرم‌افزار Authenticator چه می‌گذرد؟
در رایج‌ترین حالت، سرور هنگام فعال‌سازی یک «راز مشترک» می‌سازد و آن را در قالب یک کد QR به اپلیکیشن منتقل می‌کند. از آن به بعد، برنامه با ترکیب آن راز و زمان جاری کدی چندرقمی می‌سازد؛ سرور هم همان محاسبه را تکرار و مقایسه می‌کند.
- کد یکبارمصرف مبتنی بر زمان (Time-based One-Time Password – TOTP): کد به بازه‌های زمانی کوتاه، مثلاً هر ۳۰ ثانیه، گره خورده است. مزیت: نیازی به هماهنگی شمارنده نیست.
- کد یکبارمصرف مبتنی بر شمارنده (HMAC-based One-Time Password – HOTP): هر بار مصرف، شمارنده یکی جلو می‌رود. در دستگاه‌های بدون ساعت دقیق مفید است، اما همگام‌سازی شمارنده دردسر دارد.
- تأیید فشاری (Push-based approval): کاربر روی اعلان می‌زند و تأیید می‌کند. راحت‌ترین گزینه، ولی در برابر «خسته‌کردن از اعلان (MFA Fatigue)» آسیب‌پذیر است؛ مهاجم آن‌قدر اعلان می‌فرستد تا کاربر بی‌حواس یکی را تأیید کند. راهکار مؤثر، نمایش عددی است که کاربر باید در برنامه انتخاب کند.
مهم‌ترین نکته‌ی امنیتی اینجاست: آن راز مشترک یک اعتبارنامه است، نه یک تنظیم. اگر لو برود، مهاجم تا ابد و بدون نیاز به گوشی شما کد درست می‌سازد. پس کد QR باید فقط یک‌بار و روی اتصال امن نمایش داده شود، راز در پایگاه داده به‌صورت رمزنگاری‌شده ذخیره شود و دسترسی به آن محدود بماند.
نسل بعد: کلید امنیتی و پاسکی
در استانداردهای مبتنی بر وب‌آوثن (WebAuthn)، به‌جای راز مشترک یک جفت‌کلید ساخته می‌شود: کلید خصوصی هرگز از دستگاه بیرون نمی‌رود و سرور فقط کلید عمومی را نگه می‌دارد. نتیجه چند مزیت مهم است:
- مقاومت در برابر فیشینگ: امضا به دامنه‌ی مشخص گره خورده است؛ کاربر در سایت جعلی اصلاً نمی‌تواند امضای معتبر تولید کند.
- حذف رمز عبور: با «پاسکی (Passkey)» کاربر بدون رمز وارد می‌شود و بیومتریک فقط قفل محلی کلید را باز می‌کند.
- تفاوت سخت‌افزاری و نرم‌افزاری: پاسکی همگام‌شده بین دستگاه‌ها راحت است؛ کلید سخت‌افزاری جدا امن‌تر، اما برای کاربر سنگین‌تر و پرهزینه‌تر است.
اگر می‌خواهید احراز هویت دوم را در محصول خودتان پیاده کنید
این فهرست، خلاصه‌ی اشتباه‌های پرتکراری است که معمولاً بعد از راه‌اندازی سر باز می‌کنند:
- پنجره‌ی زمانی را کوتاه و منعطف نگه دارید: پذیرش یک گام قبل و بعد، تا ساعت‌های کمی ناهماهنگ کاربران را رد نکند.
- از تکرار کد جلوگیری کنید: آخرین گام زمانی مصرف‌شده را ذخیره کنید تا یک کد رهگیری‌شده دوباره قابل استفاده نباشد.
- محدودسازی نرخ و قفل موقت: بدون آن، شش رقم یعنی یک میلیون حالت که با چند هزار درخواست در دقیقه قابل حدس‌زدن است.
- کدهای بازیابی را جدی بگیرید: چند کد یکبارمصرف بسازید و از کاربر بخواهید آن‌ها را جدا نگه دارد.
- مسیر بازیابی هویت را سخت‌تر از مسیر ورود کنید: بی‌دقتی در این مرحله، همه‌ی لایه‌های قبلی را دور می‌زند.
- همه‌چیز را ثبت کنید: فعال‌سازی، غیرفعال‌سازی، تغییر دستگاه و تلاش‌های ناموفق باید قابل ردیابی باشند.
رعایت این موارد را می‌توانید بر پایه‌ی راهنماهای شناخته‌شده‌ی امنیت برنامه‌های وب پیش ببرید و از تکیه بر سلیقه‌ی تیم پرهیز کنید. همچنین یادتان باشد که احراز هویت همان مرز اعتماد است؛ هر چیزی که پیش از ورود کاربر اتفاق می‌افتد، از کپچا تا اعتبارسنجی ورودی، فقط تدارکات است، نه امنیت نهایی.
راهنمای تصمیم‌گیری سریع
- کارمندان داخلی با ورود یکپارچه: کلید امنیتی یا پاسکی؛ بهترین نسبت امنیت به زحمت.
- مشتریان عمومی یک اپلیکیشن موبایل: نرم‌افزار Authenticator به‌عنوان روش اصلی و پیامک فقط به‌عنوان پشتیبان.
- عملیات حساس (تغییر رمز، تأیید تراکنش، دسترسی مدیریتی): عامل دوم اجباری، مستقل از روش ورود عادی.
- دسترسی سرویس‌ها و APIها: توکن با عمر کوتاه و بازبینی دوره‌ای؛ کد یکبارمصرف اینجا ابزار مناسبی نیست.
- کسب‌وکار کوچک بدون تیم امنیتی: با همان چند گام پایه شروع کنید؛ امنیت سایبری برای کسب‌وکارهای کوچک بیشتر از ابزار گران، به انضباط عملی وابسته است.
جمع‌بندی
نرم‌افزار Authenticator یک ابزار خوش‌دست است، اما جای تصمیم‌گیری معماری را نمی‌گیرد. اول مشخص کنید می‌خواهید در برابر چه حمله‌ای مقاومت کنید: حدس رمز، فیشینگ، جابه‌جایی سیم‌کارت یا دسترسی داخلی. بعد روش را انتخاب کنید؛ اگر می‌شود، پاسکی یا کلید امنیتی را در اولویت بگذارید، کد مبتنی بر زمان را جایگزین پیامک کنید و مسیر بازیابی حساب را با همان جدیت مسیر ورود طراحی کنید. امنیت واقعی، نه در نصب یک اپ، در بستن همان حلقه‌های ضعیفی است که مهاجم همیشه سراغشان می‌رود.
