احراز هویت دو مرحله‌ای چیست؟ آموزش افزایش امنیت سایت با 2FA

احراز هویت دو مرحله‌ای یا 2FA یک لایه امنیتی اضافه برای ورود به حساب کاربری است که در آن داشتن رمز عبور به‌تنهایی کافی نیست و کاربر باید عامل دیگری مانند کد یک‌بارمصرف TOTP، کلید امنیتی، Passkey یا تأیید از دستگاه مورد اعتماد را نیز ارائه کند. فعال‌سازی اصولی 2FA، به‌خصوص برای مدیران سایت، می‌تواند خطر تصاحب حساب در اثر سرقت یا افشای رمز عبور را به شکل قابل توجهی کاهش دهد.

امنیت صفحه ورود یکی از مهم‌ترین بخش‌های امنیت هر وب‌سایت است. حتی اگر سایت از WAF، SSL/TLS، سیستم مانیتورینگ، افزونه‌های امنیتی و سرور به‌روز استفاده کند، در نهایت بخش مهمی از کنترل سایت در اختیار حساب‌های کاربری قرار دارد.

اگر رمز عبور مدیر سایت افشا شود چه اتفاقی می‌افتد؟

در یک سیستم مبتنی بر رمز عبور، مهاجم ممکن است تنها با داشتن Username و Password بتواند وارد حساب شود. این اطلاعات می‌توانند در حملات Phishing، Credential Stuffing، بدافزارهای سرقت اطلاعات، نشت اطلاعات سرویس‌های دیگر یا حتی استفاده مجدد کاربر از یک Password قدیمی به دست آیند.

احراز هویت دو مرحله‌ای یا Two-Factor Authentication برای کاهش همین ریسک ایجاد شده است.

در یک سیستم 2FA استاندارد، Password فقط اولین عامل Authentication است. کاربر برای تکمیل ورود باید عامل مستقلی مانند دستگاه، کلید رمزنگاری یا کد ایجادشده در Authenticator App را نیز ارائه کند.

OWASP استفاده از Multi-Factor Authentication را یکی از کنترل‌های مهم برای مقابله با حملات مرتبط با Password می‌داند و توصیه می‌کند حداقل حساب‌های مدیریتی و دارای سطح دسترسی بالا حتماً با MFA محافظت شوند.

اما تمام روش‌هایی که با عنوان «ورود دو مرحله‌ای» معرفی می‌شوند، امنیت یکسانی ندارند.

کد پیامکی، TOTP، Push Notification، Hardware Security Key و Passkey همگی تجربه‌ای متفاوت و سطح متفاوتی از مقاومت در برابر Phishing، SIM Swap و سرقت Credential ارائه می‌کنند.

در این مقاله از رخنه‌کاو بررسی می‌کنیم احراز هویت دو مرحله‌ای چیست، چگونه امنیت سایت را افزایش می‌دهد، تفاوت 2FA و MFA چیست، بهترین روش 2FA کدام است و هنگام پیاده‌سازی آن در وردپرس یا سایر وب‌سایت‌ها باید به چه نکاتی توجه کرد.

احراز هویت چیست؟

Authentication یا احراز هویت فرایندی است که سیستم از طریق آن بررسی می‌کند کاربری که درخواست ورود دارد واقعاً همان فردی است که ادعا می‌کند.

ساده‌ترین نمونه Authentication همان Username و Password است.

کاربر می‌گوید:

«من صاحب این حساب هستم.»

و برای اثبات آن Password را ارائه می‌دهد.

اگر Password صحیح باشد، سیستم Authentication را موفق تلقی می‌کند.

مشکل این مدل این است که تمام امنیت ورود به یک Secret وابسته شده است.

اگر Password به هر دلیلی افشا شود، عامل دیگری برای تشخیص کاربر واقعی از مهاجم وجود ندارد.

2FA این معماری را تغییر می‌دهد.

احراز هویت دو مرحله‌ای یا 2FA چیست؟

2FA مخفف Two-Factor Authentication است.

در احراز هویت دو مرحله‌ای، سیستم برای ورود موفق از دو عامل مستقل Authentication استفاده می‌کند.

برای مثال:

عامل اول:
Password

+

عامل دوم:
کد TOTP از Authenticator App

فقط در صورتی که هر دو عامل صحیح باشند، Login انجام می‌شود.

WordPress نیز در مستندات امنیتی خود توضیح می‌دهد که ورود صرفاً با Password بر پایه چیزی است که کاربر «می‌داند»، در حالی که Two-Step Authentication می‌تواند Password را با چیزی که کاربر «در اختیار دارد» ترکیب کند.

این موضوع باعث می‌شود سرقت Password به‌تنهایی برای ورود کافی نباشد.

عوامل احراز هویت چه هستند؟

برای درک واقعی 2FA باید مفهوم Authentication Factor را بشناسیم.

سه دسته اصلی که در سیستم‌های وب بیشتر استفاده می‌شوند عبارت‌اند از:

چیزی که می‌دانید؛ Something You Know

مثل:

• Password
• PIN

این عامل مبتنی بر دانش کاربر است.

چیزی که دارید؛ Something You Have

مثل:

• گوشی
• Authenticator
• Hardware Token
• Security Key
• Smart Card

در این حالت کاربر باید به یک Device یا Credential خاص دسترسی داشته باشد.

چیزی که هستید؛ Something You Are

این دسته شامل ویژگی‌های Biometric است، مانند:

• Fingerprint
• Face Recognition
• Iris

البته در معماری‌های مدرن، Biometric معمولاً به‌صورت Local برای Unlock کردن یک Authenticator استفاده می‌شود و الزاماً Template بیومتریک برای سایت ارسال نمی‌شود.

NIST در راهنمای جدید SP 800-63B نیز تأکید می‌کند که ویژگی Biometric به‌تنهایی در مدل مربوطه Authenticator مستقل محسوب نمی‌شود و معمولاً همراه یک Physical Authenticator استفاده می‌شود.

تفاوت دو مرحله‌ای و دو عاملی چیست؟

این دو اصطلاح اغلب به جای یکدیگر استفاده می‌شوند، اما از نظر مفهومی تفاوت ظریفی دارند.

Two-Step Verification یعنی Login در دو مرحله انجام شود.

Two-Factor Authentication یعنی دو عامل مستقل از دو Category متفاوت Authentication استفاده شوند.

فرض کنید سیستم از شما ابتدا Password و سپس پاسخ Security Question را بخواهد.

