Credential Stuffing چیست؟ چگونه از ورود با رمزهای افشاشده جلوگیری کنیم؟

پاسخ کوتاه: Credential Stuffing یا «استفاده خودکار از اطلاعات ورود افشاشده» حمله‌ای است که در آن مهاجم نام کاربری و رمز عبوری را که قبلاً از سرویس دیگری افشا شده‌اند، روی سایت‌ها و برنامه‌های دیگر آزمایش می‌کند. بهترین دفاع، ترکیبی از MFA یا Passkey، جلوگیری از استفاده رمزهای افشاشده، Rate Limiting، تشخیص Bot، تحلیل ریسک ورود، مدیریت صحیح Session و مانیتورینگ تلاش‌های مشکوک است.

اگر یک وب‌سایت پایگاه داده کاربران خود را به‌درستی ایمن کرده باشد، رمزهای عبور را با Argon2id یا الگوریتم مناسب Hash کند و حتی هیچ رخنه اطلاعاتی مستقیمی نداشته باشد، آیا باز هم حساب کاربران آن می‌تواند با رمز عبورشان هک شود؟

پاسخ بله است.

مشکل از رفتار بسیار رایجی به نام Password Reuse یا استفاده مجدد از رمز عبور ناشی می‌شود.

کاربری را تصور کنید که برای یک فروشگاه اینترنتی، شبکه اجتماعی، سرویس ایمیل و وب‌سایت دیگری از یک Email و Password مشابه استفاده می‌کند. اگر یکی از این سرویس‌ها دچار Data Breach شود و Credential قابل استفاده کاربر در اختیار مهاجمان قرار گیرد، مهاجم می‌تواند همان Credential را روی سرویس‌های دیگر نیز امتحان کند.

این تکنیک Credential Stuffing نام دارد.

برخلاف Brute Force کلاسیک، مهاجم الزاماً میلیون‌ها Password مختلف را برای یک حساب حدس نمی‌زند. در Credential Stuffing او از جفت‌های Username/Password واقعی استفاده می‌کند که قبلاً در یک Data Breach، Phishing Campaign، Malware Infection یا منبع دیگری افشا شده‌اند.

OWASP، Credential Stuffing را آزمایش خودکار Credentialهای سرقت‌شده روی Authentication Endpoint سرویس‌های دیگر برای پیدا کردن حساب‌هایی تعریف می‌کند که کاربر در آن‌ها از همان اطلاعات ورود استفاده کرده است.

ریشه اصلی موفقیت این حمله اغلب ضعف Password Policy یک سایت خاص نیست؛ بلکه استفاده مجدد کاربران از یک Secret مشترک در چند سرویس مختلف است.

به همین دلیل Credential Stuffing یکی از نمونه‌های مهمی است که نشان می‌دهد امنیت Authentication فقط با Hash کردن Password در Database خود سایت تأمین نمی‌شود.

سایت باید فرض کند:

ممکن است Password صحیح یکی از کاربران از جایی خارج از کنترل ما قبلاً افشا شده باشد.

این تغییر دیدگاه، پایه طراحی یک سیستم Authentication مقاوم در برابر Credential Stuffing است.

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

Credential Stuffing چیست؟

Credential Stuffing یک Automated Authentication Attack است که در آن مهاجم مجموعه‌ای از Credentialهای افشاشده شامل مواردی مانند:

• Email و Password
• Username و Password
• شماره تلفن و Password
• شناسه حساب و Password

را روی Login Endpoint سرویس دیگری امتحان می‌کند.

هدف مهاجم این نیست که Password را حدس بزند.

او Passwordی را دارد که قبلاً برای همان فرد در سرویس دیگری معتبر بوده است و بررسی می‌کند آیا کاربر همان Password را دوباره استفاده کرده است یا خیر.

OWASP این حمله را در دسته Automated Threatها با شناسه OAT-008 معرفی می‌کند.

یک جریان ساده Credential Stuffing را می‌توان چنین نمایش داد:

افشای Credential در سرویس A
        ↓
به‌دست آمدن Username/Password
        ↓
استفاده مجدد کاربر از همان Password
        ↓
آزمایش Credential روی سرویس B
        ↓
Credential معتبر است؟
        ↓
بله
        ↓
Account Takeover

بنابراین Credential Stuffing معمولاً به یک پیش‌شرط مهم وابسته است:

Credential Reuse

اگر کاربر در هر سایت Password منحصربه‌فرد داشته باشد، افشای Credential یک سرویس نباید باعث ورود مستقیم مهاجم به سرویس دیگر شود.

چرا Credential Stuffing خطرناک است؟

Credential Stuffing از چند جهت با حملات Guessing ساده تفاوت دارد.

اول اینکه Credential مورد استفاده مهاجم ممکن است کاملاً صحیح باشد.

از دید Login System، Request ممکن است شامل:

Username صحیح
+
Password صحیح

باشد.

بنابراین Authentication Server لزوماً نمی‌تواند فقط براساس صحیح یا غلط بودن Password تشخیص دهد چه کسی پشت Request قرار دارد.

دوم اینکه Credential Stuffing معمولاً Automation-Friendly است.

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

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

اگر هزاران Request از یک IP ارسال شوند، Rate Limit ساده مؤثر است.

اما اگر درخواست‌ها میان تعداد زیادی IP، Device یا Network توزیع شوند، تشخیص پیچیده‌تر می‌شود.

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

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

Credential Stuffing چگونه اتفاق می‌افتد؟

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

هدف این بخش آموزش اجرای حمله نیست؛ بلکه شناخت Trust Boundaryهایی است که تیم امنیت باید محافظت کند.

مرحله اول: Credential افشا می‌شود

Credential ممکن است از طریق:

• Data Breach سرویس دیگر
• Phishing
• Malware
• Infostealer
• Database Leak
• Credential Dump
• سیستم قدیمی ناامن
• Password ذخیره‌شده در Plaintext
• Repository افشاشده

در اختیار شخص غیرمجاز قرار بگیرد.

نکته مهم این است که Data Breach الزاماً مربوط به سایت شما نیست.

ممکن است سایت شما هیچ‌گاه هک نشده باشد.

مرحله دوم: کاربر Password را دوباره استفاده کرده است

کاربر ممکن است همان Password یا نسخه بسیار مشابه آن را در چند Account داشته باشد.

مثلاً:

Service A → Email + Password X
Service B → Email + Password X
Service C → Email + Password X

افشای Service A اکنون Service B و C را نیز تحت تأثیر قرار داده است.

مرحله سوم: Credential روی Login System دیگری بررسی می‌شود

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

در حملات مدرن این فرایند معمولاً Automated است.

مرحله چهارم: Account معتبر شناسایی می‌شود

اگر Login موفق شود، مهاجم ممکن است کنترل حساب را به دست آورد.

اما Login تنها مرحله خطر نیست.

پس از ورود ممکن است عملیات دیگری انجام شود:

