حملات Brute Force چیست؟ روش‌های جلوگیری از حملات ورود به سایت

صفحه ورود یکی از حساس‌ترین نقاط هر وب‌سایت است. تمام مکانیزم‌های کنترل دسترسی، نقش‌های کاربری و اطلاعات خصوصی زمانی ارزش امنیتی دارند که مهاجم نتواند به‌سادگی اعتبار ورود یک کاربر را حدس بزند یا از اطلاعات لو‌رفته برای ورود به حساب استفاده کند. یکی از شناخته‌شده‌ترین تهدیدهایی که مستقیماً این بخش را هدف قرار می‌دهد، حملات Brute Force یا حملات حدس رمز عبور است.

در ساده‌ترین تعریف، حمله Brute Force زمانی رخ می‌دهد که مهاجم تعداد زیادی ترکیب احتمالی نام کاربری و رمز عبور را برای دستیابی غیرمجاز به یک حساب آزمایش کند. اما حملات امروزی همیشه به شکل امتحان کردن هزاران رمز روی یک حساب انجام نمی‌شوند. Password Spraying، Credential Stuffing، حملات توزیع‌شده و استفاده از رمزهای افشاشده نمونه‌هایی هستند که می‌توانند سیستم‌های ورود ضعیف را با الگوهای متفاوت هدف قرار دهند.

OWASP در راهنمای Authentication خود بین Brute Force، Credential Stuffing و Password Spraying تفاوت قائل می‌شود. در Brute Force معمولاً چندین رمز علیه یک حساب امتحان می‌شوند؛ در Credential Stuffing ترکیب‌های نام کاربری و رمز عبور افشاشده از سرویس‌های دیگر آزمایش می‌شوند و در Password Spraying یک یا چند رمز رایج روی تعداد زیادی حساب امتحان می‌شود.

همین تفاوت نشان می‌دهد که جلوگیری از حملات Brute Force با مسدود کردن یک IP یا نصب CAPTCHA روی صفحه ورود تمام نمی‌شود. مهاجمان می‌توانند درخواست‌ها را میان IPهای متعدد توزیع کنند، از Credentialهای سرقت‌شده استفاده کنند یا تعداد تلاش‌ها علیه هر حساب را پایین نگه دارند تا سیستم‌های ساده تشخیص حمله متوجه رفتار غیرعادی نشوند.

برای دفاع مؤثر باید چند لایه امنیتی در کنار یکدیگر قرار گیرند: محدودسازی تلاش‌های ورود، احراز هویت چندمرحله‌ای، تشخیص رفتار ربات‌ها، سیاست رمز عبور مناسب، جلوگیری از Account Enumeration، مانیتورینگ رویدادهای ورود و محافظت ویژه از حساب‌های مدیریتی.

در این مقاله از رخنه کاو به‌طور کامل بررسی می‌کنیم حملات Brute Force چیست، چه انواعی دارد، چگونه صفحه ورود وب‌سایت‌ها را تهدید می‌کند، چه تفاوتی با Credential Stuffing و Password Spraying دارد و مهم‌تر از همه، چگونه می‌توان امنیت سایت و به‌خصوص سایت‌های وردپرسی را در برابر حملات ورود خودکار افزایش داد.

حمله Brute Force چیست؟

Brute Force به معنای تلاش برای پیدا کردن اطلاعات احراز هویت از طریق آزمودن تعداد زیادی احتمال است.

اگر یک سیستم ورود هیچ محدودیتی روی تعداد تلاش‌های ناموفق نداشته باشد، مهاجم می‌تواند بارها اطلاعات ورود مختلف را ارسال کند تا در نهایت یکی از ترکیب‌ها با حساب واقعی مطابقت داشته باشد.

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

اما مهاجمان امروزی الزاماً از روش کاملاً تصادفی استفاده نمی‌کنند. آن‌ها معمولاً احتمال‌های پرکاربرد را در اولویت قرار می‌دهند؛ زیرا رفتار کاربران قابل پیش‌بینی است.

بسیاری از کاربران هنوز از رمزهای:

• کوتاه
• قابل حدس
• مرتبط با نام یا تاریخ
• تکرارشده در چند سایت
• یا رمزهای افشاشده قبلی

استفاده می‌کنند.

به همین دلیل حمله‌ای که از نظر تئوری باید میلیون‌ها احتمال را امتحان کند، در عمل ممکن است با مجموعه‌ای بسیار کوچک‌تر از رمزهای رایج موفق شود.

OWASP نیز ضعف در مقابله با Brute Force، Credential Stuffing و دیگر حملات خودکار را از نشانه‌های مشکلات احراز هویت می‌داند. نسخه 2025 فهرست OWASP Top 10 نیز Authentication Failures را شامل سیستم‌هایی می‌داند که حملات خودکار را به‌سرعت محدود نمی‌کنند یا اجازه استفاده از رمزهای ضعیف و افشاشده را می‌دهند.

چرا حملات Brute Force هنوز مؤثر هستند؟

ممکن است تصور شود با وجود سیستم‌های امنیتی مدرن، Brute Force دیگر تهدید مهمی نیست. اما چند عامل باعث شده‌اند این حملات همچنان کاربرد داشته باشند.

استفاده مجدد از رمز عبور

بسیاری از کاربران یک رمز عبور را برای چند سرویس استفاده می‌کنند.

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

این رفتار پایه Credential Stuffing است.

OWASP توضیح می‌دهد که Credential Stuffing از ترکیب‌های نام کاربری و رمز عبور سرقت‌شده استفاده می‌کند و موفقیت آن تا حد زیادی به عادت کاربران در استفاده مجدد از رمزها وابسته است.

رمزهای قابل حدس

رمزهای ضعیف فضای جستجوی مهاجم را کاهش می‌دهند.

نام برند، شماره تلفن، سال تولد، کلمات ساده یا تغییرات جزئی یک رمز قدیمی ممکن است به‌راحتی قابل پیش‌بینی باشند.

نبود Rate Limiting

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

نبود MFA

زمانی که رمز عبور تنها عامل احراز هویت باشد، به دست آمدن رمز معمولاً به معنی عبور از مرحله ورود است.

