एज पर ही Credential Stuffing को रोकना

Credential stuffing

हमले चुराए गए username और password संयोजनों को लॉगिन पेजों के विरुद्ध परखने के लिए स्वचालित उपकरणों का उपयोग करते हैं। ये हमले बड़े पैमाने के होते हैं — एक ही ऑपरेटर सैकड़ों लक्षित साइटों पर प्रतिदिन लाखों credential परख सकता है। rate limiting और CAPTCHA जैसी पारंपरिक सुरक्षा अपर्याप्त हैं क्योंकि हमलावर अपने अनुरोधों को हज़ारों IP पतों में बाँट देते हैं और CAPTCHA हल करने वाली सेवाओं का उपयोग करते हैं। यहाँ बताया गया है कि हम credential stuffing को एज पर कैसे रोकते हैं, इससे पहले कि अनुरोध आपके authentication सिस्टम तक पहुँचें।

हमले की सतह

एक सामान्य credential stuffing ऑपरेशन चुराए गए credential की सूची (dark web मार्केटप्लेस पर प्रति दस लाख रिकॉर्ड मात्र $10 में उपलब्ध), एक automation उपकरण (आमतौर पर एक कस्टम स्क्रिप्ट या OpenBullet जैसा उपकरण), और proxy IP का एक pool (residential proxy जो हर अनुरोध पर घूमते हैं ताकि IP-आधारित rate limiting से बचा जा सके) का उपयोग करता है।

हमलावर अपने उपकरण को एक नियंत्रित दर पर लॉगिन अनुरोध भेजने के लिए कॉन्फ़िगर करता है — इतना धीमा कि साधारण rate limit ट्रिगर न हो, पर इतना तेज़ कि प्रति घंटे हज़ारों credential परखे जा सकें। हर अनुरोध एक अलग IP पते से, एक अलग user agent स्ट्रिंग के साथ आता है, जिससे यह अलग-अलग उपयोगकर्ताओं के वैध लॉगिन प्रयासों की धारा जैसा दिखता है।

Rate Limiting क्यों विफल होती है

IP-आधारित rate limiting रक्षा की पहली पंक्ति है जिसे अधिकांश टीमें तैनात करती हैं, और यही सबसे पहले विफल होती है। residential proxy सेवाएँ लाखों असली IP पतों तक पहुँच देती हैं — घरेलू राउटर, मोबाइल डिवाइस, और IoT डिवाइस — जो हर अनुरोध पर घूमते हैं। सर्वर के नज़रिए से, हर लॉगिन प्रयास एक अनूठे residential IP से आता है जिसका दुरुपयोग का कोई इतिहास नहीं है।

Account-आधारित rate limiting (प्रति username लॉगिन प्रयासों को सीमित करना) अधिक प्रभावी है पर यह denial-of-service का रास्ता बनाती है: एक हमलावर किसी वैध उपयोगकर्ता के username के विरुद्ध जान-बूझकर कई असफल लॉगिन प्रयास करके उन्हें लॉक कर सकता है।

आधार के रूप में Device Fingerprinting

Device fingerprinting समीकरण बदल देती है क्योंकि यह हमला चलाने वाले device को पहचानती है, न कि उस IP को जिसे वह उपयोग कर रहा है। एक ही मशीन या VM फ़ार्म पर चलने वाला credential stuffing उपकरण अपने सभी अनुरोधों में एक जैसा device fingerprint उत्पन्न करता है, चाहे वह किसी भी proxy IP से होकर घूमे।

हमारा Bot Detection इंजन automation उपकरणों को स्वयं पहचानता है। Selenium navigator.webdriver आर्टिफ़ैक्ट छोड़ता है। Puppeteer और Playwright की विशिष्ट JavaScript रनटाइम विशेषताएँ होती हैं। Headless Chrome में कुछ विशेष browser API नहीं होते जो headed Chrome में होते हैं। यहाँ तक कि JavaScript न चलाने वाले कस्टम HTTP क्लाइंट भी TLS fingerprinting के जरिए पकड़ लिए जाते हैं — उनके Client Hello संदेश अंतर्निहित HTTP लाइब्रेरी को उजागर कर देते हैं।