• تغییر Email
• تغییر Password
• اضافه کردن روش Recovery
• مشاهده اطلاعات خصوصی
• استفاده از اعتبار مالی حساب
• تغییر Address
• سرقت Reward یا Credit
• انجام خرید
• دسترسی به API Token
• سوءاستفاده از حساب معتبر

در این مرحله Credential Stuffing تبدیل به Account Takeover یا ATO می‌شود.

تفاوت Credential Stuffing با Brute Force چیست؟

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

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

Brute Force

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

مثلاً:

Account: [email protected]

Password attempt 1
Password attempt 2
Password attempt 3
...

تمرکز روی یک Account و تعداد زیادی Guess است.

Credential Stuffing

در Credential Stuffing مهاجم Credentialهای قبلاً افشاشده را در اختیار دارد.

[email protected] + known password
[email protected] + known password
[email protected] + known password

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

به همین دلیل Password Strength به تنهایی Credential Stuffing را متوقف نمی‌کند.

یک Password بسیار طولانی و پیچیده اگر عیناً در سایت دیگری افشا و دوباره استفاده شود، همچنان می‌تواند در Credential Stuffing کاربرد داشته باشد.

تفاوت Credential Stuffing و Password Spraying

Password Spraying نیز حمله‌ای متفاوت است.

در Password Spraying مهاجم یک یا تعداد محدودی Password رایج را روی تعداد زیادی Account امتحان می‌کند.

برای مثال ساختار مفهومی آن چنین است:

Password رایج
      ↓
Account A
Account B
Account C
Account D
...

در حالی که در Credential Stuffing:

Credential Pair A
Credential Pair B
Credential Pair C
...

هر Account معمولاً Credential مربوط به خودش را دارد.

OWASP این سه گروه را جدا می‌کند:

این تفاوت برای Detection بسیار مهم است.

چرا Account Lockout ساده کافی نیست؟

فرض کنید بعد از پنج Login ناموفق، Account را 30 دقیقه Lock کنیم.

این روش می‌تواند Brute Force مستقیم را کند کند.

اما Credential Stuffing ممکن است برای هر Account فقط یک یا دو Attempt داشته باشد.

مثلاً مهاجم:

Account A → 1 Attempt
Account B → 1 Attempt
Account C → 1 Attempt
Account D → 1 Attempt

هیچ حسابی به Threshold قفل شدن نمی‌رسد.

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

همچنین Lockout بسیار تهاجمی خودش می‌تواند به Denial of Service تبدیل شود.

اگر مهاجم Username قربانی را بداند، می‌تواند عمداً Login ناموفق ایجاد کند تا Account قربانی دائماً Lock شود.

به همین دلیل Lockout باید بخشی از Defense in Depth باشد، نه تنها کنترل موجود.

چرا Rate Limiting هنوز مهم است؟

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

اما Rate Limit خوب باید چندبعدی باشد.

نباید فقط بگوییم:

حداکثر 10 Request برای هر IP

بلکه بهتر است Signalهای مختلف بررسی شوند:

Requests per IP
Requests per Account
Requests per Device
Requests per Session
Failed logins per subnet
Distinct accounts per IP
Distinct IPs per account
Success/failure ratio
Velocity over time

مثلاً:

یک IP که در چند دقیقه سعی می‌کند وارد صدها Account مختلف شود، رفتار طبیعی User نیست.

این Signal می‌تواند بسیار مهم‌تر از تعداد Attempt روی یک Account خاص باشد.

NIST نیز برای Password Authentication استفاده از Rate Limiting مؤثر روی تلاش‌های ناموفق را الزامی می‌داند.

MFA؛ یکی از مهم‌ترین دفاع‌ها در برابر Credential Stuffing

Multi-Factor Authentication باعث می‌شود دانستن Password به تنهایی برای Login کافی نباشد.

مثلاً:

Password
+
Security Key

یا:

Password
+
Authenticator

در Credential Stuffing مهاجم معمولاً Credential اصلی را دارد، اما Factor دوم را ندارد.

OWASP، MFA را مؤثرترین کنترل عمومی در برابر Credential Stuffing، Password Spraying و بخش بزرگی از حملات مبتنی بر Password معرفی می‌کند.

با این حال تمام MFAها سطح امنیت یکسانی ندارند.

آیا SMS OTP برای Credential Stuffing مفید است؟

بله، وجود SMS OTP معمولاً بسیار بهتر از Password-Only است.

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

اما SMS دارای محدودیت‌هایی است:

• SIM Swap
• Social Engineering
• اختلال در دریافت پیام
• وابستگی به شبکه مخابراتی
• Phishing
• Recovery ضعیف

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

Authenticator App

TOTP تولیدشده در برنامه‌هایی مانند Authenticator یک Factor اضافه ایجاد می‌کند.

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

اما TOTP کاملاً Phishing-Resistant نیست.

User ممکن است Code را در صفحه جعلی وارد کند.

پس برای محیط‌های پرریسک روش‌های FIDO بهتر هستند.

Passkey؛ راهکاری بنیادی‌تر برای Credential Stuffing

Passkey به جای Secret مشترک و قابل تایپ، از Public-Key Cryptography استفاده می‌کند.

در مدل Passkey:

• Private Key در اختیار User باقی می‌ماند.
• Server Public Key را نگهداری می‌کند.
• Credential برای همان Service طراحی شده است.
• Password قابل استفاده مجدد وجود ندارد.

به همین دلیل مدل کلاسیک Credential Stuffing عملاً چیزی برای Replay کردن ندارد.

FIDO Alliance Passkey را مقاوم در برابر Phishing و Credential Stuffing معرفی می‌کند و توضیح می‌دهد که Passkeyها براساس جفت کلید رمزنگاری ساخته می‌شوند و Shared Password قابل سرقتی روی Server وجود ندارد.

برای Applicationهای جدید، ارائه Passkey در کنار Login قدیمی یا برنامه مهاجرت تدریجی به Passwordless Authentication می‌تواند یکی از مؤثرترین تغییرات معماری باشد.

مراقب Recovery باشید

استفاده از Passkey یا MFA زمانی ارزش واقعی دارد که Account Recovery نیز امن باشد.

فرض کنید Login اصلی بسیار قدرتمند است:

Passkey

اما گزینه:

Forgot password → Email ضعیف → Reset

یا:

Lost MFA → Security question ساده

به مهاجم اجازه دور زدن کامل Authentication را بدهد.

در این صورت مهاجم به جای Login اصلی، Recovery Flow را هدف می‌گیرد.

OWASP نیز تأکید می‌کند که MFA Recovery نباید تبدیل به مسیری ساده برای Bypass کردن MFA شود.

بررسی Passwordهای افشاشده

یکی از مهم‌ترین کنترل‌های پیشگیرانه این است که هنگام:

• ساخت حساب
• انتخاب Password جدید
• تغییر Password
• Reset Password

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