افشای نام کاربری

اگر سایت مشخص کند کدام Username یا Email وجود دارد، مهاجم بخشی از مسئله را از قبل حل کرده است.

بات‌نت‌ها و IPهای متعدد

سیستم‌هایی که فقط براساس IP محدودیت ایجاد می‌کنند در برابر حملات توزیع‌شده ضعف دارند.

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

انواع حملات Brute Force

عبارت Brute Force گاهی برای مجموعه بزرگی از حملات علیه سیستم ورود استفاده می‌شود. شناخت تفاوت این روش‌ها برای انتخاب کنترل دفاعی اهمیت زیادی دارد.

Brute Force کلاسیک چیست؟

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

برای مثال اگر Username یک مدیر شناخته شده باشد، هدف حمله پیدا کردن رمز آن حساب خواهد بود.

این روش در برابر سیستم‌هایی که Rate Limiting و Lockout مناسب دارند بسیار سخت‌تر می‌شود.

چرا Brute Force تصادفی همیشه بهترین روش مهاجم نیست؟

هرچه رمز طولانی‌تر و غیرقابل پیش‌بینی‌تر باشد، تعداد ترکیب‌های ممکن به‌سرعت افزایش پیدا می‌کند.

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

این موضوع ما را به Dictionary Attack می‌رساند.

Dictionary Attack چیست؟

در Dictionary Attack به‌جای امتحان کردن تمام ترکیب‌های ممکن، مجموعه‌ای از رمزهای محتمل آزمایش می‌شود.

این مجموعه می‌تواند شامل:

• رمزهای رایج
• کلمات متداول
• الگوهای متداول کاربران
• رمزهای افشاشده
• تغییرات قابل پیش‌بینی کلمات

باشد.

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

OWASP توصیه می‌کند برنامه‌ها در زمان ساخت یا تغییر رمز، رمزهای شناخته‌شده و افشاشده را شناسایی و مسدود کنند. همچنین استفاده از Password Manager را تشویق کنند.

Password Spraying چیست؟

Password Spraying جهت حمله را تغییر می‌دهد.

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

فرض کنید یک سامانه هزار کاربر دارد.

اگر مهاجم فقط چند رمز متداول را برای هر حساب آزمایش کند، ممکن است هیچ حسابی به آستانه Lockout نرسد؛ در نتیجه سیستم‌های ساده‌ای که فقط تعداد خطاهای هر حساب را بررسی می‌کنند ممکن است حمله را دیر تشخیص دهند.

چرا Password Spraying خطرناک است؟

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

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

OWASP Password Spraying را جدا از Brute Force کلاسیک در نظر می‌گیرد، اما بسیاری از کنترل‌های دفاعی میان آن‌ها مشترک هستند.

Credential Stuffing چیست؟

Credential Stuffing یکی از مهم‌ترین تهدیدهای احراز هویت مدرن است.

در این روش مهاجم الزاماً رمز را حدس نمی‌زند؛ بلکه از ترکیب‌های Username و Password که در رخنه‌های اطلاعاتی سرویس‌های دیگر افشا شده‌اند استفاده می‌کند.

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

تفاوت Brute Force و Credential Stuffing

Credential Stuffing نشان می‌دهد حتی اگر خود سایت شما هرگز دچار نشت اطلاعات نشده باشد، ضعف امنیتی یک سرویس دیگر می‌تواند کاربران شما را در معرض خطر قرار دهد.

Distributed Brute Force چیست؟

در حمله Distributed Brute Force درخواست‌ها از IPهای متعدد ارسال می‌شوند.

هدف این است که محدودیت‌هایی که فقط براساس IP طراحی شده‌اند اثربخشی خود را از دست بدهند.

برای مثال اگر سایت هر IP را پس از چند تلاش مسدود کند، مهاجم می‌تواند تلاش‌ها را میان منابع متعدد تقسیم کند.

به همین دلیل Rate Limiting مدرن باید چند سیگنال را هم‌زمان بررسی کند.

OWASP در راهنمای ضد اتوماسیون توصیه می‌کند Endpoint ورود علاوه بر محدودسازی منبع درخواست، محدودیت مستقل برای خود حساب نیز داشته باشد؛ زیرا اتکا به یک Bucket ترکیبی IP و Username می‌تواند الگوهای Credential Stuffing را از کنترل خارج کند.

Reverse Brute Force چیست؟

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

از نظر عملی، Password Spraying نیز به این الگو نزدیک است.

این روش بار دیگر اهمیت جلوگیری از رمزهای رایج و ضعیف را نشان می‌دهد.

حملات Brute Force چگونه صفحه ورود سایت را هدف قرار می‌دهند؟

برای دفاع مناسب ابتدا باید بدانیم سطح حمله فقط محدود به فرم Login اصلی نیست.

هر مسیری که Credential یا Token دریافت می‌کند می‌تواند هدف حملات خودکار باشد.

فرم Login

واضح‌ترین نقطه، صفحه ورود اصلی وب‌سایت است.

API ورود

اگر اپلیکیشن موبایل یا SPA از API استفاده کند، ممکن است درخواست‌های ورود از Endpoint جداگانه‌ای عبور کنند.

اگر فقط فرم HTML محدود شده باشد اما API همان محدودیت را نداشته باشد، کنترل امنیتی ناقص است.

ورود مدیران

پنل مدیریت ارزش بیشتری برای مهاجم دارد و باید محدودیت‌های سخت‌گیرانه‌تری داشته باشد.

Password Reset

صفحه فراموشی رمز نیز می‌تواند هدف اتوماسیون قرار گیرد.

OWASP توصیه می‌کند Password Reset در برابر ارسال درخواست‌های بیش از حد Rate Limit داشته باشد و پیام‌ها برای حساب موجود و ناموجود یکسان باشند.

Verification Code

کدهای یک‌بارمصرف نیز اگر فضای حدس کوچک و محدودیت تلاش ضعیف داشته باشند ممکن است در معرض حملات Guessing قرار بگیرند.

پنل‌های قدیمی یا فراموش‌شده

