ऑथेंटिकेशन टेस्टिंग

यह क्यों ज़रूरी है

Authentication सामने का दरवाज़ा है। OWASP Top 10 में authentication failures की अपनी अलग category है (OWASP Top 10 वाले lesson में आप इससे मिल चुके हैं), और कई असली break-ins को किसी चतुर exploit की ज़रूरत नहीं होती: किसी दूसरी site से leak हुआ password, कभी expire न होने वाला reset link, कभी धीमा न होने वाला login। कीमत है account takeover, और उसके साथ आने वाला fraud, data loss और regulatory नुकसान।

Tester के लिए यह एक productive area है: ज़्यादातर checks का साफ़ expected result किसी published guideline में लिखा है, passwords और attempt limits के लिए NIST SP 800-63B में और reset flows व enumeration के लिए OWASP cheat sheets में, और इसका लगभग सब कुछ सिर्फ़ एक browser, एक HTTP client और दो test accounts से हो जाता है। जो चीज़ सच में चाहिए, वह है permission: सिर्फ़ वही systems टेस्ट करें जो आपके हैं या जिन्हें टेस्ट करने की लिखित अनुमति आपके पास है, और testing के लिए बनाए गए accounts से।

एक sign-in attempt, और हर check कहाँ रहता है

एक आम login handler हमेशा वही steps उसी क्रम में चलाता है, और हर step वह जगह है जहाँ tests की एक class रहती है: account ढूँढना, attempt को एक limit के विरुद्ध गिनना, password की तुलना stored hash से करना (hash password का one-way fingerprint है, इसलिए server को password खुद रखने की ज़रूरत नहीं पड़ती), account में second factor हो तो उसे माँगना, और उसके बाद ही session बनाना। Password policy इससे पहले, sign-up और password change पर लागू होती है, और reset flow उसी account का एक side door है।

हर step पर दो सवाल पूछें: क्या check होता भी है, और क्या वह कुछ leak करता है — अलग message, status code या response time — जो attacker को "नहीं" से ज़्यादा बताता है?

Password policy: वह टेस्ट करें जो NIST SP 800-63B माँगता है

NIST SP 800-63B authentication के लिए अमेरिकी federal guideline है, जिसे सरकार के बाहर भी कई organisations अपनाते हैं, और यह कई पुरानी आदतों को उलट देती है। इसका current edition, revision 4 (2025), password के अकेला factor होने पर कम से कम 15 characters ज़रूरी करता है, और password सिर्फ़ second factor के साथ इस्तेमाल हो तो minimum 8 की अनुमति देता है; 2017 edition, जिस पर कई products बने हैं, दोनों के लिए 8 रखता था। Verifier (वह system जो password जाँचता है) को कम से कम 64 characters की अनुमति देनी चाहिए और हर printing ASCII character, space और Unicode accept करना चाहिए; उसे पूरा password जाँचना ज़रूरी है, कभी truncate किया हुआ हिस्सा नहीं, और हर नए password की तुलना commonly used, expected या compromised values की blocklist से करना ज़रूरी है। Revision 4 composition rules ("एक uppercase, एक digit, एक symbol") और compromise के सबूत के बिना forced periodic change को मना करता है, जिनके विरुद्ध 2017 edition पहले से सलाह देता था, और दोनों editions password hints और security questions को मना करते हैं। Password managers और autofill का काम करना ज़रूरी है, paste की अनुमति होनी चाहिए, और user typing के दौरान password दिखा सकना चाहिए।