NIST SP 800-63B توصیه می‌کند Verifier هنگام تعیین یا تغییر Password، Password پیشنهادی را با Blocklist شامل Passwordهای رایج، مورد انتظار یا افشاشده مقایسه کند و در صورت وجود Match از User بخواهد Secret دیگری انتخاب کند.

این کنترل اهمیت زیادی دارد.

فرض کنید User Password بسیار پیچیده‌ای انتخاب می‌کند:

طولانی + حروف + اعداد + علامت

اما همین Password قبلاً در یک Breach وجود داشته است.

پیچیدگی آن دیگر مزیت چندانی در برابر Credential Stuffing ایجاد نمی‌کند.

Attacker آن را حدس نمی‌زند؛ Password را از قبل دارد.

Pwned Passwords چیست؟

یکی از سرویس‌های شناخته‌شده برای بررسی Passwordهای افشاشده Pwned Passwords است.

این سرویس متعلق به Have I Been Pwned است.

یکی از ویژگی‌های مهم API آن مدل k-Anonymity است.

در این روش لازم نیست Password کامل یا حتی Hash کامل برای Service ارسال شود.

به‌طور خلاصه:

Password
↓
Hash محلی
↓
ارسال بخش کوچکی از Hash
↓
دریافت Candidateها
↓
مقایسه کامل به‌صورت Local

مستندات رسمی Have I Been Pwned توضیح می‌دهند که Pwned Passwords برای جست‌وجوی Password از مدل k-Anonymity و Prefix پنج کاراکتری Hash پشتیبانی می‌کند.

این مدل امکان بررسی Password افشاشده را بدون ارسال خود Password فراهم می‌کند.

آیا باید Password فعلی همه کاربران را بررسی کنیم؟

Password Plaintext نباید در Database وجود داشته باشد.

بنابراین سیستم معمولاً نمی‌تواند Password موجود کاربران را بازیابی و برای سرویس Breach Checking بررسی کند.

این نکته یکی از دلایل اهمیت بررسی Password هنگام:

Registration
Password Change
Password Reset

است؛ زمانی که Password Plaintext برای مدت کوتاه در جریان Authentication در اختیار Backend قرار دارد.

هیچ‌گاه برای قابلیت Breach Checking نباید Passwordهای کاربران را Plaintext ذخیره کرد.

Password Storage صحیح همچنان ضروری است

Credential Stuffing معمولاً از Breach خارج از سرویس شما استفاده می‌کند، اما این به معنی کم‌اهمیت شدن Password Storage نیست.

اگر Database خود سایت افشا شود، طراحی Password Storage تعیین می‌کند آیا Attacker می‌تواند Passwordها را استخراج کند یا خیر.

OWASP توصیه می‌کند Password با الگوریتم‌های مخصوص Password Hashing مانند Argon2id ذخیره شود و Hash سریع عمومی مانند SHA-256 به تنهایی برای Password Storage مناسب نیست.

اصل مهم:

Credential Stuffing Defense
≠
Password Storage Defense

هر دو لازم هستند.

Password Hashing خوب از User در برابر Breach سایت شما محافظت می‌کند.

MFA، Breached Password Detection و Anti-Automation از User در برابر Credentialهای افشاشده خارج از سایت محافظت می‌کنند.

Password Manager چه کمکی می‌کند؟

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

اگر User برای:

example-a.com

Password A و برای:

example-b.com

Password B داشته باشد، Breach سرویس A مستقیماً سرویس B را تحت تأثیر قرار نمی‌دهد.

NIST استفاده از Password Manager و قابلیت Autofill و Paste Password را پشتیبانی می‌کند و توصیه می‌کند سایت‌ها مانع استفاده User از این امکانات نشوند.

بنابراین مواردی مانند:

• غیرفعال کردن Paste در Password Field
• محدودیت عجیب روی Characterها
• Maximum Length بسیار کوتاه

می‌توانند امنیت User را کاهش دهند.

Password Complexity به تنهایی مشکل را حل نمی‌کند

یک Policy ممکن است بگوید Password باید:

• حرف بزرگ داشته باشد.
• حرف کوچک داشته باشد.
• عدد داشته باشد.
• علامت داشته باشد.

این Policy شاید Guessing را کمی دشوار کند.

اما اگر Password افشا و Reuse شود، Attacker دقیقاً همان Password را دارد.

Credential Stuffing نیاز به Guess ندارد.

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

• طول مناسب
• Password منحصربه‌فرد
• Blocklist Passwordهای افشاشده
• Password Manager
• MFA
• Passkey

نه اجبار بی‌پایان به تغییر شکل Password.

تغییر دوره‌ای Password خوب است؟

تغییر اجباری Password هر 30، 60 یا 90 روز بدون دلیل امنیتی مشخص می‌تواند باعث رفتارهای بد User شود.

مثلاً User:

Password1
Password2
Password3

می‌سازد یا Password را در مکان ناامن نگه می‌دارد.

NIST توصیه می‌کند تغییر دوره‌ای Arbitrary Password اجباری نباشد؛ اما اگر شواهدی از Compromise وجود دارد، Credential باید تغییر کند.

این تفاوت مهم است:

Periodic Rotation بدون دلیل → معمولاً توصیه نمی‌شود
Known Compromise → Password باید تغییر کند

Risk-Based Authentication چیست؟

در بعضی سرویس‌ها نمی‌توان MFA را برای تمام Loginها اجباری کرد.

در این شرایط می‌توان Risk-Based Authentication یا Adaptive Authentication پیاده کرد.

سیستم Signalهای Login را بررسی می‌کند.

برای مثال:

• Device جدید
• Browser جدید
• IP جدید
• Country غیرعادی
• Impossible Travel
• IP Reputation بد
• تعداد زیاد Login
• رفتار شبیه Bot
• User-Agent غیرمعمول
• Session غیرعادی

اگر Risk پایین باشد:

Username + Password → Login

اما اگر Risk بالا باشد:

Username + Password
↓
Step-Up Authentication
↓
MFA / Passkey

OWASP استفاده از Step-Up MFA در Loginهای غیرعادی مانند Device جدید، IP مشکوک یا تلاش‌های Automation را توصیه می‌کند.

Device Fingerprinting؛ مفید اما نه قطعی

Device Fingerprinting می‌تواند Signal کمکی باشد.

مثلاً Service مشخص کند:

User معمولاً:
Chrome + Windows + Device X

و اکنون Login از Environment کاملاً متفاوتی آمده است.

اما Fingerprint باید با احتیاط استفاده شود.

Browser Privacy Featureها، NAT، VPN و تغییر Device ممکن است User واقعی را متفاوت نشان دهند.

همچنین Attackerهای پیشرفته می‌توانند برخی Signalها را Spoof کنند.

پس:

Fingerprint = Signal

نه:

Fingerprint = Identity

OWASP نیز تأکید می‌کند Client-Side Defenseها باید در قالب Defense in Depth استفاده شوند و قابل Bypass فرض شوند.