از نظر ظاهری:

دو مرحله وجود دارد.

اما هر دو از نوع:

Something You Know

هستند.

بنابراین لزوماً یک 2FA واقعی و قوی ایجاد نشده است.

در مقابل:

Password + Hardware Security Key

دو عامل متفاوت هستند:

Something You Know + Something You Have

به همین دلیل هنگام ارزیابی امنیت بهتر است به «استقلال عامل‌ها» توجه کنیم، نه صرفاً تعداد صفحه‌هایی که کاربر برای Login طی می‌کند.

تفاوت 2FA و MFA چیست؟

MFA مخفف Multi-Factor Authentication است.

2FA در واقع زیرمجموعه MFA محسوب می‌شود.

اگر دقیقاً دو عامل داشته باشیم:

2FA

اگر دو یا چند عامل مستقل در معماری Authentication دخالت داشته باشند:

MFA

در استفاده روزمره این اصطلاح‌ها گاهی به جای یکدیگر استفاده می‌شوند.

برای اکثر سایت‌ها هدف اصلی این است که Password تنها عامل تعیین‌کننده ورود نباشد.

چرا Password به‌تنهایی کافی نیست؟

داشتن Password قوی همچنان ضروری است.

اما حتی Password بسیار قوی نیز می‌تواند دزدیده شود.

برای مثال ممکن است کاربر یک Password Manager داشته باشد و رمز ۳۰ کاراکتری تصادفی استفاده کند، اما آن را در یک صفحه Phishing وارد کند.

از نظر Entropy رمز مشکلی ندارد.

مشکل این است که Secret در اختیار مهاجم قرار گرفته است.

سایر مسیرهای افشای Password شامل موارد زیر هستند:

• Phishing
• Infostealer Malware
• Data Breach
• Credential Stuffing
• استفاده مجدد Password
• Browser Malware
• سیستم آلوده
• Social Engineering

بنابراین افزایش طول Password تمام Threat Model را پوشش نمی‌دهد.

2FA تلاش می‌کند یک مانع مستقل دیگر ایجاد کند.

2FA چگونه امنیت سایت را افزایش می‌دهد؟

فرض کنیم Password حساب مدیر یک سایت افشا شده است.

بدون 2FA

مهاجم Username و Password را وارد می‌کند.

اگر Credential صحیح باشد:

Username + Password
↓
Login Successful

تمام.

با 2FA

جریان به شکل زیر تغییر می‌کند:

Username + Password
↓
اعتبارسنجی مرحله اول
↓
درخواست عامل دوم
↓
TOTP / Security Key / Passkey
↓
Verification
↓
Login Successful

در این حالت Password سرقت‌شده تنها یکی از دو عامل لازم است.

بنابراین مهاجم باید مانع دیگری را نیز پشت سر بگذارد.

2FA در برابر Brute Force چه کمکی می‌کند؟

در Brute Force مهاجم تلاش می‌کند Password حساب را حدس بزند.

اگر در نهایت Password صحیح پیدا شود، در سیستم تک‌عاملی حساب در معرض خطر قرار می‌گیرد.

اما در حساب دارای 2FA هنوز عامل دوم وجود دارد.

البته این بدان معنا نیست که پس از فعال کردن 2FA دیگر نیازی به Rate Limiting یا محافظت Brute Force نداریم.

سیستم Login همچنان باید دارای:

• Rate Limit
• Login Throttling
• Password Policy
• Monitoring

باشد.

OWASP نیز MFA را در کنار Login Throttling و سایر کنترل‌های Authentication توصیه می‌کند، نه به‌عنوان جایگزین آن‌ها.

2FA در برابر Credential Stuffing

Credential Stuffing زمانی اتفاق می‌افتد که Username و Password افشاشده از یک سرویس دیگر روی سایت‌های دیگر امتحان شوند.

این حمله زمانی بسیار مؤثر است که کاربران Password خود را Reuse کنند.

اگر سایت 2FA داشته باشد، حتی Credential صحیح معمولاً به‌تنهایی برای Login کافی نیست.

به همین دلیل 2FA یکی از کنترل‌های بسیار مهم در برابر حملات مبتنی بر Credential سرقت‌شده محسوب می‌شود.

آیا 2FA جلوی Phishing را می‌گیرد؟

اینجا باید بسیار دقیق باشیم.

پاسخ:

بستگی به نوع 2FA دارد.

یکی از اشتباهات رایج این است که تصور کنیم هر نوع احراز هویت دو مرحله‌ای کاملاً ضد Phishing است.

این‌طور نیست.

TOTP و Phishing

اگر کاربر کد TOTP را در یک سایت جعلی وارد کند، مهاجم ممکن است همان کد را در مدت اعتبار کوتاه آن به سایت اصلی Relay کند.

NIST صراحتاً Authenticatorهایی را که نیازمند وارد کردن دستی OTP هستند Phishing-Resistant تلقی نمی‌کند؛ زیرا خروجی Authentication به Session و Verifier واقعی متصل نشده است.

WebAuthn و Phishing

WebAuthn از Public-Key Cryptography و Credentialهایی استفاده می‌کند که به Relying Party یا دامنه مربوطه Scope شده‌اند.

در نتیجه Credential مربوط به سایت واقعی در Origin جعلی قابل استفاده نیست.

این یکی از دلایلی است که WebAuthn، Passkey و FIDO2 در بحث Authentication مدرن اهمیت زیادی پیدا کرده‌اند. استاندارد WebAuthn نیز Credentialهای Public-Key را برای Relying Party مشخص ایجاد و Scope می‌کند.

انواع روش‌های احراز هویت دو مرحله‌ای

همه روش‌های 2FA از نظر امنیت، هزینه و تجربه کاربری یکسان نیستند.

2FA پیامکی

در این روش پس از Password، یک OTP از طریق SMS ارسال می‌شود.

کاربر آن را وارد کرده و Login تکمیل می‌شود.

مزایای SMS:

• برای عموم کاربران آشناست؛
• نیاز به نصب Authenticator ندارد؛
• پیاده‌سازی UX آن ساده است.

اما معایب مهمی دارد:

• SIM Swap
• Number Porting
• خطرهای مرتبط با شبکه مخابرات
• نمایش پیام روی Lock Screen
• امکان Phishing
• وابستگی به اپراتور
• هزینه ارسال SMS