یک سایت ممکن است علاوه بر پنل اصلی دارای Staging، پنل Legacy یا مسیر مدیریتی قدیمی باشد.

دفاع فقط از صفحه اصلی کافی نیست.

نشانه‌های حمله Brute Force به سایت

Brute Force همیشه به نفوذ موفق منجر نمی‌شود. در بسیاری از موارد ابتدا می‌توان رفتار حمله را در Logها مشاهده کرد.

افزایش ناگهانی Login Failure

تعداد غیرعادی ورود ناموفق یکی از واضح‌ترین نشانه‌هاست.

تلاش برای Usernameهای متعدد

اگر یک IP یا گروهی از منابع در مدت کوتاه حساب‌های مختلف را امتحان کنند، احتمال Password Spraying یا Credential Stuffing مطرح می‌شود.

تلاش مکرر روی یک حساب

تعداد بالای خطا برای یک Username مشخص می‌تواند نشانه Brute Force هدفمند باشد.

درخواست‌های ورود از موقعیت‌های غیرعادی

تلاش ورود از کشورها، ASNها یا شبکه‌هایی که معمولاً کاربران سایت از آن‌ها استفاده نمی‌کنند می‌تواند سیگنال ریسک باشد.

البته Geolocation به‌تنهایی نباید معیار قطعی مسدودسازی باشد.

User-Agentهای غیرمعمول

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

اما User-Agent قابل جعل است و نباید به‌تنهایی معیار دفاع باشد.

افزایش درخواست‌های بازیابی رمز

حمله ممکن است تنها Login را هدف قرار ندهد.

افزایش درخواست Forgot Password نیز باید مانیتور شود.

Brute Force چه خطراتی برای سایت دارد؟

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

تصاحب حساب کاربری

Account Takeover یا ATO یکی از جدی‌ترین نتایج حملات Authentication است.

پس از ورود، مهاجم ممکن است بتواند:

• اطلاعات حساب را مشاهده کند.
• ایمیل یا اطلاعات پروفایل را تغییر دهد.
• عملیات مجاز کاربر را انجام دهد.
• داده‌های خصوصی را استخراج کند.
• از اعتبار حساب برای حملات بعدی استفاده کند.

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

اگر هدف حساب Administrator باشد، شدت حادثه می‌تواند بسیار بیشتر شود.

بسته به سامانه، حساب مدیر ممکن است به:

• کاربران
• تنظیمات
• محتوا
• افزونه‌ها
• API Keyها
• گزارش‌ها
• یا قابلیت‌های مدیریتی حساس

دسترسی داشته باشد.

افشای اطلاعات کاربران

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

سوءاستفاده از اعتبار سایت

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

افزایش بار سرور

حتی در صورت ناموفق بودن حمله، حجم بالای درخواست‌های Authentication می‌تواند منابع CPU، Database یا سیستم Session را مصرف کند.

در برخی شرایط Brute Force شدید ممکن است به کاهش عملکرد سرویس منجر شود.

مهم‌ترین روش‌های جلوگیری از حملات Brute Force

هیچ راهکار واحدی تمام انواع Brute Force، Password Spraying و Credential Stuffing را متوقف نمی‌کند.

بهترین راهکار Defense in Depth است.

استفاده از Rate Limiting

Rate Limiting یکی از اساسی‌ترین کنترل‌ها علیه حملات حدس آنلاین است.

هدف این است که مهاجم نتواند بدون محدودیت درخواست Authentication ایجاد کند.

NIST Rate Limiting یا Throttling را یکی از کنترل‌های اصلی مقاومت در برابر Online Guessing می‌داند. همچنین تأکید می‌کند این محدودیت باید به شکلی طراحی شود که خود آن به ابزار Denial of Service علیه کاربران واقعی تبدیل نشود.

Rate Limit فقط براساس IP کافی نیست

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

در یک سیستم مدرن بهتر است چند معیار بررسی شوند:

• تعداد تلاش برای هر حساب
• تعداد تلاش از هر IP
• رفتار Subnet یا ASN
• تعداد حساب‌های هدف‌شده
• Device Signals
• سرعت درخواست‌ها
• سابقه قبلی Session

هدف ساختن یک سیستم تشخیص رفتار است، نه فقط یک شمارنده ساده.

Login Throttling چیست؟

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

برای مثال، پس از چند خطای متوالی سیستم می‌تواند اجازه تلاش بعدی را با تأخیر بیشتری صادر کند.

OWASP Login Throttling را یکی از کنترل‌های اصلی برای کاهش حملات خودکار معرفی می‌کند.

مزیت تأخیر تدریجی

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

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

Account Lockout؛ مفید اما حساس

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

اما Lockout سخت و دائمی مشکل دیگری ایجاد می‌کند:

مهاجم می‌تواند عمداً Username کاربران واقعی را هدف قرار دهد و حساب‌های آن‌ها را قفل کند.

در این صورت کنترل ضد Brute Force تبدیل به ابزار DoS می‌شود.

OWASP نیز درباره همین تعادل میان امنیت و Availability هشدار می‌دهد و پیشنهاد می‌کند Threshold، Observation Window و Lockout Duration با دقت طراحی شوند.

Exponential Backoff

یکی از گزینه‌ها افزایش تدریجی زمان انتظار است.

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

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

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

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

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

OWASP MFA را یکی از مؤثرترین روش‌ها برای مقابله با Brute Force، Credential Stuffing و Password Spraying معرفی می‌کند.

MFA برای کدام حساب‌ها ضروری‌تر است؟

حداقل برای موارد زیر باید اولویت بالایی داشته باشد:

• مدیران سایت
• توسعه‌دهندگان
• پشتیبان‌ها
• کاربران مالی
• افرادی که اطلاعات حساس مشاهده می‌کنند
• حساب‌هایی که امکان تغییر تنظیمات امنیتی دارند

MFA تطبیقی

لازم نیست همیشه تجربه کاربر را پیچیده کرد.

می‌توان Step-Up Authentication را در شرایط پرریسک فعال کرد؛ برای مثال:

• دستگاه جدید
• موقعیت غیرعادی
• تغییر حساس حساب
• IP مشکوک
• رفتار مشابه ربات
• عملیات مالی مهم

OWASP این رویکرد Risk-Based را نیز در راهنمای Credential Stuffing مطرح می‌کند.

استفاده از Passkey

Passkey و فناوری‌های مبتنی بر FIDO2 می‌توانند وابستگی سیستم به رمزهای قابل حدس و قابل تکرار را کاهش دهند.

در سیستم‌هایی که معماری آن اجازه می‌دهد، حرکت به سمت Passwordless Authentication می‌تواند سطح حمله سنتی Brute Force را کاهش دهد.

البته فرآیند Recovery همچنان باید امن طراحی شود؛ زیرا مهاجم ممکن است به‌جای Login، ضعیف‌ترین مسیر بازیابی حساب را هدف قرار دهد.

سیاست رمز عبور مناسب

یک اشتباه رایج این است که سیاست رمز عبور را با قوانین پیچیده و آزاردهنده یکی بدانیم.

الزام‌هایی مانند:

«حتماً یک حرف بزرگ، یک حرف کوچک، یک عدد و یک نماد استفاده کنید و هر ۳۰ روز رمز را عوض کنید»

لزوماً امنیت واقعی بیشتری ایجاد نمی‌کنند.

OWASP در نسخه جدید Authentication Failures توصیه می‌کند سیاست‌های رمز با راهنماهای مدرن NIST هماهنگ باشند و تغییر اجباری دوره‌ای رمز بدون نشانه‌ای از Compromise اعمال نشود.

رمز قوی چه ویژگی‌هایی دارد؟

در عمل بهتر است:

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

رمزهای افشاشده را Block کنید

سیستم ثبت‌نام و تغییر رمز باید رمزهای شناخته‌شده و افشاشده را رد کند.

این کار احتمال موفقیت Dictionary Attack و Credential Stuffing ترکیبی را کاهش می‌دهد.

CAPTCHA؛ مفید اما نه کافی

CAPTCHA می‌تواند اجرای حملات خودکار را دشوارتر و گران‌تر کند.

اما نباید تنها دفاع سایت باشد.

OWASP تأکید می‌کند CAPTCHA قابل دور زدن یا برون‌سپاری است و باید یک لایه Defense in Depth محسوب شود، نه راهکار کامل جلوگیری از Brute Force.

CAPTCHA تطبیقی بهتر است

نمایش CAPTCHA در اولین ورود برای همه کاربران می‌تواند تجربه کاربری را ضعیف کند.

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

برای مثال:

• چند Login Failure
• IP پرریسک
• رفتار خودکار
• حجم درخواست غیرعادی

در این صورت کاربر معمولی کمتر درگیر کنترل‌های اضافی می‌شود.

جلوگیری از Account Enumeration

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

اگر سایت برای Username معتبر بگوید:

«رمز اشتباه است»

اما برای Username نامعتبر بگوید:

«چنین کاربری وجود ندارد»

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

پیام مناسب چیست؟

پیام عمومی مانند:

«نام کاربری یا رمز عبور صحیح نیست»

اطلاعات کمتری افشا می‌کند.

OWASP توصیه می‌کند صفحات Login، Registration و Account Recovery نتیجه‌هایی ارائه نکنند که مهاجم بتواند از آن‌ها برای Enumeration حساب‌ها استفاده کند.

فقط متن پیام مهم نیست

زمان پاسخ و Status Code نیز ممکن است اطلاعات ایجاد کنند.

اگر پاسخ حساب موجود و ناموجود رفتار کاملاً متفاوتی داشته باشد، مهاجم ممکن است از اختلاف جانبی برای تشخیص حساب استفاده کند.

استفاده از WAF در برابر Brute Force

Web Application Firewall می‌تواند یکی از لایه‌های مفید دفاع باشد.

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

• Rate Limiting
• Bot Detection
• IP Reputation
• Challenge
• Geo Rules
• Behavioral Analysis

داشته باشند.

اما WAF نیز جایگزین امنیت خود سیستم Authentication نیست.

اگر Backend هیچ محدودیتی نداشته باشد و تمام دفاع فقط در لایه بیرونی قرار گیرد، تغییر معماری یا مسیر دیگری از API می‌تواند مشکل ایجاد کند.

اصل مهم این است:

Authentication باید خودش مقاوم باشد و WAF دفاع اضافی ایجاد کند.

Bot Management چیست؟

حملات Brute Force امروزی تا حد زیادی خودکار هستند.

بنابراین شناسایی Bot می‌تواند بخش مهمی از دفاع باشد.

سامانه می‌تواند نشانه‌هایی مانند:

• حجم درخواست
• الگوی زمانی
• Reputation
• رفتار Session
• Device Signals
• تغییر سریع حساب‌های هدف

را تحلیل کند.

نباید تنها به یک سیگنال وابسته بود؛ زیرا بسیاری از آن‌ها قابل جعل یا تغییر هستند.

مانیتورینگ Login Attemptها

دفاع بدون Visibility ناقص است.

سایت باید رویدادهای Authentication را به شکلی ثبت کند که رفتار غیرعادی قابل بررسی باشد.

چه اطلاعاتی مفید هستند؟

بسته به سیاست حریم خصوصی و معماری سیستم:

• زمان Login Attempt
• نتیجه
• Account Identifier مناسب
• IP
• Device/Client Signal
• علت Challenge
• Rate Limit Event
• تغییرات MFA
• Password Reset Event

چه چیزهایی نباید Log شوند؟

هرگز نباید رمز عبور، OTP خام یا Secretهای احراز هویت را در Log ذخیره کرد.

Log امنیتی نباید خودش به منبع نشت Credential تبدیل شود.

Alert برای رفتارهای مشکوک

ثبت Log بدون Alerting ممکن است باعث شود حمله تا زمان بررسی دستی متوجه نشود.

Alert می‌تواند برای مواردی مانند:

• افزایش شدید Login Failure
• ورود از کشور غیرمنتظره
• تلاش روی تعداد زیادی حساب
• افزایش Password Reset
• چندین Account Lockout
• تغییر ناگهانی MFA
• ورود موفق پس از تعداد زیادی Failure