Bot Detection

Credential Stuffing در مقیاس بزرگ معمولاً به Automation نیاز دارد.

به همین دلیل Bot Detection نقش مهمی دارد.

سیستم می‌تواند رفتارهایی مانند:

• Request Velocity
• Timing
• Navigation Pattern
• Cookie Behavior
• JavaScript Execution
• Device Signals
• TLS Fingerprint
• IP Reputation

را تحلیل کند.

اما Bot Detection یک مسابقه دائمی است.

Attacker می‌تواند رفتار Automation را به User واقعی شبیه‌تر کند.

بنابراین Bot Detection نیز باید یک Layer باشد.

نه تمام معماری.

CAPTCHA چه نقشی دارد؟

CAPTCHA می‌تواند حمله Automation را کند کند.

اما مشکلاتی دارد:

• Accessibility
• UX ضعیف
• امکان حل توسط سرویس‌های انسانی
• ابزارهای Bypass
• Botهای پیشرفته
• ایجاد اصطکاک برای User واقعی

OWASP پیشنهاد می‌کند CAPTCHA ترجیحاً براساس Risk فعال شود، نه لزوماً برای تمام Loginهای عادی.

برای مثال:

Login عادی → بدون CAPTCHA

Login مشکوک → CAPTCHA

Login بسیار پرریسک → MFA + CAPTCHA یا Block

این روش تجربه کاربران عادی را کمتر تحت تأثیر قرار می‌دهد.

Multi-Step Login

Login سنتی ممکن است در یک Request شامل Username و Password باشد.

برخی سامانه‌ها Authentication را به چند مرحله تقسیم می‌کنند:

Username
↓
Challenge
↓
Password
↓
Risk Check
↓
MFA

این طراحی به تنهایی Credential Stuffing را متوقف نمی‌کند، اما Automation ساده را دشوارتر کرده و نقاط بیشتری برای Risk Evaluation ایجاد می‌کند.

OWASP این روش را یک کنترل تکمیلی می‌داند، نه جایگزین MFA.

Username Enumeration و Credential Stuffing

یکی از مشکلات مرتبط با Login، Username Enumeration است.

اگر سایت برای Account موجود بگوید:

Password اشتباه است

اما برای Account ناموجود بگوید:

این Email ثبت نشده است

Attacker می‌تواند Userهای واقعی را شناسایی کند.

Credential Stuffing با Credential Pairهای از قبل موجود کار می‌کند، اما Username Enumeration همچنان می‌تواند حملات Authentication دیگر را آسان‌تر کند.

بهتر است Error Message عمومی باشد.

مثلاً:

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

اما فقط Message کافی نیست.

Response Code، Timing، Response Length و سایر تفاوت‌ها نیز نباید به‌راحتی وجود Account را افشا کنند.

آیا Error Message باید همیشه یکسان باشد؟

برای User Experience می‌توان طراحی مناسبی انجام داد، اما از نظر امنیتی پاسخ نباید به مهاجم Oracle دقیق برای Account Validity بدهد.

برای مثال نباید:

این Email وجود دارد اما Password اشتباه است.

برای API عمومی Login ارسال شود.

هدف کاهش امکان Enumeration است.

نشانه‌های Credential Stuffing در Log

تشخیص Credential Stuffing نیازمند Logging مناسب است.

فقط ثبت:

Login failed

کافی نیست.

بهتر است اطلاعات غیرحساس زیر در Security Telemetry وجود داشته باشند:

• Timestamp
• Account Identifier Hash یا ID مناسب
• Source IP
• ASN
• Country
• User-Agent
• Device ID در صورت Policy مناسب
• Login Result
• MFA Result
• Risk Score
• CAPTCHA Result
• Session ID غیرحساس
• Reason Code

Secretها نباید Log شوند.

هرگز موارد زیر را ثبت نکنید:

Password
OTP
Recovery Code
Full Session Token
API Secret

الگوهای مشکوک

Credential Stuffing می‌تواند چند Signature رفتاری داشته باشد.

تعداد زیاد حساب از یک IP

IP X:
Account 1
Account 2
Account 3
...

یک حساب از IPهای زیاد

Account X:
IP 1
IP 2
IP 3
...

Failure زیاد همراه با Success کم

ممکن است Attacker هزاران Credential آزمایش کند و فقط چند Credential معتبر باشند.

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

Traffic Login بدون افزایش مشابه Traffic عادی Application می‌تواند مشکوک باشد.

Login از Geography غیرمعمول

به‌خصوص اگر اندکی بعد از Session عادی User رخ دهد.

تغییر فوری تنظیمات حساب بعد از Login

مثلاً:

Login
↓
Change Email
↓
Change Password
↓
Add Recovery Method

این Pattern می‌تواند نشانه Account Takeover باشد.

Alert فقط روی Failed Login کافی نیست

یکی از خطرناک‌ترین رویدادها Login موفق مهاجم است.

اگر SOC فقط Login Failureها را بررسی کند، Successful Credential Stuffing نادیده می‌ماند.

مواردی که پس از Successful Login باید Risk-Scored شوند:

• Login از Device جدید
• تغییر Credential
• تغییر MFA
• تغییر Email
• ایجاد API Key
• برداشت وجه
• خرید غیرمعمول
• Export داده
• تغییر Billing
• افزودن Address

بنابراین Authentication Security باید با Fraud Detection و Session Monitoring ارتباط داشته باشد.

User Notification

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

Notification می‌تواند شامل:

• زمان Login
• Device
• Browser
• Location تقریبی
• گزینه «این من نبودم»

باشد.

OWASP نیز برای رویدادهای مشکوک Authentication اطلاع‌رسانی به User را پیشنهاد می‌کند.

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

Sessions را Revoke کند
Password Change را درخواست کند
MFA را بررسی کند
Incident را ثبت کند

Session Security بعد از Login

Credential Stuffing تنها Login را هدف نمی‌گیرد.

پس از Account Takeover، مهاجم Session معتبر دارد.

بنابراین Session Management بخش مهم دفاع است.

Session Cookie باید:

Secure
HttpOnly
SameSite مناسب

داشته باشد.

Session ID باید غیرقابل حدس باشد.

Sessionها باید:

• Expiration مناسب
• Revocation
• Logout واقعی
• Rotation در نقاط حساس

داشته باشند.

تغییر Password باید Sessionها را چه کند؟

اگر User Password خود را به دلیل Compromise تغییر می‌دهد، منطقی است Sessionهای قدیمی بررسی یا Revoke شوند.

در بسیاری از سرویس‌های حساس بهتر است User بتواند:

Sign out all devices

را انتخاب کند.

در Incident آشکار می‌توان Sessionهای موجود را به‌صورت اجباری Invalid کرد.

در غیر این صورت Attacker ممکن است Credential اولیه را از دست بدهد، اما Session قبلی او همچنان فعال بماند.

MFA Reset یکی از نقاط حساس است