در نسخه جدید NIST SP 800-63B-4 استفاده از PSTN برای Out-of-Band Authentication به‌عنوان Restricted Authenticator در نظر گرفته شده است. OWASP نیز استفاده از SMS را برای Applicationهای دارای ریسک مالی یا اطلاعات حساس گزینه مناسبی نمی‌داند و مهاجرت به TOTP، Push یا WebAuthn/FIDO2 را توصیه می‌کند.

پس SMS بهتر از Password تنها است، اما معمولاً بهترین 2FA موجود نیست.

TOTP چیست؟

TOTP مخفف:

Time-Based One-Time Password

است.

این همان مدلی است که بسیاری از Authenticator Appها استفاده می‌کنند.

در Setup اولیه، سایت و Authenticator یک Secret مشترک دارند.

Authenticator سپس براساس آن Secret و زمان فعلی، کدهای کوتاه‌عمر تولید می‌کند.

مزیت مهم TOTP این است که برای تولید کد به دریافت SMS نیاز ندارد.

پس از Enrollment اولیه، Authenticator می‌تواند حتی Offline کد تولید کند.

OWASP نیز TOTP Software Tokens را یکی از روش‌های رایج MFA معرفی می‌کند.

مزایای TOTP

TOTP چند مزیت مهم دارد:

• Standardized است؛
• به اپراتور تلفن وابسته نیست؛
• هزینه ارسال SMS ندارد؛
• در بسیاری از Authenticatorها پشتیبانی می‌شود؛
• برای سایت‌های معمولی قابل پیاده‌سازی است؛
• از Password تنها بسیار قوی‌تر است.

برای بسیاری از سایت‌های وردپرسی، TOTP نقطه شروع خوبی برای 2FA محسوب می‌شود.

محدودیت‌های TOTP

TOTP بی‌نقص نیست.

مهم‌ترین محدودیت آن Phishing است.

کاربر می‌تواند کد معتبر را ناخواسته در سایت جعلی وارد کند.

همچنین:

• دستگاه می‌تواند آلوده شود؛
• Backup Seed ممکن است ناامن ذخیره شود؛
• گوشی ممکن است گم شود؛
• Clock Drift باید مدیریت شود؛
• Recovery مناسب لازم است.

بنابراین TOTP یک کنترل امنیتی قوی است، اما Phishing-Resistant محسوب نمی‌شود.

Push Authentication چیست؟

برخی سیستم‌ها به‌جای وارد کردن OTP، روی گوشی Notification ارسال می‌کنند.

کاربر درخواست Login را Approve می‌کند.

این روش UX راحت‌تری دارد.

اما یک ریسک شناخته‌شده دارد:

MFA Fatigue یا Push Fatigue.

در این حمله مهاجم پس از داشتن Password، بارها درخواست تأیید ارسال می‌کند تا کاربر:

• از روی خستگی؛
• اشتباه؛
• یا تصور اینکه Notification متعلق به خودش است

آن را Approve کند.

بنابراین Push ساده «Yes/No» بدون Context قوی بهترین طراحی نیست.

Number Matching و نمایش اطلاعات Login می‌تواند وضعیت را بهتر کند، اما Phishing-Resistant Cryptographic Authentication همچنان سطح متفاوتی از امنیت ارائه می‌دهد.

Hardware Security Key چیست؟

Security Key یک Authenticator فیزیکی است که معمولاً از استانداردهایی مانند FIDO2/WebAuthn استفاده می‌کند.

کاربر ممکن است کلید را از طریق:

• USB
• NFC
• فناوری‌های پشتیبانی‌شده دیگر

به Device متصل کند.

مزیت اصلی در مدل مناسب WebAuthn این است که Authentication بر اساس Cryptographic Challenge انجام می‌شود.

Private Key از Authenticator خارج نمی‌شود.

OWASP Hardware U2F/FIDO-based Authentication را در میان روش‌های مقاوم‌تر در برابر Phishing معرفی می‌کند.

برای حساب‌های بسیار حساس مانند:

• Administrator
• Server Management
• Hosting Panel
• Identity Provider
• Developer Accounts

Security Key انتخاب بسیار جذابی است.

Passkey چیست؟

Passkey نسل جدیدتری از Authentication مبتنی بر FIDO/WebAuthn است.

به‌جای Shared Password، از Public-Key Cryptography استفاده می‌شود.

در Registration:

یک Key Pair ایجاد می‌شود.

Private Key نزد Authenticator باقی می‌ماند و Public Key در اختیار سرویس قرار می‌گیرد.

در Login، سایت یک Challenge ارائه می‌کند و Authenticator آن را امضا می‌کند.

W3C در WebAuthn Level 3 این مدل را بر پایه Public Key Credentialهایی تعریف می‌کند که برای Relying Party مشخص Scope شده‌اند.

آیا Passkey همان 2FA است؟

نه همیشه به معنای سنتی Password + OTP.

Passkey می‌تواند خودش یک Multi-Factor Authenticator باشد.

برای مثال Device چیزی است که کاربر دارد و Unlock آن ممکن است نیازمند:

• PIN
• Fingerprint
• Face Recognition

باشد.

OWASP Passkeyها را به‌عنوان شکل بسیار امنی از Authentication معرفی می‌کند که می‌توانند ویژگی‌های Possession را با Knowledge یا Inherence ترکیب کنند و در برابر Phishing مقاوم باشند.

بنابراین معماری آینده Authentication الزاماً این نیست:

Password → OTP

ممکن است Passwordless و مبتنی بر Passkey باشد.

مقایسه روش‌های مهم 2FA

این جدول نباید به‌عنوان رتبه‌بندی مطلق برای تمام سیستم‌ها دیده شود. Threat Model و شیوه پیاده‌سازی اهمیت زیادی دارند.

کدام روش 2FA برای سایت بهتر است؟

برای یک وب‌سایت عمومی، پاسخ به حساسیت حساب‌ها بستگی دارد.

سایت محتوایی کوچک

TOTP می‌تواند انتخاب مناسبی باشد.

حداقل:

Administrator و Editor

بهتر است 2FA داشته باشند.

فروشگاه اینترنتی

برای:

• Administrator
• Shop Manager
• پشتیبانی با دسترسی به اطلاعات کاربران

استفاده از MFA جدی‌تر توصیه می‌شود.

SaaS یا سیستم سازمانی

بهتر است گزینه‌های Phishing-Resistant مانند WebAuthn/Passkeys نیز بررسی شوند.

سیستم بسیار حساس

Hardware-backed Authentication و سیاست‌های سازمانی سخت‌گیرانه‌تر مناسب هستند.