تعریف شود.

OWASP نیز توصیه می‌کند تلاش‌های ناموفق ورود ثبت شوند و هنگام مشاهده Brute Force یا Credential Stuffing، سیستم هشدار ایجاد کند.

اطلاع‌رسانی رویداد امنیتی به کاربر

در برخی شرایط بهتر است کاربر نیز از فعالیت مشکوک مطلع شود.

برای مثال:

• ورود از دستگاه جدید
• تغییر رمز
• غیرفعال شدن MFA
• تغییر ایمیل
• Recovery حساس

این پیام‌ها امکان واکنش سریع‌تر را فراهم می‌کنند.

بااین‌حال اعلان نباید اطلاعاتی افشا کند که به مهاجم کمک کند.

محافظت از فرایند Forgot Password

گاهی صفحه Login به‌خوبی محافظت شده اما Password Reset ضعیف است.

این مسئله مانند داشتن در ورودی مقاوم و پنجره باز است.

Reset Token باید چگونه باشد؟

Token باید:

• غیرقابل پیش‌بینی باشد.
• عمر محدود داشته باشد.
• پس از استفاده باطل شود.
• امن ذخیره شود.
• فقط برای حساب و عملیات مشخص معتبر باشد.

درخواست Reset را Rate Limit کنید

مهاجم نباید بتواند هزاران ایمیل یا پیامک Reset برای کاربر ارسال کند.

OWASP صراحتاً Rate Limiting و کنترل اتوماسیون را برای Forgot Password توصیه می‌کند.

جلوگیری از Brute Force در سایت وردپرسی

سایت‌های وردپرسی به دلیل گستردگی استفاده، معمولاً هدف حجم زیادی از Login Botها قرار می‌گیرند.

این موضوع الزاماً به معنی ناامن بودن وردپرس نیست؛ بلکه محبوبیت بالا باعث جذابیت بیشتر آن برای حملات خودکار می‌شود.

محافظت از حساب Administrator

مدیر سایت باید MFA فعال داشته باشد.

همچنین تعداد حساب‌های Administrator باید به حداقل لازم محدود شود.

اصل Least Privilege اهمیت زیادی دارد.

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

حذف حساب‌های بلااستفاده

حساب قدیمی همچنان یک Credential قابل هدف است.

حساب‌های کارکنانی که دیگر دسترسی نیاز ندارند باید حذف یا Disable شوند.

جلوگیری از رمزهای ضعیف

رمزهای مدیران و کاربران حساس باید منحصر‌به‌فرد و قوی باشند.

استفاده از Password Manager برای تولید رمزهای تصادفی انتخاب مناسبی است.

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

وردپرس یا لایه امنیتی اطراف آن باید Login Throttling و Rate Limiting مناسب داشته باشد.

هدف مسدود کردن یک IP برای همیشه نیست؛ بلکه کنترل رفتار خودکار است.

فعال‌سازی MFA برای مدیران وردپرس

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

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

محافظت از XML-RPC در صورت عدم نیاز

برخی سایت‌های وردپرسی ممکن است قابلیت‌هایی داشته باشند که مسیرهای Authentication دیگری ایجاد می‌کنند.

اگر یک قابلیت مانند XML-RPC برای سایت مورد استفاده نیست، کاهش سطح حمله از طریق محدودسازی یا غیرفعال‌سازی منطقی می‌تواند مفید باشد.

اما تصمیم باید براساس نیازهای واقعی سایت گرفته شود، زیرا برخی Integrationها ممکن است به آن وابسته باشند.

به‌روزرسانی وردپرس، قالب و افزونه‌ها

Brute Force مستقیماً یک آسیب‌پذیری افزونه نیست، اما اگر مهاجم موفق به ورود شود یا ضعف دیگری وجود داشته باشد، نسخه‌های قدیمی می‌توانند زنجیره حمله را تشدید کنند.

بنابراین Patch Management همچنان بخشی از دفاع کلی است.

استفاده از WAF و CDN

برای سایت‌هایی که حجم Bot بالایی دریافت می‌کنند، WAF یا سرویس Edge می‌تواند بخش بزرگی از ترافیک خودکار را قبل از رسیدن به سرور مدیریت کند.

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

آیا تغییر آدرس wp-login امنیت ایجاد می‌کند؟

تغییر URL صفحه ورود می‌تواند حجم Botهای ساده و اسکن‌های خودکار را کاهش دهد، اما نباید آن را کنترل اصلی امنیتی دانست.

URL مخفی Secret واقعی نیست.

اگر مهاجم مسیر جدید را پیدا کند و هیچ Rate Limiting یا MFA وجود نداشته باشد، مشکل اصلی همچنان باقی است.

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

آیا تغییر نام کاربری admin کافی است؟

استفاده نکردن از Username قابل حدس می‌تواند مقدار کمی Enumeration را دشوار کند، اما امنیت حساب نباید به مخفی بودن Username وابسته باشد.

Username معمولاً Secret محسوب نمی‌شود.

کنترل‌های اصلی عبارت‌اند از:

• رمز منحصر‌به‌فرد
• MFA
• Rate Limiting
• Lockout مناسب
• Monitoring

آیا محدود کردن IP برای پنل مدیریت مناسب است؟

برای سایت‌های سازمانی که مدیران از شبکه‌های مشخص وارد می‌شوند، Allowlist کردن IP می‌تواند لایه امنیتی قدرتمندی باشد.

اما برای سایتی که مدیران دائماً از اینترنت‌های متغیر استفاده می‌کنند ممکن است عملی نباشد.

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

Brute Force در APIها

امنیت Login API باید دقیقاً به اندازه فرم وب جدی گرفته شود.

گاهی توسعه‌دهنده روی صفحه Login CAPTCHA قرار می‌دهد اما Endpoint API محدودیتی ندارد.

این طراحی به مهاجم اجازه می‌دهد رابط گرافیکی را دور بزند و مستقیماً API را هدف قرار دهد.