فرض کنید Attacker با Password افشاشده Login را شروع می‌کند اما MFA جلوی او را می‌گیرد.

مرحله بعدی ممکن است تلاش برای:

Reset MFA

باشد.

اگر MFA Reset تنها با Password انجام شود، Factor دوم عملاً ارزش خود را از دست می‌دهد.

MFA Reset باید Security Level نزدیک به Enrollment اولیه داشته باشد.

ممکن است نیاز باشد:

• Re-authentication
• Recovery Code
• Existing Device
• Verified Channel
• Support Review
• Delay
• User Notification

استفاده شود.

Account Recovery را ضعیف‌تر از Login نسازید

این قانون ساده اما مهم است:

Recovery Security ≥ Authentication Risk

اگر Account Login به Passkey نیاز دارد اما Recovery فقط یک سؤال امنیتی ساده می‌پرسد، مهاجم Recovery را انتخاب می‌کند.

OWASP استفاده از Security Question به‌عنوان تنها روش Password Reset را توصیه نمی‌کند.

Re-Authentication برای عملیات حساس

حتی پس از Login معتبر، برای بعضی عملیات حساس بهتر است Re-authentication انجام شود.

مانند:

• تغییر Password
• تغییر Email
• غیرفعال کردن MFA
• اضافه کردن Account بانکی
• برداشت دارایی
• ایجاد API Token
• مشاهده Recovery Code
• تغییر Role

اگر Session از طریق Credential Stuffing به دست آمده باشد، Step-Up Authentication می‌تواند Damage را کاهش دهد.

OWASP Re-authentication برای عملیات حساس را بخشی از Authentication Security می‌داند.

Credential Stuffing در APIها

فقط صفحه Login وب هدف نیست.

Application ممکن است Endpointهایی مانند:

/api/login
/oauth/token
/mobile/login
/graphql

داشته باشد.

اگر Web Login دارای CAPTCHA و WAF باشد اما Mobile API همان Authentication را بدون Anti-Automation ارائه کند، مهاجم Endpoint آسان‌تر را انتخاب می‌کند.

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

شامل:

• Website
• Mobile API
• Legacy API
• Admin Panel
• Partner Portal
• OAuth
• SSO
• GraphQL
• WebSocket Authentication

Security Policy باید در همه مسیرها Consistent باشد.

Legacy Endpoint خطر بزرگی است

گاهی تیم یک Login جدید با MFA راه‌اندازی می‌کند، اما نسخه قدیمی API همچنان Password-Only است.

در چنین شرایطی مهاجم نیازی ندارد Interface جدید را هدف بگیرد.

او مسیر Legacy را پیدا می‌کند.

بنابراین هنگام Deploy Authentication جدید باید تمام Endpointهای قدیمی Audit شوند.

Credential Stuffing در WordPress

WordPress نیز می‌تواند هدف Credential Stuffing قرار بگیرد.

به‌خصوص سایت‌هایی که:

• User Registration دارند
• WooCommerce دارند
• Membership دارند
• Subscriber زیاد دارند
• Admin Account متعدد دارند

مهاجم ممکن است Credentialهای افشاشده کاربران را روی Login WordPress بررسی کند.

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

• MFA برای Administratorها
• Password منحصربه‌فرد
• Rate Limiting
• Login Monitoring
• WAF
• Bot Protection
• محدودسازی Login Abuse
• به‌روزرسانی WordPress و Pluginها

است.

آیا تغییر wp-login.php جلوی Credential Stuffing را می‌گیرد؟

مخفی کردن یا تغییر URL Login ممکن است Noise بعضی Botهای ساده را کاهش دهد.

اما نباید آن را کنترل امنیتی اصلی در نظر گرفت.

اگر Endpoint Login قابل کشف باشد یا Application Functionality آن را افشا کند، Attacker می‌تواند مسیر جدید را پیدا کند.

Security by Obscurity نباید جای:

MFA
Rate Limiting
Password Security
Monitoring

را بگیرد.

WooCommerce و Credential Stuffing

فروشگاه‌های اینترنتی هدف جذابی هستند، زیرا Account ممکن است حاوی:

• Address
• Order History
• Personal Information
• Store Credit
• Loyalty Point
• Payment Metadata
• Gift Balance

باشد.

در بعضی فروشگاه‌ها Account Takeover می‌تواند مستقیماً ارزش مالی داشته باشد.

بنابراین WooCommerce Login باید همانند Authentication یک Application حساس مدیریت شود.

Administratorها باید Policy قوی‌تری داشته باشند

همه Accountها Impact یکسان ندارند.

Admin، Editor، Support Agent و User عادی سطح دسترسی متفاوتی دارند.

اگر اجرای MFA برای تمام کاربران ممکن نباشد، حداقل باید برای:

• Administrator
• Staff
• Support
• Financial User
• Developer

اجباری باشد.

OWASP نیز پیشنهاد می‌کند در صورت تفاوت Roleها، Defenseهای قوی‌تر برای Roleهای حساس اعمال شوند.

IP Blocking چه محدودیتی دارد؟

Block کردن IPهای مخرب مفید است.

اما IP به تنهایی Identity نیست.

مشکلات شامل:

• VPN
• Proxy
• Mobile Network
• NAT
• Cloud IP
• Residential Proxy
• Shared IP

است.

اگر یک IP را بعد از چند Failure برای همیشه Block کنیم، احتمال False Positive بالا می‌رود.

بهتر است IP یکی از چند Signal باشد.

Geo Blocking

اگر سرویس فقط به یک منطقه مشخص ارائه می‌شود، Geo Restriction می‌تواند Attack Surface را کاهش دهد.

اما برای سرویس جهانی مناسب نیست.

همچنین Location به تنهایی قطعی نیست.

VPN می‌تواند Geography را تغییر دهد.

Geo باید بخشی از Risk Score باشد.

Threat Intelligence

IP Reputation، ASN Reputation، Known Proxy List و Threat Feed می‌توانند در Risk-Based Authentication کمک کنند.

اما Feed نیز کامل نیست.

IP جدید ممکن است هنوز Reputation بد نداشته باشد.

از سوی دیگر IP یک User واقعی ممکن است به اشتباه در List قرار گرفته باشد.

بنابراین Threat Intelligence یک Signal تکمیلی است.

CAPTCHA و MFA را بعد از Risk فعال کنیم یا همیشه؟

این تصمیم به Application بستگی دارد.

برای Admin Panel:

MFA همیشه

معمولاً منطقی است.

برای Consumer Site بزرگ:

Risk-based MFA

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

مثلاً:

Known Device + Low Risk → Password

New Device → MFA

High-risk IP → CAPTCHA + MFA

Critical Action → Re-authentication

Credential Stuffing و Credential Cracking یکی نیستند

Credential Cracking تلاش برای کشف Credential است.

Credential Stuffing استفاده از Credential از قبل به‌دست‌آمده است.

این تفاوت در Threat Modeling مهم است.