NIST در SP 800-63B-4 برای AAL2 ارائه حداقل یک گزینه Phishing-Resistant را مطرح می‌کند و برای AAL3 الزامات بسیار قوی‌تری در زمینه Cryptographic Authenticator در نظر می‌گیرد.

آیا Email Code یک 2FA واقعی است؟

این موضوع محل بحث است.

فرض کنید:

Password سایت = عامل اول

و Code به Email ارسال شود.

اگر Email روی همان Device باز باشد و خودش MFA نداشته باشد، استقلال عامل دوم می‌تواند ضعیف باشد.

همچنین کاربران گاهی Passwordهای مشابه یا حتی یکسان برای Email و سایت استفاده می‌کنند.

OWASP نیز اشاره می‌کند که درباره اینکه Email واقعاً یک Factor مستقل محسوب می‌شود بحث وجود دارد.

به همین دلیل Email OTP معمولاً نباید قوی‌ترین گزینه MFA شما باشد.

2FA باید برای چه حساب‌هایی اجباری باشد؟

اگر قرار نیست از روز اول برای همه کاربران اجباری شود، اولویت با حساب‌های High Privilege است.

یعنی:

• Administrator
• Super Admin
• Server Administrator
• Shop Manager
• Editorهای دارای دسترسی حساس
• Developer
• Support Staff
• حساب‌های مالی

OWASP توصیه می‌کند MFA حداقل برای کاربران Administrative و High Privilege اجباری شود.

در سایت‌هایی که اطلاعات حساس دارند، می‌توان 2FA را برای تمام کاربران اجباری کرد.

Step-Up Authentication چیست؟

لازم نیست همیشه تمام کاربران برای هر Action دوباره 2FA انجام دهند.

می‌توان برای Actionهای حساس Step-Up Authentication اجرا کرد.

مثلاً کاربر Login کرده است، اما می‌خواهد:

• Password را تغییر دهد؛
• Email حساب را عوض کند؛
• 2FA را خاموش کند؛
• API Key بسازد؛
• برداشت مالی انجام دهد؛
• Administrator جدید ایجاد کند.

در این حالت Application دوباره عامل قوی Authentication درخواست می‌کند.

این مدل باعث می‌شود Security افزایش یابد بدون اینکه UX برای تمام عملیات روزمره بیش از حد دشوار شود.

فرایند اصولی راه‌اندازی TOTP چگونه است؟

یک Enrollment استاندارد را می‌توان به‌صورت زیر تصور کرد.

مرحله ۱: کاربر از قبل Login است

اما صرف Active Session برای تغییر Authentication Factor کافی نیست.

برای Action حساس بهتر است Reauthentication انجام شود.

مرحله ۲: ایجاد Secret

Server یک Secret امن و تصادفی تولید می‌کند.

این Secret باید به‌شکل امن مدیریت شود.

مرحله ۳: نمایش QR Code

Secret در قالب استاندارد به Authenticator منتقل می‌شود.

مرحله ۴: کاربر کد اولیه را وارد می‌کند

سیستم نباید صرفاً با نمایش QR فرض کند Setup موفق بوده است.

کاربر باید حداقل یک OTP معتبر ارائه کند تا مشخص شود Authenticator درست اضافه شده است.

مرحله ۵: فعال شدن 2FA

پس از Verification، Factor به Account Bind می‌شود.

مرحله ۶: Recovery Code

Backup Codeهای یک‌بارمصرف در اختیار کاربر قرار می‌گیرد.

OTP باید چه ویژگی‌های امنیتی داشته باشد؟

OWASP برای OTP چند اصل مهم مطرح می‌کند:

• عمر کوتاه داشته باشد؛
• Single Use باشد؛
• تعداد Attempt محدود باشد؛
• پس از Verification موفق Invalid شود؛
• در Log ثبت نشود؛
• با Randomness امن تولید شود.

این موارد مخصوصاً در OTPهای Server-generated اهمیت دارند.

OTP یک Password دائمی نیست.

ماهیت امنیتی آن از کوتاه‌عمر و محدود بودن نیز می‌آید.

Rate Limiting برای کد 2FA ضروری است

فرض کنید OTP شش‌رقمی داریم.

فضای احتمالات محدود است.

پس Endpoint تأیید OTP نباید تعداد نامحدود Attempt قبول کند.

باید کنترل‌هایی مانند:

• Attempt Limit
• Cooldown
• Account Rate Limit
• IP/Device Risk Signal

وجود داشته باشد.

بدون این کنترل‌ها مهاجم می‌تواند Authentication Factor دوم را هدف Guessing قرار دهد.

Backup Code چیست؟

Backup Code مجموعه‌ای از کدهای اضطراری است که برای زمانی استفاده می‌شود که کاربر به عامل اصلی دسترسی ندارد.

مثلاً گوشی گم شده است.

کدها باید:

• تصادفی باشند؛
• فقط یک بار قابل استفاده باشند؛
• پس از مصرف Invalid شوند؛
• در محل امن نگهداری شوند.

OWASP ارائه Single-Use Recovery Codes هنگام Setup MFA را یکی از روش‌های بازیابی حساب معرفی می‌کند.

Backup Code را کجا نگه داریم؟

کاربر نباید Screenshot کدها را در همان گوشی Authenticator نگه دارد.

بهتر است در:

• Password Manager معتبر
• فضای امن آفلاین
• محل Secure Backup

ذخیره شوند.

هدف این است که از دست رفتن یک Device به معنی از دست رفتن هم‌زمان Factor و Recovery نباشد.

Recovery مهم‌تر از چیزی است که تصور می‌کنیم

یک سیستم 2FA ممکن است Login بسیار امنی داشته باشد اما Recovery بسیار ضعیفی ارائه کند.

در این صورت مهاجم به جای شکست 2FA مستقیماً سراغ:

«من گوشیم را گم کرده‌ام، 2FA را برایم خاموش کنید.»

می‌رود.

اگر Support بدون Identity Verification مناسب این درخواست را قبول کند، تمام ارزش 2FA از بین می‌رود.

OWASP تأکید می‌کند که Recovery نباید راه آسان‌تری برای Bypass MFA و Account Takeover ایجاد کند.

تغییر شماره تلفن یا Authenticator یک عملیات حساس است

یکی دیگر از نقاط بسیار مهم:

Change MFA Factor

است.

فرض کنید مهاجم Session کاربر را سرقت کرده است.

اگر بتواند بدون درخواست Factor فعلی، Authenticator جدید اضافه کند، می‌تواند 2FA قربانی را تصاحب کند.