کنترل‌های مهم API Authentication

• Rate Limit
• MFA
• Generic Errors
• Monitoring
• Session Security
• Token Security
• Bot Detection
• Account-Level Throttling

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

جلوگیری از Brute Force کدهای OTP

OTP به معنی مصونیت از Guessing نیست.

اگر یک کد فضای محدودی داشته باشد و تلاش نامحدود مجاز باشد، مهاجم می‌تواند احتمال‌های مختلف را امتحان کند.

بنابراین OTP باید:

• عمر کوتاه داشته باشد.
• تعداد تلاش محدود داشته باشد.
• پس از استفاده باطل شود.
• به Session و Purpose مناسب متصل باشد.
• Rate Limit داشته باشد.

ارسال مجدد OTP نیز باید کنترل شود تا مهاجم نتواند سامانه SMS یا Email را مورد سوءاستفاده قرار دهد.

تفاوت Rate Limiting و Account Lockout

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

بهترین معماری معمولاً ترکیبی از چند مورد است.

اشتباهات رایج در مقابله با Brute Force

مسدود کردن دائمی حساب بعد از چند خطا

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

محدودسازی فقط براساس IP

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

استفاده از CAPTCHA به‌عنوان تنها دفاع

CAPTCHA یک مانع است، نه تضمین امنیت.

نادیده گرفتن API

محافظت صفحه Login بدون محافظت Endpoint پشت آن ناقص است.

نداشتن MFA برای مدیران

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

نمایش پیام‌های متفاوت برای حساب معتبر

این رفتار Account Enumeration را ساده‌تر می‌کند.

اجبار به تغییر مداوم رمز بدون دلیل

کاربران ممکن است تغییرات قابل پیش‌بینی روی رمز قبلی ایجاد کنند.

بهتر است Rotation اجباری بدون نشانه Compromise با سیاست‌های مدرن جایگزین شود.

ذخیره ناامن رمز عبور

دفاع از Login فقط جلوگیری از حدس آنلاین نیست.

اگر Database افشا شود، نحوه ذخیره Password تعیین می‌کند مهاجم تا چه اندازه می‌تواند Credentialها را بازیابی کند.

Passwordها نباید به شکل Plain Text یا رمزنگاری قابل بازگشت ذخیره شوند.

باید از Password Hashing مناسب و الگوریتم‌های معتبر متناسب با استانداردهای روز استفاده شود.

چگونه متوجه شویم حمله Brute Force موفق شده است؟

Login Failure زیاد فقط نشان‌دهنده تلاش است.

برای تشخیص Account Compromise باید رویدادهای بعدی نیز تحلیل شوند.

نشانه‌های احتمالی:

• ورود موفق پس از تعداد زیادی Failure
• ورود از Device جدید
• تغییر Password بلافاصله پس از Login
• تغییر Email
• حذف یا تغییر MFA
• ایجاد Sessionهای متعدد
• عملیات غیرمعمول حساب
• دسترسی به حجم غیرعادی اطلاعات

ترکیب Eventها معمولاً تصویر دقیق‌تری نسبت به بررسی یک Log منفرد ایجاد می‌کند.

اگر حمله Brute Force موفق شد چه کار کنیم؟

در صورت مشاهده شواهد واقعی از Account Takeover، فقط Block کردن IP کافی نیست.

Sessionهای مشکوک را باطل کنید

Session و Tokenهای فعال حساب باید براساس سیاست Incident Response بررسی شوند.

Credential حساب را Reset کنید

اگر احتمال افشای Password وجود دارد، تغییر رمز ضروری است.

MFA را بررسی کنید

اگر MFA تغییر کرده یا حذف شده است باید وضعیت آن بازبینی شود.

فعالیت حساب را تحلیل کنید

مشخص کنید مهاجم پس از ورود چه اقداماتی انجام داده است.

Logها را حفظ کنید

اطلاعات لازم برای تحلیل Incident نباید با اقدامات عجولانه حذف شوند.

Scope حادثه را بررسی کنید

ممکن است یک حساب تنها قربانی نباشد.

کاربران در معرض خطر را مطلع کنید

در صورت لزوم و براساس الزامات قانونی و سیاست سازمان، اطلاع‌رسانی مناسب انجام شود.

Root Cause را اصلاح کنید

اگر علت موفقیت رمز ضعیف، نبود MFA یا Rate Limiting ناکافی بوده، مشکل معماری باید اصلاح شود؛ نه اینکه فقط حساب قربانی Reset شود.

طراحی یک سیستم Login مقاوم در برابر Brute Force

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

لایه اول: رمز عبور مناسب

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

لایه دوم: Rate Limiting

هم Account و هم Source رفتار محدود شوند.

لایه سوم: Risk Detection

رفتار غیرعادی تشخیص داده شود.

لایه چهارم: CAPTCHA یا Challenge

برای ترافیک مشکوک اصطکاک اضافی ایجاد شود.

لایه پنجم: MFA

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

لایه ششم: Monitoring

رویدادها ثبت و تحلیل شوند.

لایه هفتم: Notification

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

لایه هشتم: Incident Response

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

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

امنیت صفحه ورود بدون آسیب زدن به تجربه کاربری

یکی از چالش‌های مهم این است که امنیت بیش از حد سخت‌گیرانه می‌تواند کاربران واقعی را آزار دهد.

قرار دادن CAPTCHA روی هر درخواست، قفل یک‌ساعته پس از دو اشتباه یا اجبار مداوم به MFA ممکن است نرخ خروج کاربران را افزایش دهد.

راهکار بهتر Adaptive Security است.

سیستم می‌تواند ورودهای عادی را ساده نگه دارد و فقط زمانی اصطکاک اضافه کند که Risk Score افزایش می‌یابد.

برای مثال:

کاربر شناخته‌شده + دستگاه آشنا + IP معمول → ورود عادی

دستگاه جدید + Location غیرعادی → MFA

چند Failure + رفتار Bot → CAPTCHA و Throttling

صدها Account Target از یک شبکه → Rate Limit شدید

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

آیا Brute Force فقط سایت‌های بزرگ را هدف قرار می‌دهد؟