यही आपका test oracle है, जब team बता दे कि product कौन-सा edition और कौन-सा case मानता है। Length पर boundary value analysis लगाएँ, हर Unicode code point को एक character गिनते हुए, जैसा SP 800-63B कहता है: सिर्फ़ password से सुरक्षित login के लिए 14, 15, 64 और 65, या जब second factor हमेशा ज़रूरी हो तो 14 और 15 की जगह 7 और 8। Spaces वाला एक Arabic या Devanagari password आज़माएँ, और ऐसी values भेजें जो blocklist में होनी चाहिए: minimum तक बढ़ाया गया एक common password, जैसे Password1234567, और उसी तरह बढ़ाया गया product का अपना नाम। फिर storage जाँचें: salt एक random value है जो हर user के साथ रखी जाती है ताकि दो एक जैसे passwords के hash अलग बनें, और Argon2, bcrypt या PBKDF2 जैसा जान-बूझकर slow algorithm table चुराने वाले attacker के लिए हर अंदाज़े को महँगा बना देता है। इसलिए test database की users table में salted hashes होने चाहिए, कभी plain text नहीं, और password logs या URLs में नहीं दिखना चाहिए।

#  Input (password is the only factor)   Expected
1  14 characters                         rejected: fewer than 15
2  15 characters                         accepted, and login works with it
3  64 characters                         accepted, and login works with it
4  65 characters                         rejected with a message, or accepted whole;
                                         never silently truncated
5  Arabic words with spaces              accepted (Unicode and the space)
6  Password1234567, product name padded  rejected: blocklist
7  paste, autofill, show password        all allowed
8  users table in a test database        salted slow hash, not the password

आज़माएँ: पासवर्ड जनरेटर आज़माएँ: स्ट्रिंग लेंथ काउंटर आज़माएँ: Unicode डेटासेट जनरेटर

Lockout, throttling और second factor

Lockout कुछ failed attempts के बाद account का sign-in बंद कर देता है, कुछ समय के लिए या जब तक कोई उसे unlock न करे; throttling इसके बजाय attempts को धीमा करती है: बढ़ता हुआ delay, कुछ failed attempts के बाद CAPTCHA, या हर account और हर source address पर एक limit। SP 800-63B verifier से माँगता है कि एक account पर लगातार failed attempts 100 से ज़्यादा न हो सकें। ऐसा lock जिसे कोई भी victim का e-mail और गलत passwords डालकर trigger कर सके, खुद denial of service के लिए इस्तेमाल हो सकता है, इसलिए दर्ज करें कि lock कैसे हटता है और कितनी देर रहता है।

MFA एक अलग category का check जोड़ती है, आम तौर पर कुछ ऐसा जो user के पास है: authenticator app का one-time code, एक security key, phone पर भेजा code। इस step को अपने आप में एक छोटी authentication की तरह टेस्ट करें: time-based code (TOTP) RFC 6238 के default के अनुसार हर 30 seconds में बदलता है, और 6-digit code की सिर्फ़ दस लाख values हैं, इसलिए step को अपनी attempt limit चाहिए; SP 800-63B यह भी माँगता है कि हर one-time code valid रहते हुए सिर्फ़ एक बार accept हो। वही guideline phone network को restricted channel मानता है, इसलिए SMS से भेजे codes को risk के रूप में दर्ज करें, defect के रूप में नहीं।

• दूसरे test account से गिनें कि throttle या lock trigger होने में कितने गलत passwords लगते हैं, और जाँचें कि counter server पर रहता है: page reload, नया browser session या cookies साफ़ करने से वह reset नहीं होना चाहिए, सिर्फ़ successful sign-in से या documented lock period ख़त्म होने पर।
• Failed attempts हर entry point से दोहराएँ — web form, mobile API, reset page, MFA step। Limit हर जगह लागू रहनी चाहिए, और message से यह पता नहीं चलना चाहिए कि account मौजूद है या नहीं।
• MFA: password step के ठीक बाद बिना code के post-login page या API call करें; वही code दो बार भेजें; कई time steps पहले expire हुआ code आज़माएँ, जो team की documented window से पुराना होते ही fail होना चाहिए (RFC 6238 network delay के लिए ज़्यादा से ज़्यादा एक पिछले time step और clock drift के लिए एक तय limit की सलाह देता है); जाँचें कि recovery codes single-use हैं, "remember this device" expire होता है, और password reset second factor को skip नहीं करता।

आज़माएँ: API रिक्वेस्ट बिल्डर

Worked example: एक shop के login पर reset flow और enumeration