OWASP پیشنهاد می‌کند برای تغییر MFA Factor:

• Factor فعلی دوباره تأیید شود؛
• فقط به Active Session اعتماد نشود؛
• تغییر Factor High-Risk Action محسوب شود؛
• کاربر از طریق Channel دیگری Notify شود؛
• در حساب‌های حساس Step-Up Verification اعمال شود.

آیا بعد از Login موفق با 2FA دیگر حساب کاملاً امن است؟

خیر.

2FA عمدتاً Authentication را تقویت می‌کند.

اما اگر مهاجم Session Token معتبر را سرقت کند، ممکن است اصلاً نیازی به Login مجدد نداشته باشد.

بنابراین سایت همچنان به Session Security نیاز دارد.

کنترل‌های مهم شامل:

• Secure Cookie
• HttpOnly
• SameSite
• TLS
• Session Rotation
• Session Expiration
• Reauthentication
• XSS Prevention

هستند.

2FA جایگزین امنیت Session نیست.

ارتباط XSS و 2FA

Cross-Site Scripting می‌تواند Context کاربر Login شده را هدف قرار دهد.

در چنین شرایطی مهاجم لزوماً لازم نیست Password یا OTP را بداند.

اگر Script مخرب در Origin سایت اجرا شود، ممکن است بتواند Actionهایی را در Session کاربر انجام دهد.

به همین دلیل:

2FA ≠ رفع XSS

2FA یک لایه Authentication است.

برای XSS همچنان نیازمند:

• Output Encoding
• Sanitization
• CSP
• Secure Development

هستیم.

ارتباط CSRF و 2FA

2FA به‌تنهایی CSRF را هم متوقف نمی‌کند.

اگر کاربر Login باشد و Endpoint حساس CSRF Protection نداشته باشد، ممکن است Browser قربانی Request ناخواسته ارسال کند.

برای Action بسیار حساس می‌توان Reauthentication را نیز اضافه کرد، اما CSRF Protection همچنان باید مستقل اجرا شود.

ارتباط WAF و 2FA

WAF و 2FA دو Layer متفاوت هستند.

WAF:

Request را بررسی می‌کند.

2FA:

هویت کاربر را تقویت می‌کند.

یک Architecture خوب می‌تواند همزمان داشته باشد:

WAF
↓
Login Rate Limiting
↓
Password Authentication
↓
2FA
↓
Session Security
↓
Authorization

این همان Defense in Depth است.

2FA در وردپرس چگونه کار می‌کند؟

مستندات رسمی WordPress استفاده از Two-Step Authentication را برای افزایش امنیت Login توضیح می‌دهد و Repository رسمی WordPress.org نیز Pluginهای مختلفی برای 2FA دارد.

در یک سایت وردپرسی معمولاً Plugin مربوطه فرایند Login را توسعه می‌دهد.

جریان ممکن است به شکل زیر باشد:

wp-login.php
↓
Username + Password
↓
تأیید Credential
↓
درخواست Factor دوم
↓
TOTP / Email / WebAuthn
↓
ورود به wp-admin

کدام کاربران وردپرس باید 2FA داشته باشند؟

اولویت پیشنهادی:

1. Administrator
2. Editor
3. Shop Manager
4. کاربران دارای دسترسی به داده حساس

برای Subscriber معمولی، اجباری بودن 2FA به Threat Model و نوع سایت بستگی دارد.

اگر سایت:

• کیف پول
• اطلاعات مالی
• اطلاعات شخصی حساس
• دارایی دیجیتال

نگهداری می‌کند، Scope می‌تواند گسترده‌تر باشد.

هنگام انتخاب افزونه 2FA وردپرس چه چیزهایی مهم است؟

فقط تعداد نصب را نگاه نکنید.

موارد زیر اهمیت دارند:

• آخرین Update
• سازگاری با نسخه WordPress
• توسعه فعال
• TOTP استاندارد
• Backup Code
• Role Enforcement
• Recovery Process
• Logging
• Compatibility با WooCommerce
• سازگاری با Loginهای سفارشی
• Security History
• WebAuthn Support در صورت نیاز

Repository رسمی WordPress گزینه‌های متعددی در این زمینه ارائه می‌دهد و بعضی Pluginها TOTP یا Integrationهای WebAuthn را پشتیبانی می‌کنند.

آیا Application Password وردپرس جای 2FA را می‌گیرد؟

خیر.

Application Passwords در WordPress برای Authentication برنامه‌ها، Scriptها و APIها طراحی شده‌اند.

مستندات رسمی WordPress صراحتاً می‌گوید Application Password برای Login تعاملی کاربران در wp-login.php نیست و برای Login انسانی باید از Password قوی و در صورت نیاز Two-Step Authentication استفاده شود.

این دو مفهوم را نباید با یکدیگر اشتباه گرفت.

بهترین معماری 2FA برای سایت

یک جریان پیشنهادی می‌تواند چنین باشد:

User Login
↓
Password Verification
↓
Risk Evaluation
↓
Second Factor
↓
Attempt Limit
↓
Verification
↓
Session Rotation
↓
Login Notification
↓
Monitoring

برای Actionهای حساس:

Sensitive Action
↓
Reauthentication
↓
Step-Up MFA
↓
Authorization Check
↓
Execute Action

این مدل امنیت بسیار بیشتری نسبت به اضافه کردن یک صفحه OTP ساده دارد.

Risk-Based Authentication چیست؟

در برخی سیستم‌ها شدت Authentication براساس Risk تغییر می‌کند.

مثلاً Login از:

• Device شناخته‌شده
• Location معمول
• Browser قبلی

ممکن است UX ساده‌تری داشته باشد.

اما Login از:

• Device جدید
• Country جدید
• IP پرریسک
• رفتار غیرمعمول

می‌تواند Step-Up MFA ایجاد کند.

Risk-Based Authentication می‌تواند UX را بهتر کند، اما نباید به شکلی طراحی شود که کاربران High Privilege عملاً بدون Factor قوی وارد شوند.

Login Notification چه اهمیتی دارد؟

پس از Login از Device جدید می‌توان به کاربر Alert ارسال کرد.

اطلاعات مفید:

• زمان
• Browser
• Location تقریبی
• Device

اگر Login متعلق به کاربر نباشد، باید مسیر سریع برای:

• تغییر Password
• Logout All Sessions
• بررسی MFA

وجود داشته باشد.