برای Credential Cracking:

Password Strength
Hashing
Rate Limit

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

برای Credential Stuffing:

Password Reuse
MFA
Breach Detection
Risk Analysis

نقش ویژه‌ای دارد.

جلوگیری از Password Reuse داخل همان سایت

سایت ممکن است History چند Password قبلی را نگه دارد تا User فوراً به Password قبلی برنگردد.

اما این کار Credential Reuse بین چند سایت را حل نمی‌کند.

Application نمی‌داند User در Gmail، فروشگاه دیگری یا شبکه اجتماعی چه Passwordی دارد.

برای حل این مشکل:

• Password Manager
• Breached Password Check
• User Education
• Passkey

راهکارهای مؤثرتری هستند.

آموزش کاربر همچنان اهمیت دارد

تکنولوژی باید بار اصلی دفاع را تحمل کند، اما User Awareness نیز مفید است.

User باید بداند:

• یک Password را در چند سایت استفاده نکند.
• Password Manager استفاده کند.
• MFA فعال کند.
• Login Alert را جدی بگیرد.
• Password افشاشده را سریع تغییر دهد.
• Recovery Code را امن نگه دارد.
• Password یا OTP را برای Support ارسال نکند.

اما نباید تمام مسئولیت به User منتقل شود.

Application باید فرض کند User ممکن است اشتباه کند.

امنیت مناسب Registration

مقابله با Credential Stuffing از زمان Registration شروع می‌شود.

فرایند مناسب:

User Password را انتخاب می‌کند
↓
Length Validation
↓
Breached Password Check
↓
Password Strength Feedback
↓
Hash امن
↓
پیشنهاد MFA / Passkey

اگر Password در Blocklist باشد:

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

بهتر از Message مبهم:

Password invalid

است.

NIST توصیه می‌کند دلیل Reject شدن Password Blocklist به User توضیح داده شود.

Hashing Password و Breach Check را اشتباه نگیرید

دو فرایند جدا هستند.

Breach Check

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

Password Hashing

Password را برای ذخیره امن تبدیل می‌کند.

Flow:

Password
↓
Breach Check
↓
Password Policy
↓
Argon2id / Password Hashing
↓
Database

Password Plaintext نباید بعد از پایان عملیات نگهداری شود.

Response Time و User Enumeration

در Login API حتی Timing ممکن است اطلاعات بدهد.

اگر Account ناموجود:

10 ms

و Account موجود با Password اشتباه:

300 ms

باشد، Attacker ممکن است تفاوت را تحلیل کند.

این موضوع پیچیده است و نباید با Delay ثابت ساده حل شود، اما تیم امنیت باید Timing Discrepancy را در تست Authentication بررسی کند.

Credential Stuffing و DDoS

Credential Stuffing هدف اصلی‌اش Account Takeover است، نه Availability.

اما حجم بالای Login Attempt می‌تواند Resource مصرف کند.

به‌خصوص Password Hashing عمداً CPU/Memory Intensive است.

اگر Attacker تعداد زیادی Login Failure ایجاد کند، Authentication Server ممکن است تحت فشار قرار بگیرد.

بنابراین Anti-Automation باید علاوه بر Security، Capacity Planning را نیز در نظر بگیرد.

Rate Limiting قبل از Password Hashing

از دید معماری، بعضی کنترل‌های Abuse Prevention بهتر است قبل از عملیات پرهزینه Authentication قرار بگیرند.

مثلاً:

Request
↓
Edge Rate Limit
↓
Bot Detection
↓
Risk Evaluation
↓
Authentication

اما مراقب باشید Error Response طوری نباشد که Username Enumeration ایجاد کند.

CDN و WAF

CDN یا WAF می‌تواند:

• Rate Limit
• IP Reputation
• Bot Management
• Geo Rule
• Challenge
• Traffic Analytics

فراهم کند.

اما WAF نباید تنها Defense باشد.

Authentication Backend نیز باید کنترل مستقل داشته باشد.

اگر WAF Bypass شد، Login Endpoint نباید بدون هیچ محدودیتی در دسترس باشد.

Defense in Depth

معماری امن Credential Stuffing می‌تواند چنین باشد:

Internet
   ↓
CDN / DDoS Protection
   ↓
WAF / Bot Management
   ↓
Rate Limiting
   ↓
Login Endpoint
   ↓
Risk Analysis
   ↓
Password Authentication
   ↓
MFA / Passkey
   ↓
Session Management
   ↓
Post-login Fraud Detection

در کنار آن:

Breached Password Blocking
Logging
Monitoring
User Notification
Threat Intelligence
Account Recovery Security

قرار می‌گیرد.

هیچ Layer به تنهایی کافی نیست.

یک Policy پیشنهادی برای Login

برای یک Application حساس می‌توان منطق مفهومی زیر را داشت:

Login Request
↓
آیا Traffic از نظر Automation مشکوک است؟
      ↓
   Challenge / Limit
↓
Credential معتبر است؟
      ↓
Risk Score
↓
Low Risk → ادامه
Medium Risk → MFA
High Risk → MFA قوی / Block / Review
↓
Session Creation
↓
Post-login Monitoring

این طراحی بهتر از تصمیم دودویی:

Password درست بود → همیشه Login

است.

اشتباهات رایج در مقابله با Credential Stuffing

فقط استفاده از Password Complexity

Credential افشاشده نیازی به Guess شدن ندارد.

فقط Account Lockout

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

فقط Rate Limit بر اساس IP

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

CAPTCHA دائمی برای همه

UX را خراب می‌کند و همچنان قابل Bypass است.

استفاده نکردن از MFA

Password صحیح افشاشده مستقیماً Account را در معرض خطر قرار می‌دهد.

MFA ضعیف با Recovery بسیار ساده

Attacker به جای MFA، Recovery Flow را هدف می‌گیرد.

عدم بررسی Passwordهای افشاشده

User ممکن است Credential شناخته‌شده را دوباره انتخاب کند.

اعتماد کامل به WAF

Backend نیز باید Control داشته باشد.

ثبت Password در Log

این اشتباه می‌تواند خودش Credential Leak جدید ایجاد کند.

نادیده گرفتن Successful Loginهای غیرعادی

همیشه حمله با Failure پایان نمی‌یابد.

فراموش کردن API قدیمی

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

نگهداری Session پس از Incident

تغییر Password بدون Revocation Session ممکن است Attacker را داخل Account نگه دارد.

چک‌لیست جلوگیری از Credential Stuffing