Device के अनुसार Velocity Tracking

एक बार जब हमारे पास एक स्थिर device पहचानकर्ता हो जाता है (Device Identification के जरिए), तो हम velocity जाँच IP स्तर के बजाय device स्तर पर लागू कर सकते हैं। यदि एक ही device 5 मिनट में 50 लॉगिन का प्रयास करता है — चाहे वे अनुरोध कितने ही अलग IP से आए हों — तो पैटर्न स्पष्ट रूप से credential stuffing है।

हमारा IP Intelligence मॉड्यूल तीन समय-window में velocity को ट्रैक करता है: 5 मिनट, 1 घंटा, और 24 घंटे। यह बहु-window दृष्टिकोण आक्रामक हमलों (प्रति मिनट सैकड़ों प्रयास) और धीमे-कम हमलों (कई दिनों तक बनाए रखे गए प्रति घंटे कुछ प्रयास) दोनों को पकड़ता है।

Behavioral Signal विश्लेषण

bot detection और velocity tracking से आगे, हमारा Smart Signals विश्लेषण उन behavioral संकेतों की जाँच करता है जो स्वचालित हमलों को वैध लॉगिन से अलग करते हैं। असली उपयोगकर्ता अनुरोध के समय, टाइपिंग गति, और नेविगेशन पैटर्न में स्वाभाविक भिन्नता दिखाते हैं। स्वचालित उपकरण यांत्रिक रूप से एक जैसा समय, समान अनुरोध हेडर, और कोई माउस मूवमेंट या स्क्रॉल इवेंट न होना उत्पन्न करते हैं।

हम उन signal विसंगतियों की भी जाँच करते हैं जो environmental spoofing का संकेत देती हैं। macOS पर Chrome होने का दावा करने वाला पर Linux VM से जुड़े WebGL पैरामीटर प्रस्तुत करने वाला browser तुरंत फ़्लैग कर दिया जाता है। ऐसा user agent स्ट्रिंग जो TLS fingerprint से मेल नहीं खाता, tampering अलर्ट ट्रिगर करता है।

एज तैनाती

credential stuffing को रोकने की कुंजी इसे आपके authentication सिस्टम तक पहुँचने से पहले रोकना है। हमारा एजेंट लॉगिन पेज पर लोड होता है और पेज लोड के दौरान संकेत एकत्र करता है — इससे पहले कि उपयोगकर्ता (या बॉट) credential सबमिट करे। लॉगिन फ़ॉर्म सबमिट होने तक fingerprint और bot detection के परिणाम उपलब्ध हो जाते हैं, जिससे आपका सर्वर स्वचालित प्रयासों को तुरंत अस्वीकार कर सकता है।

उच्च-मात्रा वाले लक्ष्यों के लिए, हम अपने Cloudflare Worker या CloudFront Lambda@Edge इंटीग्रेशन को तैनात करने की सलाह देते हैं, जो fingerprint validation को CDN एज पर चलाता है। इसका अर्थ है कि credential stuffing अनुरोध हमलावर के सबसे नज़दीकी एज नोड पर ही ब्लॉक हो जाते हैं, आपके origin सर्वर तक कभी नहीं पहुँचते।

परिणाम

हमारे ग्राहक अपने लॉगिन पेजों पर tracio.ai तैनात करने के बाद credential stuffing की मात्रा में 99% कमी बताते हैं। बचे हुए 1% में अत्यधिक परिष्कृत हमले शामिल हैं जो सावधानी से spoof किए गए संकेतों के साथ पूर्ण browser automation का उपयोग करते हैं — जिन्हें हमारी बहु-विधि पहचान velocity पैटर्न उभरते ही पहले कुछ दर्जन अनुरोधों के भीतर पकड़ लेती है।