SaaS credential-stuffing रोकथाम और login abuse guide
Credential stuffing से SaaS accounts बचाने के लिए passkeys या MFA, account-aware throttling, risk-based challenges और secure recovery अपनाएँ।
इस मार्गदर्शिका में
Credential stuffing क्या है और SaaS team इसे कैसे घटाए?
Credential stuffing में attacker पहले कहीं और leak हुए username-password pairs को आपके login या recovery endpoints पर automated ढंग से आजमाता है। वह हर password नए सिरे से guess नहीं करता, बल्कि password reuse का फायदा उठाता है। Reused credentials का मूल्य MFA या passkeys से घटाएँ, account-aware और risk signals से attempts rate-limit करें, account enumeration से बचें और reset व token flows को भी login जितनी सुरक्षा दें। कोई अकेला IP block या CAPTCHA distributed campaign को भरोसेमंद रूप से नहीं रोकता।
Strong MFA या passkeys दें और sensitive बदलाव से पहले फिर authenticate करें
Product और customer base समर्थन करें तो passkeys जैसे phishing-resistant authentication दें; अधिक जोखिम वाले accounts या actions पर MFA रखें। Recovery detail, security factor, ownership या privileged access बदलने से पहले fresh authentication माँगें। Recovery को उपयोगी और सुरक्षित रखें ताकि कमजोर reset flow से attacker MFA bypass न कर सके।
Distributed attempts के लिए account-aware throttling और signals जोड़ें
Login और recovery पर सामान्य read APIs से सख्त limits रखें। Account पर failed attempts के साथ IP, device या network signals देखें; progressive wait period या risk-based step-up पर विचार करें। केवल per-IP limit distributed attack चूकती है; एक hard lockout known user को service से वंचित करने देता है।
Generic authentication errors दें और recovery endpoint भी सुरक्षित रखें
Response wording या स्पष्ट timing से यह उजागर न करें कि account मौजूद है, disabled है या password गलत था। Login के साथ password reset, one-time code, MFA challenge और token issuance पर भी abuse controls रखें। Password या bearer credential URL में न रखें और logs या analytics में leak न होने दें।
| Authentication endpoint | Account-aware limit और risk signals | Step-up/recovery control | Enumeration और lockout test | Metric, owner और escalation |
|---|---|---|---|---|
| Password login | ||||
| MFA या passkey challenge | ||||
| Password reset या token issuance |
Login-abuse defenses सुरक्षा और access में संतुलन कैसे रखें?
भंगुर global block के बजाय progressive controls रखें
Risk बढ़े तो वैध account को deny करने से पहले attempts धीमे करें, step-up factor माँगें या accessible challenge दें। Privacy commitments और user context के अनुरूप signals चुनें; केवल नई location या device fraud का प्रमाण नहीं है। Unaunthenticated caller को account existence बताए बिना अस्थायी wait की साफ जानकारी दें।
नए और reset passwords को compromised-password blocklist से जाँचें
User नया या reset password चुने तो उसे सामान्य या ज्ञात compromised secrets की उपयुक्त blocklist से मिलाएँ और दूसरा password चुनने का कारण बताएँ। Arbitrary composition rules से credential reuse हल करने की कोशिश न करें। Password को adaptive hash में store करें; matching के लिए plaintext copy कभी न रखें।
Failed attempts के साथ संदिग्ध सफल login भी पहचानें
असामान्य success rate, नए device या network, parallel sign-in, login के बाद reset attempts और जल्दी किए गए sensitive actions देखें। Trusted channel से user को notify करें और secret भेजे बिना session review या revocation दें।
Credential-stuffing controls काम कर रहे हैं या नहीं, कैसे मापें?
Distributed, धीमे और account-enumeration cases test करें
Controlled environment में अलग accounts, IPs, devices और request timing बदलकर limits जाँचें। Valid और invalid identifiers के response की तुलना करें और पुष्टि करें कि recovery endpoint account state नहीं बताता। साझा network के सामान्य customers पर limits या challenge का असमान असर न हो।
Security signal के साथ user friction भी monitor करें
Suspicious attempts, unusual sign-in success, MFA completion, challenge pass/fail, lockout, password reset और support contact track करें। Device व location signals कम इकट्ठे करें, retention सीमित रखें और staff access नियंत्रित करें। Threshold reviewed incidents और वैध traffic के आधार पर tune करें, केवल vendor score से नहीं।
Confirmed account takeover का response तैयार रखें
Session व refresh tokens revoke करने, compromised credential reset करने, recovery factors review करने और प्रभावित user को सूचित करने की प्रक्रिया लिखें। Plaintext password रखे बिना जरूरी security evidence बचाएँ। Detection और support मिलकर काम करें, लेकिन unauthenticated व्यक्ति को registered accounts की जानकारी न दें।
Credential-stuffing के सवाल
क्या सफल password login साबित करता है कि व्यक्ति account owner है?
जरूरी नहीं। Reused credentials कहीं और expose हुए हो सकते हैं। MFA या passkeys और risk-aware checks रखें, खासकर sensitive action या unusual sign-in पर।
क्या एक suspicious IP block करने से credential stuffing रुक जाएगा?
आम तौर पर नहीं। Campaign अलग networks से आ सकती है और वास्तविक customers एक IP साझा कर सकते हैं। Account, device और request-pattern signals के साथ सावधानी से limits लगाएँ।
क्या तय failures के बाद account lock कर देना चाहिए?
Hard lock guessing रोक सकता है, पर attacker known user को lock out कर सकता है। मापा हुआ throttling और recovery design अपनाएँ; अपने service और लागू identity requirements का पालन करें, एक universal threshold न कॉपी करें।
क्या login पर CAPTCHA पर्याप्त सुरक्षा है?
नहीं। Challenge संदिग्ध traffic में friction जोड़ सकता है, लेकिन MFA, account-aware throttling, generic errors, सुरक्षित recovery और monitoring का विकल्प नहीं है।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .
- OWASP API Security Top 10: API2:2023 Broken Authentication
- OWASP Authentication Cheat Sheet
- OWASP Credential Stuffing Prevention Cheat Sheet
- OWASP Bot Management and Anti-Automation Cheat Sheet
- NIST SP 800-63B-4: authentication और authenticator management
- OWASP Forgot Password Cheat Sheet
- OWASP Password Storage Cheat Sheet
- OWASP Session Management Cheat Sheet