1. MFA را برای حساب‌های حساس اجباری کنید.
2. امکان استفاده از Passkey را بررسی کنید.
3. Administratorها را Password-Only رها نکنید.
4. Passwordهای جدید را با Breach Blocklist بررسی کنید.
5. از Password Manager پشتیبانی کنید.
6. Paste در Password Field را مسدود نکنید.
7. از Passwordهای منحصربه‌فرد حمایت کنید.
8. Passwordها را با Argon2id یا الگوریتم مناسب Hash کنید.
9. Rate Limit فقط براساس IP نباشد.
10. Attempts per Account را نیز بررسی کنید.
11. Distinct Accounts per IP را Monitor کنید.
12. Distinct IPs per Account را بررسی کنید.
13. Bot Detection را در Login فعال کنید.
14. CAPTCHA را براساس Risk استفاده کنید.
15. Device جدید را Risk Signal بدانید.
16. Login از Location غیرعادی را بررسی کنید.
17. IP Reputation را فقط به‌عنوان Signal استفاده کنید.
18. MFA Step-Up برای Login مشکوک فعال کنید.
19. برای عملیات حساس Re-authentication بخواهید.
20. MFA Reset را به‌درستی ایمن کنید.
21. Password Recovery را ضعیف‌تر از Login طراحی نکنید.
22. Username Enumeration را کاهش دهید.
23. Error Messageهای Login را عمومی نگه دارید.
24. تمام Login Endpointها را Inventory کنید.
25. Mobile API را فراموش نکنید.
26. Legacy Authentication API را حذف یا ایمن کنید.
27. OAuth Flowها را Audit کنید.
28. Web Login و API Policy یکسان داشته باشند.
29. Login Failureها را Log کنید.
30. Successful Login غیرعادی را نیز Log کنید.
31. Password و OTP را هرگز Log نکنید.
32. Alert برای تغییر Password بعد از Login مشکوک ایجاد کنید.
33. تغییر Email را Monitor کنید.
34. تغییر MFA را Event حساس بدانید.
35. Session Revocation داشته باشید.
36. گزینه Sign Out All Devices ارائه کنید.
37. Login Notification ارسال کنید.
38. User بتواند Login ناشناس را Report کند.
39. WAF و CDN را Defense تکمیلی بدانید.
40. Metricهای Attack Volume داشته باشید.
41. False Positiveها را اندازه‌گیری کنید.
42. Abuse Detection را مرتب Tune کنید.
43. Threat Model ورود را مستندسازی کنید.
44. Authentication Flow را Penetration Test کنید.
45. Recovery Flow را جداگانه تست کنید.
46. Dependencyهای Identity System را به‌روز کنید.
47. Admin Login را روی Policy سخت‌گیرانه‌تر قرار دهید.
48. Incident Response برای Account Takeover داشته باشید.
49. Userهای دارای Password افشاشده را مجبور به انتخاب Secret جدید کنید.
50. در طراحی بلندمدت به سمت Authentication بدون Password حرکت کنید.

اگر Credential Stuffing شناسایی شد چه کنیم؟

اولین اقدام نباید فقط Block کردن چند IP باشد.

Incident باید از چند زاویه بررسی شود.

حمله را محدود کنید

Rate Limit و Bot Protection را تقویت کنید.

Credentialهای موفق را پیدا کنید

بررسی کنید کدام Loginها در Window حمله موفق بوده‌اند.

Sessionها را بررسی کنید

Session مربوط به Loginهای مشکوک ممکن است نیازمند Revocation باشد.

حساب‌های آسیب‌دیده را محافظت کنید

ممکن است Password Reset و MFA Enrollment لازم باشد.

User را مطلع کنید

User باید بداند چرا اقدام امنیتی انجام شده است.

Post-login Activity را بررسی کنید

Login موفق ممکن است به:

• تغییر Email
• تغییر Password
• Data Export
• Transaction
• API Key Creation

منجر شده باشد.

Ruleها را اصلاح کنید

Incident باید باعث بهبود Detection شود.

آیا باید تمام Userها را مجبور به Reset Password کنیم؟

نه لزوماً.

Reset سراسری Password هزینه و Risk خاص خودش را دارد.

اگر Incident تنها گروه مشخصی را تحت تأثیر قرار داده است، Response می‌تواند Targeted باشد.

اما اگر شواهد نشان دهد Credential Database خود سرویس افشا شده، شرایط متفاوت است.

Incident Response باید براساس Scope واقعی انجام شود.

چگونه حساب‌های در معرض خطر را اولویت‌بندی کنیم؟

Risk همه حساب‌ها برابر نیست.

اولویت بالا:

Administrator
Finance
Support
Developer
VIP
Account دارای Balance
Account دارای API Key

همچنین Login موفق از Device یا Country جدید اهمیت بیشتری از Failure تصادفی دارد.

Credential Stuffing و Passkey در آینده Authentication

بزرگ‌ترین ضعف Password این است که یک Shared Secret است.

User آن را می‌داند.

Server Verifier مربوط به آن را دارد.

User ممکن است آن را در چند سایت تکرار کند.

Credential ممکن است Phish شود.

اما Passkey مدل را تغییر می‌دهد.

FIDO Authentication از Cryptographic Key Pair استفاده می‌کند و Credential برای Service مربوطه Bind می‌شود. FIDO Alliance این ویژگی را دلیل مقاومت Passkey در برابر Phishing و Credential Stuffing می‌داند.

به همین دلیل در طراحی Authentication جدید باید پرسید:

آیا واقعاً لازم است Password همچنان تنها روش ورود باشد؟

Credential Stuffing در تست امنیت سایت

در Security Assessment باید بدون آسیب‌زدن به کاربران واقعی بررسی شود:

• آیا Login Rate Limit دارد؟
• آیا Account Lockout قابل Abuse است؟
• آیا Username Enumeration وجود دارد؟
• آیا MFA برای حساب حساس فعال است؟
• آیا MFA قابل Bypass است؟
• آیا Recovery Flow ضعیف‌تر است؟
• آیا Legacy Endpoint وجود دارد؟
• آیا API و Web Login Policy یکسان دارند؟
• آیا Password افشاشده هنگام Registration رد می‌شود؟
• آیا Login جدید Notification دارد؟
• آیا Session بعد از Password Change Revoked می‌شود؟
• آیا Anti-Automation فقط Client-Side است؟

تست باید با Test Account و Authorization صریح انجام شود و نباید Credentialهای واقعی افشاشده کاربران روی Production آزمایش شوند.

سؤالات متداول درباره Credential Stuffing

Credential Stuffing چیست؟

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

آیا Credential Stuffing همان Brute Force است؟

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

Password Spraying چه تفاوتی دارد؟

در Password Spraying یک Password رایج روی تعداد زیادی Account امتحان می‌شود. در Credential Stuffing معمولاً برای هر User یک Username/Password Pair از قبل افشاشده وجود دارد.

آیا Password پیچیده مانع Credential Stuffing می‌شود؟

اگر Password منحصربه‌فرد باشد، بسیار مفید است. اما اگر Password پیچیده عیناً در سرویس دیگری استفاده و افشا شده باشد، پیچیدگی آن مانع Replay شدن Credential نمی‌شود.

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

یک راه‌حل واحد وجود ندارد. MFA یا Passkey، جلوگیری از Passwordهای افشاشده، Rate Limiting، Bot Detection، Risk-Based Authentication و Monitoring باید در کنار هم استفاده شوند.