خیر.

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

یک سایت کوچک ممکن است هدف مشخص مهاجم نباشد اما در دام اسکن و حملات گسترده قرار گیرد.

در سایت‌های وردپرسی این موضوع بیشتر دیده می‌شود؛ زیرا ساختار بعضی مسیرها قابل پیش‌بینی است و ابزارهای اتوماتیک می‌توانند تعداد زیادی دامنه را بررسی کنند.

بنابراین جمله «سایت ما کوچک است و کسی سراغش نمی‌آید» استراتژی امنیتی قابل اعتمادی نیست.

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

خیر.

HTTPS ارتباط میان مرورگر و سرور را رمزنگاری می‌کند.

این ویژگی بسیار مهم است، اما مانع ارسال هزاران Login Attempt نمی‌شود.

برای جلوگیری از Brute Force باید کنترل Authentication وجود داشته باشد.

آیا تغییر پورت جلوی حمله را می‌گیرد؟

برای Login وب، تغییر پورت یا پنهان کردن Endpoint ممکن است نویز حملات ساده را کاهش دهد، اما کنترل امنیتی اصلی محسوب نمی‌شود.

امنیت نباید بر مخفی ماندن مسیر بنا شود.

آیا استفاده از Cloud WAF کافی است؟

خیر.

Cloud WAF می‌تواند لایه بسیار مفیدی باشد، ولی Backend باید مستقل از آن نیز امنیت پایه‌ای داشته باشد.

فرض کنید مسیر داخلی، API جدید یا Configuration اشتباه باعث شود درخواست‌ها WAF را دور بزنند.

اگر Authentication Backend هیچ Rate Limit نداشته باشد، خطر برمی‌گردد.

آیا Password Manager واقعاً کمک می‌کند؟

بله.

یکی از مهم‌ترین فواید Password Manager ایجاد رمزهای:

• طولانی
• تصادفی
• منحصر‌به‌فرد

برای هر سرویس است.

رمز منحصر‌به‌فرد باعث می‌شود افشای Credential در یک سایت به‌سادگی به Credential Stuffing روی سایت دیگر تبدیل نشود.

OWASP نیز استفاده از Password Manager را در راهنمای Authentication جدید توصیه می‌کند.

چک‌لیست جلوگیری از حملات Brute Force

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

• Rate Limiting برای Login فعال باشد.
• محدودیت تنها براساس IP نباشد.
• Account-Level Throttling وجود داشته باشد.
• Lockout باعث DoS ساده نشود.
• MFA برای حساب‌های حساس فعال باشد.
• رمزهای افشاشده مسدود شوند.
• Password Manager پشتیبانی شود.
• خطاهای Login حساب معتبر را افشا نکنند.
• Password Reset Rate Limit داشته باشد.
• OTP محدودیت تلاش داشته باشد.
• API Login نیز محافظت شود.
• CAPTCHA به‌صورت Adaptive استفاده شود.
• WAF یا Bot Management در صورت نیاز فعال باشد.
• Login Failureها Log شوند.
• رفتار مشکوک Alert ایجاد کند.
• ورودهای غیرعادی برای کاربران حساس بررسی شوند.
• حساب‌های بلااستفاده حذف شوند.
• دسترسی Administrator محدود باشد.
• Session پس از Login امن مدیریت شود.
• Passwordها با الگوریتم مناسب Hash شوند.
• سیاست Incident Response برای Account Takeover وجود داشته باشد.

تست امنیت سایت در برابر Brute Force

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

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

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

• آیا تعداد Login Failure محدود می‌شود؟
• محدودیت Account-Based است یا فقط IP-Based؟
• Account Lockout قابل سوءاستفاده برای DoS است؟
• Password Reset محافظت دارد؟
• MFA برای عملیات حساس وجود دارد؟
• پیام خطا Enumeration ایجاد می‌کند؟
• Login API همان کنترل‌های فرم وب را دارد؟
• رویدادهای مشکوک ثبت می‌شوند؟
• سیستم پس از رفتار غیرعادی Challenge ایجاد می‌کند؟

OWASP Web Security Testing Guide نیز ارزیابی Lockout Mechanism و مقاومت آن در برابر Credential Stuffing و Distributed Brute Force را بخشی از تست Authentication می‌داند.

سوالات متداول درباره حملات Brute Force

حمله Brute Force چیست؟

Brute Force نوعی حمله علیه سیستم احراز هویت است که در آن مهاجم تعداد زیادی احتمال برای پیدا کردن Credential صحیح آزمایش می‌کند. روش‌های مرتبط شامل Dictionary Attack، Password Spraying و Credential Stuffing هستند.

آیا Brute Force می‌تواند سایت را هک کند؟

اگر یکی از Credentialهای امتحان‌شده صحیح باشد و کنترل دیگری مانند MFA وجود نداشته باشد، مهاجم ممکن است وارد حساب شود. میزان آسیب پس از آن به سطح دسترسی حساب بستگی دارد.

بهترین روش جلوگیری از Brute Force چیست؟

هیچ کنترل واحدی کافی نیست. ترکیب MFA، Rate Limiting، Login Throttling، رمزهای منحصر‌به‌فرد، Blocklist رمزهای افشاشده، Bot Detection و Monitoring دفاع بسیار مؤثرتری ایجاد می‌کند.

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

CAPTCHA می‌تواند اتوماسیون را دشوارتر کند اما به‌تنهایی کافی نیست. بهتر است به‌عنوان یکی از لایه‌های Defense in Depth و ترجیحاً به شکل Adaptive استفاده شود.

آیا قفل کردن حساب بعد از چند تلاش اشتباه مناسب است؟

قفل موقت می‌تواند مفید باشد، اما اگر بسیار سخت‌گیرانه طراحی شود مهاجم می‌تواند عمداً حساب کاربران را قفل کند. Throttling و Lockout باید با در نظر گرفتن خطر Denial of Service طراحی شوند.

Credential Stuffing با Brute Force چه تفاوتی دارد؟