OWASP نیز در Failed MFA Scenarios توصیه می‌کند تلاش مشکوک Login به کاربر اطلاع داده شود.

اشتباهات رایج در پیاده‌سازی 2FA

۱. اجباری نکردن 2FA برای Administrator

داشتن قابلیت 2FA ولی غیرفعال بودن آن روی حساب اصلی تقریباً فایده‌ای ندارد.

۲. اعتماد کامل به SMS

SMS بهتر از Password تنهاست، اما برای سیستم حساس انتخاب نهایی مناسبی نیست.

۳. نداشتن Backup Code

گم شدن گوشی نباید باعث قفل دائمی حساب شود.

۴. Recovery ضعیف

Support نباید بتواند تنها با چند سؤال ساده MFA را خاموش کند.

۵. امکان Disable کردن 2FA فقط با Session

برای غیرفعال کردن MFA باید Reauthentication انجام شود.

۶. OTP بدون Rate Limit

Endpoint کد باید Attempt Limit داشته باشد.

۷. ثبت OTP در Log

Authentication Secret نباید وارد Log شود.

۸. استفاده از Security Question به‌عنوان Factor دوم

Password و Security Question هر دو Knowledge Factor هستند.

۹. تصور اینکه TOTP ضد Phishing است

TOTP قابل Phishing و Relay شدن است.

۱۰. نداشتن Monitoring

تعداد زیاد Failed Second Factor می‌تواند نشانه Credential Compromise باشد.

۱۱. فراموش کردن APIها

اگر Web Login 2FA دارد ولی API Endpoint با Password ساده Admin قابل دسترسی باشد، Authentication Architecture ناقص است.

۱۲. نادیده گرفتن Service Accountها

برای Machine-to-Machine Authentication باید مکانیزم مناسب دیگری مانند Keys، Certificates یا Tokenهای محدود استفاده شود.

2FA انسانی را نباید به زور روی Service Account اعمال کرد.

اگر کاربر Factor دوم را گم کرد چه کنیم؟

یک Recovery Flow امن باید از ابتدا طراحی شود.

روش‌های ممکن:

• Backup Code
• Factor دوم ثبت‌شده دیگر
• Hardware Key دوم
• Recovery Process کنترل‌شده
• Support Identity Verification

OWASP تأکید می‌کند که یک «بهترین روش واحد» برای Recovery تمام سیستم‌ها وجود ندارد و روش مناسب باید براساس حساسیت Application انتخاب شود.

آیا باید چند Factor ثبت کنیم؟

برای کاربران حساس، داشتن بیش از یک Authenticator بسیار مفید است.

مثلاً:

Primary:

Passkey / Security Key

Backup:

Security Key دوم

Recovery:

Single-use Backup Codes

این مدل بهتر از وابستگی کامل به یک گوشی است.

امنیت QR Code در TOTP

QR Code راه انتقال TOTP Secret است.

بنابراین باید مانند Credential حساس مدیریت شود.

نباید:

• Public URL داشته باشد؛
• در Log ذخیره شود؛
• برای مدت طولانی دوباره قابل مشاهده باشد؛
• برای هر کسی که Session دارد بدون Reauthentication نمایش داده شود.

اگر کسی Secret اولیه را کپی کند، می‌تواند همان TOTPها را تولید کند.

آیا Screenshot گرفتن از QR Code مناسب است؟

خیر.

ذخیره Screenshot از TOTP Setup می‌تواند عملاً یک Clone از Factor دوم ایجاد کند.

کاربر باید به‌جای نگه داشتن Setup QR از Recovery Code امن استفاده کند.

2FA و Password Manager

Password Manager و 2FA مکمل یکدیگر هستند.

Password Manager:

• Passwordهای Unique
• Passwordهای تصادفی
• کاهش Reuse

را فراهم می‌کند.

2FA نیز Factor مستقلی اضافه می‌کند.

ترکیب این دو بسیار بهتر از استفاده از یک Password ثابت همراه SMS است.

آیا نگهداری TOTP داخل Password Manager بد است؟

از دید جداسازی عامل‌ها، اگر Password و TOTP هر دو در یک Vault و یک Device نگهداری شوند، استقلال عملی آن‌ها کاهش می‌یابد.

اما Threat Model اهمیت دارد.

برای بسیاری از کاربران، Password Manager امن همراه TOTP همچنان بسیار بهتر از:

Password Reuse + بدون MFA

است.

برای حساب‌های High Security می‌توان Factor را روی Hardware Security Key یا Device مستقل نگهداری کرد.

2FA در برابر SIM Swap

اگر Factor دوم SMS باشد، SIM Swap اهمیت زیادی پیدا می‌کند.

در این حمله مهاجم تلاش می‌کند شماره قربانی را به SIM تحت کنترل خود منتقل کند.

پس از آن SMSهای Authentication ممکن است در اختیار مهاجم قرار بگیرند.

همین Threat یکی از دلایل Restricted شدن PSTN-based Authentication در راهنمای NIST است.

2FA در برابر Session Hijacking

اگر Session پس از Authentication سرقت شود، مهاجم ممکن است Login Flow را دور بزند.

برای همین پس از MFA باید:

• Session ID Rotate شود؛
• Cookie امن باشد؛
• Session Management استاندارد باشد؛
• Actionهای حساس Step-Up بخواهند.

یعنی Authentication قوی بدون Session Security کافی نیست.

2FA در برابر Malware

اگر Device کاربر آلوده به Infostealer یا Remote Access Malware باشد، حتی MFA ممکن است محدودیت‌هایی داشته باشد.

Malware می‌تواند:

• Browser Session را بدزدد؛
• Screen را مشاهده کند؛
• Input کاربر را ضبط کند.

Hardware-backed و Phishing-resistant Authentication می‌تواند بعضی ریسک‌ها را کاهش دهد، اما Endpoint Security همچنان ضروری است.

چک‌لیست فعال‌سازی 2FA در سایت

حساب‌های کاربری

• Administratorها 2FA دارند؟
• Editorها بررسی شده‌اند؟
• حساب‌های غیرفعال حذف شده‌اند؟
• Shared Account وجود ندارد؟

روش Authentication

• TOTP استاندارد استفاده می‌شود؟
• SMS تنها گزینه نیست؟
• امکان WebAuthn وجود دارد؟
• Recovery Code فراهم شده؟

OTP

• TTL کوتاه است؟
• Attempt Limit وجود دارد؟
• OTP Single Use است؟
• OTP Log نمی‌شود؟

تغییر MFA