آیا MFA جلوی Credential Stuffing را می‌گیرد؟

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

آیا Passkey بهتر است؟

Passkey از Shared Password استفاده نمی‌کند و براساس Public-Key Cryptography ساخته شده است؛ بنابراین مدل کلاسیک Credential Stuffing مبتنی بر Username/Password برای Login Passkey کاربرد ندارد.

آیا CAPTCHA کافی است؟

خیر. CAPTCHA فقط یکی از لایه‌های Anti-Automation است و می‌تواند Bypass شود یا توسط سرویس‌های انسانی حل شود. بهتر است براساس Risk استفاده شود.

آیا Rate Limiting بر اساس IP کافی است؟

خیر. حمله ممکن است از IPهای متعدد انجام شود. Rate Limit باید در صورت امکان Account، Device، IP، Subnet و Velocity را ترکیب کند.

آیا Account Lockout مفید است؟

بله، اما باید با احتیاط تنظیم شود. Lockout بیش از حد سخت می‌تواند برای Denial of Service علیه User استفاده شود و Credential Stuffing نیز ممکن است Attempt بسیار کمی روی هر Account داشته باشد.

چگونه بفهمیم Password کاربر قبلاً افشا شده است؟

می‌توان هنگام انتخاب یا تغییر Password آن را با Database یا Service مخصوص Breached Password مقایسه کرد. Pwned Passwords یکی از سرویس‌های شناخته‌شده در این زمینه است.

آیا باید Password را برای بررسی به سرویس خارجی بفرستیم؟

نباید Password Plaintext ارسال شود. سرویس‌هایی مانند Pwned Passwords از مدل k-Anonymity پشتیبانی می‌کنند که امکان مقایسه با استفاده از بخشی از Hash را فراهم می‌کند.

آیا تغییر Password هر 90 روز از Credential Stuffing جلوگیری می‌کند؟

تغییر Arbitrary و دوره‌ای Password راهکار اصلی نیست. بهتر است Password منحصربه‌فرد باشد و در صورت وجود شواهد Compromise تغییر کند.

Password Manager مفید است؟

بله. Password Manager به User کمک می‌کند برای هر سرویس Password منحصربه‌فرد داشته باشد و در نتیجه Breach یک سایت به Accountهای دیگر سرایت نکند.

آیا سایت WordPress هم در معرض Credential Stuffing است؟

بله. هر سرویس دارای Username/Password Authentication می‌تواند هدف باشد. برای WordPress خصوصاً MFA مدیران، Rate Limiting و Monitoring Login اهمیت زیادی دارند.

آیا WAF مشکل را حل می‌کند؟

WAF می‌تواند بخشی از Automation را متوقف کند، اما کنترل اصلی نیست. Backend Authentication باید Rate Limit، MFA و Risk Control مستقل داشته باشد.

اگر Password کاربر افشا شده باشد چه کنیم؟

User باید Password جدید و منحصربه‌فرد انتخاب کند، Sessionهای مشکوک بررسی شوند، MFA فعال شود و فعالیت‌های اخیر Account برای Account Takeover بررسی شوند.

آیا Sign Out All Devices مفید است؟

بله. اگر Attacker قبلاً Session معتبر ایجاد کرده باشد، تغییر Password به تنهایی ممکن است Session قدیمی را از بین نبرد. امکان Revocation تمام Sessionها کنترل مهمی است.

Credential Stuffing بیشتر چه حساب‌هایی را تهدید می‌کند؟

تمام حساب‌های Password-Based ممکن است هدف باشند، اما حساب‌های مالی، فروشگاهی، Administrator، Support، API و حساب‌هایی که اطلاعات یا Credit قابل استفاده دارند ارزش بیشتری برای Attacker دارند.

مهم‌ترین اصل طراحی چیست؟

Authentication System باید فرض کند Password صحیح User ممکن است روزی افشا شود. امنیت حساب نباید فقط به محرمانه ماندن Password وابسته باشد.

جمع‌بندی

Credential Stuffing یکی از مهم‌ترین نمونه‌های سوءاستفاده از Password Reuse است.

در این حمله مهاجم الزاماً Password کاربر را حدس نمی‌زند. او Credentialی را که قبلاً در سرویس دیگری افشا شده است روی Application جدید آزمایش می‌کند.

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

دفاع مناسب باید از این فرض شروع شود:

ممکن است Password صحیح User از قبل در اختیار شخص دیگری قرار گرفته باشد.

اگر سیستم فقط این سؤال را بپرسد که:

آیا Password صحیح است؟

در برابر Credential Stuffing دفاع کافی ندارد.

سیستم مدرن باید علاوه بر اعتبار Password بررسی کند:

آیا Login از Device آشناست؟
آیا رفتار شبیه Automation است؟
آیا IP مشکوک است؟
آیا تعداد زیادی Account از همین Source امتحان شده‌اند؟
آیا User MFA دارد؟
آیا این Password قبلاً افشا شده است؟
آیا بعد از Login رفتار Account طبیعی است؟

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

Passkey یک مرحله بنیادی‌تر است.

در Passkey دیگر Shared Password قابل تکرار میان سایت‌ها وجود ندارد و Authentication براساس کلیدهای رمزنگاری انجام می‌شود.

در سیستم‌هایی که همچنان Password دارند، Passwordهای جدید باید با مجموعه Passwordهای رایج یا افشاشده مقایسه شوند. NIST این Blocklist را بخشی از Password Authentication مدرن می‌داند.

Password Manager نیز به User کمک می‌کند برای هر سرویس Credential مستقل داشته باشد.

در سطح زیرساخت، Rate Limiting باید چندبعدی باشد.

IP، Account، Device، Velocity، Location و رفتار کلی Login باید در کنار هم بررسی شوند.

Bot Detection، CAPTCHA و WAF می‌توانند Automation را دشوار کنند، اما هیچ‌کدام جای MFA یا طراحی مناسب Authentication را نمی‌گیرند.

همچنین Successful Login باید همان اندازه Failed Login مورد توجه قرار گیرد.

اگر Credential Stuffing موفق شود، Attacker یک Session قانونی دریافت می‌کند و ممکن است بلافاصله Email، Password، MFA یا اطلاعات مالی را تغییر دهد.

به همین دلیل Post-Login Monitoring، Re-authentication برای عملیات حساس، Login Notification و Session Revocation اهمیت دارند.

در نهایت Credential Stuffing یادآوری می‌کند که Password یک Security Boundary کامل نیست.

یک سیستم مقاوم باید فرض کند Secret می‌تواند افشا شود و لایه‌های دیگری برای محافظت از Account داشته باشد.

هدف امنیت مدرن Authentication این نیست که فقط Password را بررسی کند؛ هدف این است که حتی در صورت افشای Password، تصاحب حساب تا حد ممکن دشوار، قابل تشخیص و قابل مهار باشد.