در Brute Force مهاجم معمولاً Password صحیح را حدس می‌زند. در Credential Stuffing از Credentialهایی استفاده می‌شود که قبلاً از سرویس دیگری افشا شده‌اند.

Password Spraying چیست؟

در Password Spraying یک یا چند رمز رایج روی تعداد زیادی حساب امتحان می‌شود. این روش می‌تواند از Lockoutهایی که فقط تعداد تلاش هر حساب را بررسی می‌کنند عبور کند.

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

MFA جلوی ارسال Login Attempt را نمی‌گیرد، اما می‌تواند از تبدیل Password افشاشده یا حدس‌زده‌شده به Account Takeover جلوگیری کند. به همین دلیل یکی از مهم‌ترین دفاع‌های Authentication محسوب می‌شود.

آیا وردپرس در معرض Brute Force قرار دارد؟

هر سایتی که Login مبتنی بر Password دارد ممکن است هدف حملات خودکار قرار گیرد. محبوبیت وردپرس باعث شده Botها صفحات ورود سایت‌های وردپرسی را به‌طور گسترده بررسی کنند. Rate Limiting، MFA و مانیتورینگ برای این سایت‌ها اهمیت زیادی دارند.

آیا تغییر آدرس Login وردپرس کافی است؟

خیر. این اقدام ممکن است بخشی از اسکن‌های ساده را کاهش دهد اما جایگزین MFA، Rate Limiting یا رمز قوی نیست.

آیا WAF می‌تواند Brute Force را متوقف کند؟

WAF می‌تواند حجم زیادی از ترافیک خودکار را محدود کند، اما سیستم Authentication نیز باید کنترل داخلی مناسبی داشته باشد. دفاع صرفاً در یک لایه توصیه نمی‌شود.

چند بار تلاش ناموفق باید مجاز باشد؟

عدد ثابت مناسبی برای تمام سامانه‌ها وجود ندارد. آستانه باید براساس حساسیت سرویس، رفتار کاربران، MFA، Risk Model و احتمال سوءاستفاده از Lockout برای DoS تعیین شود. استانداردهای امنیتی بر Rate Limiting تأکید دارند، اما طراحی نهایی باید متناسب با برنامه باشد.

آیا رمز طولانی Brute Force را غیرممکن می‌کند؟

رمز طولانی و تصادفی فضای حدس را بسیار افزایش می‌دهد، اما اگر همان رمز در سرویس دیگری افشا شده و دوباره استفاده شود، Credential Stuffing همچنان ممکن است موفق شود. بنابراین Unique بودن رمز به اندازه قدرت آن اهمیت دارد.

جمع‌بندی

حملات Brute Force یکی از قدیمی‌ترین روش‌های حمله به سیستم‌های احراز هویت هستند، اما شکل مدرن آن‌ها بسیار فراتر از امتحان کردن تصادفی میلیون‌ها رمز عبور است. مهاجمان امروزی می‌توانند از Password Spraying، Credential Stuffing، رمزهای افشاشده، Botnetها و IPهای توزیع‌شده برای عبور از کنترل‌های ساده استفاده کنند.

به همین دلیل دفاع مؤثر نباید به یک تکنیک مانند Block کردن IP یا اضافه کردن CAPTCHA محدود شود.

یک سیستم Login امن باید چند لایه داشته باشد.

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

لایه بعدی Rate Limiting و Login Throttling است. سایت باید تعداد تلاش‌های ورود را براساس حساب و رفتار منبع کنترل کند. محدودسازی صرفاً براساس IP برای مقابله با حملات توزیع‌شده کافی نیست.

Account Lockout نیز باید با احتیاط طراحی شود؛ زیرا مهاجم نباید بتواند با چند درخواست عمدی حساب کاربران واقعی را برای مدت طولانی از دسترس خارج کند.

احراز هویت چندمرحله‌ای نقش بسیار مهمی دارد. حتی اگر مهاجم Password را از طریق Brute Force، Phishing یا Data Breach به دست آورد، وجود عامل مستقل دوم می‌تواند مانع تصاحب حساب شود. برای حساب‌های مدیریتی، مالی و سایر کاربران دارای دسترسی حساس، MFA باید در اولویت بسیار بالایی قرار گیرد.

CAPTCHA، WAF و Bot Management نیز ابزارهای ارزشمندی هستند اما نقش مکمل دارند. این کنترل‌ها باید در کنار امنیت داخلی Backend استفاده شوند.

موضوع مهم دیگر Visibility است. اگر هزاران Login Failure رخ دهد اما هیچ Log، Alert یا مانیتورینگی وجود نداشته باشد، تیم سایت ممکن است حمله را تا زمان تصاحب حساب متوجه نشود.

همچنین نباید تنها صفحه اصلی Login را محافظت کرد. APIهای ورود، Password Reset، OTP، پنل مدیریت و مسیرهای Authentication قدیمی نیز بخشی از سطح حمله هستند.

برای سایت‌های وردپرسی، محدود کردن حساب‌های Administrator، استفاده از MFA، جلوگیری از Passwordهای ضعیف، کنترل تلاش‌های ورود، حذف حساب‌های بلااستفاده، به‌روزرسانی افزونه‌ها و استفاده از WAF یا Bot Protection در صورت نیاز می‌تواند سطح امنیت را به شکل قابل توجهی افزایش دهد.

در نهایت، هدف جلوگیری از Brute Force این نیست که یک مهاجم هرگز نتواند درخواست Login ارسال کند. هدف این است که تعداد حدس‌های قابل انجام به‌شدت محدود شود، رفتارهای خودکار زود تشخیص داده شوند و حتی در صورت افشای Password، کنترل‌های دیگری مانند MFA مانع تصاحب حساب شوند.

امنیت صفحه ورود زمانی مؤثر است که Password، Rate Limiting، MFA، Bot Protection، Logging، Monitoring و Incident Response به‌عنوان اجزای یک سیستم واحد طراحی شوند. این رویکرد چندلایه علاوه بر مقابله با Brute Force کلاسیک، مقاومت سایت را در برابر Credential Stuffing، Password Spraying و بسیاری از حملات خودکار احراز هویت نیز افزایش می‌دهد.