एक shop में login, registration form और "Forgot password" page है। आपके पास दो test accounts हैं, qa.one@example.com और qa.two@example.com, और एक throwaway address जो कभी register नहीं हुआ। तीनों pages पर वही request एक known और एक unknown address के साथ भेजें, हर जोड़ी को पिछले lesson के intercepting proxy या किसी HTTP client से capture करें, और दोनों responses की हर चीज़ compare करें: message, HTTP status, redirect target, body size और लगा समय। नीचे वाली login जोड़ी पहली ही तुलना में fail हो जाती है।

• Login: known address पर 401 और unknown पर 404 user enumeration है। Expected: वही status, वही message और timing में कोई ध्यान देने लायक फ़र्क़ नहीं (unknown account अक्सर जल्दी जवाब देता है, क्योंकि server slow hash comparison छोड़ देता है)।
• Registration: "यह e-mail पहले से registered है" भी enumeration है। कुछ teams इसे usability के लिए स्वीकार करती हैं; विकल्प है हमेशा "अपना inbox देखें" जवाब देना और welcome mail या "आपका account पहले से है" mail भेजना। दर्ज करें कि product ने कौन-सा चुना।
• Forgot password: page को दोनों addresses के लिए एक जैसा जवाब देना चाहिए। फिर उसका e-mail किया token टेस्ट करें: link से नया password set करें और link फिर खोलें (fail होना चाहिए, क्योंकि token इस्तेमाल हो चुका है), expiry के बाद तक इंतज़ार करें, token का एक character बदलें, और दो resets request करके देखें कि पहला link अब भी चलता है या नहीं। Reset page को अपने URL का token Referer header में leak नहीं करना चाहिए, यानी उस header में जिसमें browser बताता है कि request किस page से आई: उसे Referrer-Policy: no-referrer set करना चाहिए, जैसी OWASP Forgot Password Cheat Sheet की सलाह है, ताकि उस page की कोई third-party script, image या link token न पा सके।
• Successful reset के बाद: पुराना password काम करना बंद कर दे, reset से पहले खुले sessions ख़त्म हों (या कम से कम user को उन्हें ख़त्म करने का विकल्प मिले), और user को सूचना मिले कि password बदला गया।

# Known test account, wrong password
POST /api/login HTTP/1.1
Host: staging.shop.example
Content-Type: application/json

{"email": "qa.one@example.com", "password": "Not-the-password-1"}

HTTP/1.1 401 Unauthorized
{"error": "Invalid e-mail or password"}

# Same request, an address that never registered
POST /api/login HTTP/1.1
Host: staging.shop.example
Content-Type: application/json

{"email": "never.registered@example.com", "password": "Not-the-password-1"}

HTTP/1.1 404 Not Found
{"error": "No account for this e-mail"}

आज़माएँ: API रिस्पॉन्स कम्पेरेटर आज़माएँ: अस्थायी ईमेल

अक्सर पूछे जाने वाले सवाल

संदर्भ

• NIST SP 800-63B: Digital Identity Guidelines — Authentication and Lifecycle ManagementNIST · 2017पासवर्ड और ऑथेंटिकेटर की आवश्यकताएँ: जटिलता नियमों से ज़्यादा लंबाई, लीक हुए पासवर्ड की ब्लॉकलिस्ट, रेट लिमिटिंग, ज़बरन रोटेशन नहीं।
• OWASP Cheat Sheet Series: AuthenticationOWASP Foundationऑथेंटिकेशन नियंत्रण: सामान्य एरर मैसेज, लॉकआउट और थ्रॉटलिंग, MFA, क्रेडेंशियल रिकवरी।
• OWASP Web Security Testing Guide (WSTG)OWASP Foundationवेब एप्लिकेशन और API की सुरक्षा कमज़ोरियों को परखने की संदर्भ कार्यप्रणाली, एक-एक टेस्ट के रूप में।
• OWASP Cheat Sheet Series: Password StorageOWASP Foundationपासवर्ड कैसे स्टोर करें: Argon2id, scrypt या bcrypt सॉल्ट के साथ — कभी MD5, SHA-1 या बिना सॉल्ट के हैश नहीं।