اگر فقط IP را بعد از پنج خطا مسدود کنید، مهاجم توزیعشده دورش میزند؛ اگر حساب را سخت قفل کنید، مهاجم همان کنترل را به ابزار DoS علیه کاربران تبدیل میکند. دفاع Login باید همزمان سرعت حمله، استفاده از رمز افشاشده، تصاحب حساب و مصرف منابع را کنترل کند، بدون اینکه کاربر واقعی پشت اینترنت مشترک ایران قربانی شود.
این راهنما Brute Force، Password Spraying و Credential Stuffing را تفکیک و یک معماری دفاع چندلایه برای WordPress، API و فروشگاه ارائه میکند.
Brute Force چیست؟
در Brute Force مهاجم Password یک حساب را با حدسهای بسیار امتحان میکند. Dictionary attack از واژهها و الگوهای رایج استفاده میکند؛ Exhaustive search فضای بزرگتری را میگردد. Online brute force با Rate limit محدود میشود، اما Offline cracking پس از سرقت Hash به کیفیت الگوریتم ذخیرهسازی وابسته است.
Credential Stuffing چیست؟
Credential Stuffing حدس Password نیست؛ Username/Passwordهایی که از سرویس دیگری سرقت شدهاند بهصورت خودکار روی Login شما آزمایش میشوند، با امید استفاده مجدد کاربر. تعریف OAT-۰۰۸ در OWASP دقیقاً بر آزمودن انبوه Credentialهای سرقتشده تأکید دارد.
Password Spraying و Credential Cracking
- Password spraying: یک یا چند Password رایج روی حسابهای بسیار، برای فرار از Lockout هر حساب؛
- Credential cracking: حدس یا استخراج Password، نه Replay Credential آماده؛
- Stuffing: زوج Username/Password معتبرِ سرویس دیگر؛
- Account takeover: نتیجه موفق حمله که ممکن است با Session theft یا Recovery abuse هم رخ دهد.
مقایسه تهدیدها
| تهدید | الگو | کنترلهای مؤثر |
|---|---|---|
| Brute force | حدسهای زیاد برای یک/چند حساب | Rate limit، Password قوی، MFA، Hash امن |
| Password spraying | حدس کم روی حسابهای زیاد | Global detection، Blocklist، MFA |
| Credential stuffing | Credential واقعی از نشت دیگر | MFA، breached-password check، Bot/Risk control |
| Enumeration | کشف Username/Email معتبر | Response یکنواخت، Timing و Recovery امن |
| Session theft | سرقت Cookie/Token پس از Login | Session security، XSS defense، Reauth |
Attack surface ورود را کامل ببینید
محافظت فقط از فرم ظاهری کافی نیست:
- wp-login.php و Login سفارشی؛
- WooCommerce/My Account؛
- XML-RPC methods و Application Password؛
- REST/API login و Mobile app؛
- SSO/OAuth callback؛
- Password reset و Magic link؛
- MFA challenge و Backup code؛
- Support-assisted recovery؛
- Admin AJAX/legacy endpoint؛
- Hosting، ایمیل، CDN و Registrar.
مهاجم مسیر کممحافظت را انتخاب میکند. Policy باید در لایه مرکزی Identity اجرا شود.
هدف دفاع را تعریف کنید
- کاهش نرخ Guess و Validation Credential؛
- جلوگیری از Login حتی با Password سرقتشده؛
- حفظ Availability برای کاربر واقعی؛
- کشف Account takeover سریع؛
- پاسخ و Recovery امن؛
- حفظ حریم خصوصی در Device/Risk signals؛
- اندازهگیری False positive و Support impact.
لایه اول: Password policy مدرن
اجبار ترکیب حرف بزرگ/کوچک/عدد/نماد اغلب Password قابلپیشبینی میسازد. NIST SP ۸۰۰-63B جاری برای Password تکعاملی حداقل ۱۵ نویسه، پذیرش طول بیشتر، مقایسه با Blocklist رمزهای رایج/افشاشده و Rate limiting را مقرر میکند و Composition ruleهای اضافی را توصیه نمیکند.
- Passphrase بلند و Password manager را پشتیبانی کنید؛
- Paste و Auto-fill را مسدود نکنید؛
- Unicode را با Normalization سازگار مدیریت کنید؛
- Password hint و سؤال امنیتی حذف؛
- تغییر دورهای اجباری بدون نشانه Compromise نگذارید؛
- Password جدید را با Username، نام سرویس و Blocklist بسنجید؛
- پس از Compromise، Reset و Session revoke انجام دهید.
بررسی Password افشاشده
در ثبتنام، تغییر Password و Incident، Password را با corpus امن رمزهای افشاشده مقایسه کنید. کنترل باید:
- Password خام را برای سرویس ثالث ارسال نکند؛
- از روش محلی یا Prefix/k-anonymity معتبر استفاده کند؛
- دلیل رد را ساده بگوید؛
- کاربر را به تغییر جزئی همان Password هل ندهد؛
- Result را Log نکند که Password قابل استنتاج شود؛
- Blocklist را بهروز و Fail mode را تعریف کند.
ذخیرهسازی Password
دفاع Online بدون Hash امن کافی نیست. Password باید با الگوریتم کند و Memory-hard مناسب (مانند Argon2id در Stack پشتیبان)، Salt یکتا و Cost قابلارتقا ذخیره شود. Encryption قابلبازگشت یا Hash سریع عمومی مناسب Password نیست.
- پارامتر Cost و نسخه کنار Hash؛
- Rehash پس از Login هنگام ارتقا؛
- Pepper در Secret manager در صورت استفاده؛
- عدم Log یا Analytics Password؛
- محدودکردن دسترسی Database/Backup؛
- برنامه Rotate/Reset در نشت.
در WordPress Core از API رسمی Password استفاده کنید و الگوریتم سفارشی نسازید.
لایه دوم: MFA مقاوم به فیشینگ
MFA بهترین مانع پس از افشای Password است، ولی همه روشها برابر نیستند. Passkey/WebAuthn و FIDO2 در برابر فیشینگ مقاومترند؛ TOTP و SMS قابل Relay هستند.
برای انتخاب عامل، Recovery، Backup code و Rollout، راهنمای MFA پنل مدیریت را اجرا کنید. حسابهای ادمین، ایمیل، DNS، Hosting و CI/CD را در اولویت بگذارید.
لایه سوم: Rate limiting چندبعدی
IP-only کافی نیست و Account-only قابل سوءاستفاده برای Lockout است. Signalها را ترکیب کنید:
- Account/username hash؛
- IP و Subnet/ASN با احتیاط؛
- Device/connection signal حداقلی؛
- Endpoint و Tenant؛
- Global failure rate؛
- Success/failure ratio؛
- Password fingerprint امن برای Spraying detection در صورت طراحی تخصصی؛
- زمان و Velocity.
Threshold را از Baseline و ظرفیت بسازید؛ عدد ثابت مقالهای را Copy نکنید.
Token bucket، Sliding window و Backoff
| روش | مزیت | احتیاط |
|---|---|---|
| Token bucket | Burst کوچک قانونی و نرخ پایدار | ظرفیت/Refill باید Tune شود |
| Sliding window | دید دقیقتر در بازه | هزینه State بالاتر |
| Progressive delay | کندکردن Attack بدون Lock دائم | Delay باید سمت سرور و غیرقابل دورزدن باشد |
| Risk challenge | اصطکاک فقط در خطر | Model و False positive نیازمند Monitor |
Rate limit در Edge منابع را حفظ میکند و در Application Account/context را میبیند؛ هر دو لایه مکملاند.
چرا Lockout سخت خطرناک است؟
اگر هر کس بتواند با چند Password غلط حساب مدیر را یک ساعت قفل کند، Login به ابزار Denial of Service تبدیل میشود. جایگزین:
- Backoff تدریجی؛
- Challenge اضافی بر اساس Risk؛
- محدودیت ترکیبی Account/IP/Global؛
- اعلان به کاربر؛
- Self-service recovery امن؛
- Break-glass برای ادمین با Audit؛
- عدم نمایش شمارش دقیق به مهاجم.
Response یکنواخت و جلوگیری از Enumeration
- «اطلاعات ورود نامعتبر است» برای Username/Password؛
- Password reset نتیجه عمومی مانند «اگر حسابی باشد…»؛
- Status code، Body و Timing تا حد عملی مشابه؛
- عدم تفاوت آشکار در مرحله MFA برای حساب ناموجود؛
- عدم افشای Email/Phone Mask بیش از حد؛
- Log داخلی دقیق، پیام عمومی امن؛
- Rate limit روی Enumeration endpoint.
امنیت نباید Recovery کاربر واقعی را ناممکن کند؛ پیام عمومی را با راه کمک معتبر ترکیب کنید.
CAPTCHA؛ لایه تطبیقی، نه دفاع اصلی
CAPTCHA میتواند هزینه Bot را بالا ببرد، اما سرویس حل، Automation پیشرفته و مزرعه انسانی آن را دور میزنند. همچنین Accessibility و Privacy هزینه دارد.
- پس از Risk/Velocity غیرعادی فعال شود؛
- جایگزین دسترسپذیر داشته باشد؛
- Fail-open/closed با Availability سنجیده شود؛
- CAPTCHA token سمت سرور Verify شود؛
- یک Token چند بار مصرف نشود؛
- حل CAPTCHA Rate limit را Reset کامل نکند؛
- Provider و انتقال داده بررسی شود.
WAF و Bot management
WAF میتواند ترافیک را قبل از Origin کاهش دهد، Reputation و Velocity را ترکیب و Challenge اعمال کند. اما:
- Rule عمومی ممکن است کاربران پشت NAT یا اپراتور مشترک را مسدود کند؛
- IPv6/Proxy rotation، IP-only را دور میزند؛
- API/Mobile header با Browser فرق دارد؛
- Allowlist دائمی Office/VPN میتواند ریسک بسازد؛
- Origin نباید مستقیم قابل دورزدن باشد؛
- Rule change باید Log، Test و Rollback داشته باشد.
معماری WAF را با راهنمای فایروال وب و سرور تکمیل کنید.
Risk-based authentication
Risk engine میتواند بر اساس Signal درخواست Step-up یا محدودیت دهد:
- Device جدید یا Cookie معتبر غایب؛
- Impossible travel با احتیاط در VPN؛
- ASN/Hosting provider و Reputation؛
- Velocity میان چند حساب؛
- زمان/رفتار غیرعادی؛
- Reset اخیر Password/MFA؛
- عملیات حساس پس از Login؛
- Session/Token anomaly.
Risk score حکم قطعی هویت نیست. Explainability، Bias، False positive، Retention و حداقلسازی داده لازماند.
Device fingerprinting و حریم خصوصی
Fingerprint ممکن است Bot را تفکیک کند، اما پایدار/قطعی نیست و میتواند داده پرریسک بسازد:
- فقط Signal لازم؛
- Hash/Rotation و Retention محدود؛
- عدم اتکا به شناسه دائمی پنهان؛
- اطلاع و Consent/مبنای مناسب؛
- Fallback برای Browserهای Privacy-oriented؛
- عدم قفل حساب صرفاً بر Fingerprint؛
- دسترسی و Vendor review.
اصول داده را با راهنمای بودجه و حریم خصوصی داده همراستا کنید.
محافظت از API و Mobile
- Rate limit در API gateway و Backend؛
- OAuth/OIDC flow استاندارد؛
- PKCE برای Client عمومی؛
- Token کوتاهعمر و Refresh rotation؛
- Client secret داخل App موبایل بهعنوان Secret واقعی تلقی نشود؛
- Device attestation فقط Signal، نه دفاع یگانه؛
- Response و Enumeration یکسان؛
- MFA/Step-up در API flow؛
- Versionهای قدیمی و Endpoint legacy حذف/محدود؛
- Log correlation میان Edge و Identity.
WordPress: مسیرهای خاص
wp-login.php
Rate limit و MFA را روی Login واقعی اعمال کنید. تغییر URL ورود Noise را کم میکند، اما کنترل امنیتی اصلی نیست و با Endpoint دیگر دور زده میشود.
XML-RPC
اگر قابلیت لازم نیست، Methodهای احراز هویت بلااستفاده را محدود کنید. خاموشکردن کور ممکن است Integration قانونی را بشکند؛ Usage و Log را اول بررسی کنید.
Application Password
برای API از Credential جدا با Scope/Name، Rotation و Revoke استفاده کنید. فهرست Credentialهای قدیمی را Audit کنید؛ Login MFA از Application password محافظت تعاملی نمیکند.
WooCommerce Account
Login، Registration، Reset، Checkout account creation و REST endpoint باید Policy یکسان داشته باشند. Rate limit سخت نباید Checkout قانونی را قطع کند.
Administrator
Username عمومی Author لزوماً Secret نیست. Passkey/MFA، Least privilege، Session review و Alert مهمتر از پنهانکردن نام است.
Password reset و Recovery
مهاجم ممکن است Login را کنار بگذارد و Recovery را هدف بگیرد:
- Token تصادفی، کوتاهعمر و یکبارمصرف؛
- Hash Token در Database؛
- لینک فقط HTTPS و Host معتبر؛
- عدم ساخت URL از Host header کنترلنشده؛
- Rate limit بر Account و Network؛
- Response ضد Enumeration؛
- پس از Reset، Session/Token طبق Policy Revoke؛
- اعلان مستقل؛
- MFA factor بدون Verification ضعیف Reset نشود.
Honey account و Canary
حساب غیرقابلاستفادهای که Login قانونی ندارد میتواند Signal با Confidence بالا بدهد، اما باید:
- Credential آن در Production استفاده نشود؛
- هیچ دسترسی واقعی نداشته باشد؛
- Alert فوری و Runbook داشته باشد؛
- نام/Email گمراهکننده داده شخص واقعی نباشد؛
- به مهاجم پاسخ متفاوت ندهد.
Telemetry لازم
| رخداد | فیلدهای امن |
|---|---|
| login_attempt | زمان، account_hash، endpoint، outcome، risk reason |
| rate_limited | dimension، policy version، retry_after |
| mfa_challenge | method، outcome، reason بدون Secret |
| password_reset | requested/completed، account_hash، outcome |
| session_created | session_id hash، assurance، device signal |
| account_change | email/MFA/role change، actor، approval |
Password، OTP، Token کامل، Cookie، Security answer و PII غیرضروری در Log نباشد.
Detection patternها
- Failure زیاد برای یک Account از Sourceهای پراکنده؛
- یک Password candidate روی Accountهای بسیار؛
- Success پس از Failureهای توزیعشده؛
- Password صحیح و MFA failure زیاد؛
- Login جدید و بلافاصله تغییر Email/MFA؛
- تلاش روی Honey account؛
- Reset flood؛
- Spike به تفکیک Endpoint/ASN/نسخه App؛
- Success rate غیرعادی پایین یا بالا؛
- Origin traffic که Edge را دور زده است.
Dashboard و Alert را طبق راهنمای Observability با SLO و Runbook بسازید.
Metricهای دفاع Login
| Metric | چرا؟ |
|---|---|
| attempt/success/failure rate | Baseline و Anomaly |
| unique accounts targeted | Spraying/Stuffing |
| rate-limit decisions | اثر Policy |
| false positive | آسیب به کاربر قانونی |
| MFA enrollment/success | پوشش و اصطکاک |
| ATO confirmed | Outcome امنیتی واقعی |
| recovery/support volume | هزینه عملیاتی |
| time to detect/contain | آمادگی Incident |
پیام به کاربر در فعالیت مشکوک
- زمان و سرویس؛
- نوع رخداد: Login جدید، Reset یا تغییر عامل؛
- مکان تقریبی با هشدار خطای VPN؛
- دکمه/لینک مستقیم امن برای Review؛
- اقدام: تغییر Password، Revoke session، بررسی MFA؛
- عدم ارسال Credential یا لینک دامنه مشکوک؛
- کانال پشتیبانی قابلراستیآزمایی.
Incident response برای Account Takeover
- حساب و Session/Tokenهای مرتبط را Contain کنید.
- Password و Recovery/MFA را Reset امن کنید.
- تغییر Role، Email، API key، سفارش/Refund و Export را Audit کنید.
- Credentialهای هاست، DNS، Git و ایمیل را در Scope ببینید.
- لاگ Edge/Application/Identity را Timeline کنید.
- حسابهای دیگر با Password reuse/Signal مشابه را بررسی کنید.
- کاربر و ذینفعان را متناسب با اثر مطلع کنید.
- Control gap، Detection و Recovery را اصلاح کنید.
- Post-incident review بدون حذف شواهد.
تست کنترلها
- Rate limit یک Account از IPهای مختلف؛
- Accountهای مختلف از یک IP/NAT؛
- Spraying آهسته؛
- Login موفق پس از Throttle؛
- False positive کاربر پشت اپراتور مشترک؛
- CAPTCHA expired/replay؛
- Password blocklist و Unicode؛
- MFA failure/Recovery؛
- Reset enumeration و Token replay؛
- API/Mobile/legacy endpoint؛
- Application password؛
- Edge bypass/Origin direct؛
- Alert و Runbook واقعی.
تست در محیط مجاز و با حسابهای ساختگی انجام شود؛ از Credential واقعی یا ترافیک آسیبزا استفاده نکنید.
اشتباههای پرتکرار
- فقط تغییر URL ورود؛
- مسدودکردن IP ثابت و نادیدهگرفتن حمله توزیعشده؛
- Lockout سخت بدون دفاع DoS؛
- CAPTCHA برای همه کاربران از اولین تلاش؛
- رمز کوتاه با Composition پیچیده؛
- اجبار تغییر Password دورهای بیدلیل؛
- MFA فقط برای WordPress و نه ایمیل/هاست؛
- Recovery ضعیف؛
- فراموشی API/XML-RPC/Application password؛
- Log کردن Password/OTP؛
- Rule WAF بدون False-positive metric؛
- نبود Incident runbook.
نقشه اجرای ۳۰روزه
هفته اول: موجودی و Baseline
Endpointها، Accountهای حساس، Log، نرخ ورود و مسیر Recovery را فهرست کنید.
هفته دوم: Password و Rate limit
Blocklist، Policy، Backoff چندبعدی، Response یکنواخت و Edge rule را در Staging تست کنید.
هفته سوم: MFA و Detection
Passkey/MFA ادمین، Alert، Honey account و Session review را فعال کنید.
هفته چهارم: Drill و Tune
Spraying/Stuffing مجاز را شبیهسازی، False positive را Tune و ATO runbook را تمرین کنید.
چکلیست دفاع در برابر Brute Force و Credential Stuffing
- همه Login/Reset/API endpointها در Scope هستند.
- Password طول مناسب و breached-password blocklist دارد.
- Composition و Rotation بیدلیل تحمیل نمیشود.
- Password با Hash کند و قابلارتقا ذخیره میشود.
- حسابهای حساس MFA مقاومتر دارند.
- Rate limit چندبعدی و Progressive است.
- Lockout به ابزار DoS تبدیل نمیشود.
- Response و Timing تا حد عملی ضد Enumeration است.
- CAPTCHA تطبیقی و دسترسپذیر است.
- WAF و Origin قابل دورزدن نیستند.
- API/XML-RPC/Application password پوشش دارند.
- Recovery و Reset امن و Rate-limited هستند.
- Log بدون Secret و Alertهای ATO فعالاند.
- False positive و Support impact سنجیده میشوند.
- Incident runbook تست شده است.
سؤالات متداول Brute Force و Credential Stuffing
تفاوت Brute Force و Credential Stuffing چیست؟
Brute Force Password را حدس میزند؛ Credential Stuffing زوجهای Username/Password سرقتشده از سرویسهای دیگر را روی Login شما امتحان میکند.
آیا CAPTCHA کافی است؟
خیر. CAPTCHA فقط هزینه Automation را بالا میبرد و قابل دورزدن است. MFA، Rate limiting، Blocklist رمز افشاشده، WAF و Detection باید کنار آن باشند.
پس از چند تلاش حساب را قفل کنیم؟
عدد عمومی امنی وجود ندارد. Baseline و ریسک را بسنجید و Backoff/Rate limit چندبعدی را طوری تنظیم کنید که هم حمله کند شود و هم Lockout به DoS تبدیل نشود.
آیا تغییر آدرس wp-login جلوی حمله را میگیرد؟
خیر. Noise را کم میکند اما مهاجم Endpointهای دیگر را پیدا میکند. کنترل باید روی سیستم احراز هویت، API، Recovery و زیرساخت اعمال شود.
بهترین دفاع Credential Stuffing چیست؟
MFA، ترجیحاً Passkey/FIDO2 برای حساب حساس، اثر Password سرقتشده را کم میکند؛ در کنار آن breached-password check، Rate limit و Bot detection لازماند.
جمعبندی
دفاع Login یک Rule یا Plugin نیست. Password policy مدرن، MFA، Rate limit چندبعدی، Response ضد Enumeration، Bot/WAF، پوشش API و Recovery، Telemetry و Incident response باید یک سیستم هماهنگ بسازند.
برای Audit Login، تنظیم Rate limit یا تمرین Account takeover، از فرم مشاوره امنیت مایندیو استفاده کنید و پلتفرم، Endpointها و الگوی خطای ناشناس را بنویسید.