• Reauthentication لازم است؟
• تغییر Factor Notification ایجاد می‌کند؟
• Session تنها برای Disable کافی نیست؟

Recovery

• Backup Code وجود دارد؟
• Recovery Code یک‌بارمصرف است؟
• Support Process امن است؟
• Recovery از Login ضعیف‌تر نیست؟

Monitoring

• Failed MFA ثبت می‌شود؟
• تغییر Factor ثبت می‌شود؟
• Device جدید Alert ایجاد می‌کند؟
• رفتار غیرعادی بررسی می‌شود؟

Session

• Secure Cookie فعال است؟
• HttpOnly فعال است؟
• SameSite مناسب است؟
• Session Rotation انجام می‌شود؟

اولویت پیشنهادی افزایش امنیت Login سایت

اگر سایت هنوز امنیت Login مناسبی ندارد، می‌توانید این ترتیب را دنبال کنید:

1. حذف حساب‌های اضافی
2. Passwordهای Unique و قوی
3. فعال کردن 2FA برای Administrator
4. ترجیح TOTP بر SMS
5. بررسی WebAuthn/Passkey برای حساب‌های حساس
6. فعال کردن Backup Codes
7. Rate Limiting
8. Login Monitoring
9. Session Security
10. Recovery امن

آیا 2FA سرعت سایت را کاهش می‌دهد؟

در حالت عادی تأثیر محسوسی روی Performance عمومی سایت ندارد.

2FA عمدتاً هنگام:

• Login
• Reauthentication
• Action حساس

فعال است.

مشکلات Performance بیشتر ممکن است از Plugin بد، سرویس Third-Party کند یا Architecture نامناسب ایجاد شوند.

آیا 2FA باعث اذیت کاربران می‌شود؟

ممکن است Friction Login کمی بیشتر شود.

اما می‌توان UX را مدیریت کرد.

روش‌هایی مانند:

• Passkey
• Security Key
• Trusted Device با سیاست محدود
• Risk-Based Authentication

می‌توانند تجربه را بهتر کنند.

نباید برای راحتی، Security حساب Administrator قربانی شود.

آیا Remember This Device امن است؟

این قابلیت می‌تواند UX را بهتر کند، اما باید دقیق طراحی شود.

اگر Device به‌عنوان Trusted ثبت می‌شود:

• Token باید امن باشد؛
• عمر محدود داشته باشد؛
• قابل Revoke باشد؛
• Deviceها در پنل قابل مشاهده باشند؛
• Actionهای حساس همچنان Step-Up بخواهند.

«مرا برای همیشه به خاطر بسپار» برای حساب High Privilege طراحی خوبی نیست.

بهترین 2FA برای مدیر سایت چیست؟

اگر بخواهیم از نظر امنیتی اولویت‌بندی کنیم:

سطح خوب

Password قوی + TOTP

سطح بهتر

Password + WebAuthn Security Key

سطح بسیار مناسب برای معماری مدرن

Passkey/WebAuthn با Recovery امن و Authenticator دوم

برای Administratorهای سایت‌های حساس، روش Phishing-Resistant ارزش بیشتری دارد.

آیا 2FA جای CAPTCHA را می‌گیرد؟

خیر.

CAPTCHA تلاش می‌کند Automation و Bot Activity را کاهش دهد.

2FA Identity Verification را تقویت می‌کند.

هدف‌های متفاوتی دارند.

ممکن است یک Login Architecture همزمان شامل:

Rate Limiting + Bot Protection + 2FA

باشد.

آیا 2FA جای WAF را می‌گیرد؟

خیر.

WAF حملات Web Layer را بررسی می‌کند.

2FA Account Authentication را تقویت می‌کند.

هیچ‌کدام جای دیگری نیستند.

آیا با 2FA سایت هک نمی‌شود؟

خیر.

این یکی از مهم‌ترین سوءبرداشت‌هاست.

2FA فقط بخشی از Attack Surface را پوشش می‌دهد.

اگر سایت دارای:

• SQL Injection
• RCE
• File Upload Vulnerability
• XSS
• Plugin آسیب‌پذیر
• Server Misconfiguration

باشد، 2FA این مشکلات را رفع نمی‌کند.

اما اگر حمله نیازمند تصاحب Account باشد، MFA می‌تواند یک مانع بسیار مهم ایجاد کند.

معماری امنیت Login چندلایه

یک معماری مناسب می‌تواند به شکل زیر باشد:

HTTPS
↓
WAF / Rate Limiting
↓
Username + Strong Password
↓
2FA / MFA
↓
Secure Session
↓
Authorization
↓
Step-Up Authentication
↓
Logging & Monitoring

2FA زمانی بیشترین ارزش را دارد که بخشی از این معماری باشد.

سؤالات متداول درباره احراز هویت دو مرحله‌ای

احراز هویت دو مرحله‌ای چیست؟

احراز هویت دو مرحله‌ای یا 2FA روشی است که برای ورود علاوه بر Password، عامل دیگری مانند TOTP، Security Key یا Passkey درخواست می‌کند.

2FA چه فایده‌ای دارد؟

اگر Password کاربر سرقت شود، مهاجم هنوز به Factor دوم نیاز دارد. بنابراین خطر Account Takeover کاهش پیدا می‌کند.

تفاوت 2FA و MFA چیست؟

2FA دقیقاً از دو عامل Authentication استفاده می‌کند. MFA مفهوم گسترده‌تری است و می‌تواند شامل دو یا چند Factor باشد.

بهترین روش 2FA کدام است؟

برای امنیت بالا، WebAuthn/FIDO2 و Passkeyها گزینه‌های مهم Phishing-Resistant هستند. TOTP نیز برای سایت‌های معمولی گزینه مناسبی است، اما در برابر Phishing مصون نیست.

آیا Google Authenticator امن است؟

Authenticatorهای مبتنی بر استاندارد TOTP در صورت استفاده صحیح می‌توانند Factor دوم مناسبی باشند. با این حال TOTP به‌طور ذاتی Phishing-Resistant نیست.

آیا کد پیامکی امن است؟

SMS بهتر از نداشتن Factor دوم است، اما به دلیل SIM Swap، Phishing و ریسک‌های شبکه مخابرات برای حساب‌های حساس بهترین گزینه نیست.

آیا Email OTP همان 2FA است؟

می‌تواند یک مرحله اضافه ایجاد کند، اما استقلال Factor آن به Security ایمیل و Architecture سیستم بستگی دارد و معمولاً از TOTP یا WebAuthn ضعیف‌تر است.

اگر گوشی گم شود چه کنیم؟

باید از Backup Code، Authenticator دوم یا Recovery Process امن استفاده شود.

Backup Code چیست؟

کدهای یک‌بارمصرف اضطراری هستند که هنگام از دست دادن Factor اصلی برای بازیابی دسترسی استفاده می‌شوند.

آیا Backup Code را در گوشی ذخیره کنیم؟

بهتر است نه. اگر گوشی گم شود، Factor اصلی و Recovery همزمان از دست می‌روند یا در اختیار شخص دیگری قرار می‌گیرند.

آیا مدیر سایت حتماً باید 2FA داشته باشد؟

برای Administratorها فعال‌سازی 2FA یکی از مهم‌ترین اقدامات امنیتی Login است و OWASP نیز MFA را برای حساب‌های دارای دسترسی بالا توصیه می‌کند.

آیا 2FA جلوی Brute Force را می‌گیرد؟

2FA اثر موفقیت Password Guessing را کاهش می‌دهد، اما Login همچنان باید Rate Limit و Brute Force Protection داشته باشد.

آیا 2FA ضد Phishing است؟

همه انواع آن نه. OTP و TOTP می‌توانند Phishing شوند. WebAuthn/FIDO2 به دلیل Binding رمزنگاری‌شده به Relying Party مقاومت بسیار بیشتری در برابر Phishing دارند.

آیا Passkey بهتر از Password و SMS است؟

از نظر مقاومت در برابر Phishing و معماری Public-Key، Passkey/WebAuthn می‌تواند سطح امنیت بالاتری ارائه دهد، البته Recovery و مدیریت Device همچنان مهم هستند.

آیا وردپرس از 2FA پشتیبانی می‌کند؟

وردپرس مستندات رسمی برای Two-Step Authentication دارد و Pluginهای مختلفی در Repository رسمی برای اضافه کردن TOTP، Backup Code و روش‌های دیگر موجود هستند.

آیا 2FA برای WooCommerce مفید است؟

بله، به‌خصوص برای Administrator، Shop Manager و حساب‌هایی که به اطلاعات سفارش یا مشتریان دسترسی دارند.

آیا 2FA امنیت API را هم تأمین می‌کند؟

نه لزوماً. API Authentication باید مکانیزم مستقل و مناسب خود مانند Token، Application Password محدود، OAuth، Certificate یا Key داشته باشد.

آیا بعد از فعال کردن 2FA می‌توان Password ساده انتخاب کرد؟

خیر. Factor اول نیز باید امن باشد. Defense in Depth یعنی هر Layer به‌درستی طراحی شود.

آیا تغییر Authenticator باید Password بخواهد؟

برای تغییر یا حذف MFA باید Reauthentication با Factor معتبر انجام شود و نباید صرف Active Session کافی باشد.

جمع‌بندی؛ آیا فعال کردن 2FA برای امنیت سایت ضروری است؟

احراز هویت دو مرحله‌ای یکی از مؤثرترین روش‌های افزایش امنیت حساب‌های کاربری و به‌خصوص حساب‌های مدیریتی سایت است.

در مدل سنتی Username و Password، تمام امنیت Login به یک Secret وابسته است. اگر Password در اثر Phishing، Credential Stuffing، Malware یا Data Breach افشا شود، مهاجم ممکن است مستقیماً وارد حساب شود.

2FA این معماری را با اضافه کردن Factor مستقل تغییر می‌دهد.

Password می‌تواند Something You Know باشد و TOTP، Security Key یا Device مورد اعتماد نقش Something You Have را ایفا کند.

اما تمام روش‌های 2FA کیفیت یکسانی ندارند.

SMS اگرچه از Password تنها بهتر است، در برابر SIM Swap، Phishing و برخی تهدیدهای مخابراتی آسیب‌پذیر است و NIST آن را در دسته Restricted Authenticator قرار داده است.

TOTP برای بسیاری از وب‌سایت‌ها گزینه‌ای کاربردی و استاندارد است. کاربران می‌توانند از Authenticator App استفاده کنند و بدون نیاز به SMS کد کوتاه‌عمر تولید کنند.

با این حال TOTP را نباید ضد Phishing دانست.

اگر کاربر OTP را در صفحه جعلی وارد کند، مهاجم ممکن است بتواند در همان بازه کوتاه آن را Relay کند.

برای حساب‌های حساس‌تر، WebAuthn، FIDO2، Hardware Security Key و Passkey اهمیت بیشتری پیدا می‌کنند. این روش‌ها بر Public-Key Cryptography تکیه دارند و Credential را به Relying Party مشخص Scope می‌کنند؛ به همین دلیل در برابر Phishing مقاومت بیشتری دارند.

پیاده‌سازی 2FA نیز فقط به نمایش یک QR Code خلاصه نمی‌شود.

OTP باید کوتاه‌عمر و Single Use باشد، Attempt Limit داشته باشد و نباید در Log ذخیره شود. Recovery Codeها باید امن باشند و تغییر MFA Factor باید دوباره Authentication بخواهد.

فرایند Recovery نیز به اندازه Login اهمیت دارد.

اگر مهاجم بتواند با یک تماس ساده با Support، MFA را Reset کند، قوی‌ترین Login Flow نیز بی‌اثر می‌شود.

برای سایت وردپرسی نیز بهتر است حداقل Administratorها و سایر کاربران High Privilege با 2FA محافظت شوند و Plugin مورد استفاده از TOTP استاندارد، Backup Code، Recovery مناسب، Role Enforcement و Monitoring پشتیبانی کند.

در نهایت باید به یاد داشت که احراز هویت دو مرحله‌ای سایت را در برابر تمام حملات ایمن نمی‌کند.

2FA جایگزین WAF، جلوگیری از XSS و CSRF، Patch Management، امنیت Session، Password Policy، Rate Limiting یا کنترل دسترسی نیست.

بهترین معماری، Defense in Depth است:

Password امن، 2FA یا MFA، Session Security، Authorization، WAF، Monitoring و Step-Up Authentication برای عملیات حساس.

اگر فقط یک اقدام برای افزایش امنیت Login حساب Administrator سایت خود انجام می‌دهید، فعال کردن یک روش 2FA مناسب ـ ترجیحاً حداقل TOTP و برای حساب‌های حساس‌تر WebAuthn یا Passkey ـ یکی از اقدامات با ارزش امنیتی بسیار بالا خواهد بود.