सीमा तक पहुँचने से पहले अपनी कुंजी के उपयोग पर नज़र रखें
काम के साथ-साथ अपने कोटा हेडर देखते रहने से पता चलता है कि कब सीमा करीब आ रही है, किसी अनुरोध के असल में अस्वीकार होने से काफ़ी पहले।
एक समर्पित धोखाधड़ी पहचान सेवा ज़्यादातर छोटे साइनअप फ़ॉर्म की ज़रूरत से ज़्यादा है। एक सरल जाँच, जो IP पते से मिलने वाले संकेत की तुलना साइनअप फ़ॉर्म के दावे से करती है, अपने आप में साफ़ तौर पर बेमेल कोशिशों का अच्छा-खासा हिस्सा पकड़ लेती है।
GET /v1/ip?ip=198.51.100.200{
"status": "ok",
"ip": "198.51.100.200",
"version": 4,
"found": true,
"country": "Brazil",
"country_code": "BR",
"region": "Sao Paulo",
"city": "Sao Paulo",
"postcode": "01310",
"lat": -23.5505,
"lon": -46.6333,
"timezone": "America/Sao_Paulo",
"asn": 8901,
"org": "Example Cloud Provider"
}अगर साइनअप फ़ॉर्म बिलिंग देश पूछता है और दर्ज किया गया मान IP लुकअप के country_code से मेल नहीं खाता, तो यह अकेले किसी गड़बड़ी का सबूत नहीं है, क्योंकि यात्रा और VPN का उपयोग दोनों आम और वैध हैं। बेमेल को अपने आप अस्वीकार करने के बजाय एक सरल स्कोर में जोड़े गए एक अंक के रूप में लें।
org फ़ील्ड अक्सर बताता है कि पता किसी आवासीय ISP का है या किसी डेटा सेंटर या क्लाउड होस्टिंग प्रोवाइडर का। क्लाउड होस्टिंग नेटवर्क से आने वाला साइनअप, जहाँ से कोई असली व्यक्तिगत ग्राहक शायद ही कभी ब्राउज़ करता हो, किसी पहचाने जा सकने वाले आवासीय ISP से आने वाले साइनअप की तुलना में ज़्यादा स्कोर का हकदार है, हालाँकि यह भी अपने आप में स्वचालित अस्वीकृति का कारण नहीं है।
अगर आपने देखा है कि कुछ खास ASN मान दुरुपयोग वाले साइनअप के आसपास बार-बार दिखते हैं, तो उन खास asn नंबरों की एक छोटी सूची रखना और जब भी कोई नया साइनअप उनमें से किसी से मेल खाए तो एक तय स्कोर जोड़ना आगे के लिए उस पैटर्न को दर्ज करने का हल्का तरीका है, और इतने सीमित दायरे की जाँच के लिए किसी पूरे थर्ड-पार्टी ASN प्रतिष्ठा डेटाबेस की ज़रूरत नहीं पड़ती।
if ip_info["asn"] in known_abuse_asns:
score += 2कुछ सरल जाँचों को जोड़कर एक संख्यात्मक स्कोर बनाएँ: देश का मेल न खाना, होस्टिंग नेटवर्क से आना, और आपके अपने साइनअप फ़्लो से जुड़ी कोई और खास बात। आपके तय किए गए थ्रेशोल्ड से ऊपर की किसी भी चीज़ को सीधे ब्लॉक करने के बजाय मैन्युअल समीक्षा या ईमेल पुष्टि जैसे अतिरिक्त सत्यापन चरण पर भेजें।
बिना किसी दूसरे संदर्भ के हर VPN या होस्टिंग रेंज वाले साइनअप को अपने आप उच्च जोखिम वाला स्कोर न करें। बहुत से वैध ग्राहक ऐसे कंपनी नेटवर्क से ब्राउज़ करते हैं जो संयोग से किसी डेटा सेंटर IP रेंज से रूट होता है, या ऐसे VPN से जिसका उपयोग वे पूरी तरह सामान्य गोपनीयता कारणों से करते हैं। नेटवर्क के प्रकार को एक अकेले अयोग्य ठहराने वाले फ़्लैग के बजाय कई संकेतों में से एक के रूप में तौलने से यह जाँच किसी गलत पॉज़िटिव के कारण असली ग्राहकों को लौटाने से बचती है।
एक साझा ऑफ़िस नेटवर्क या किसी बड़े मोबाइल ऑपरेटर का carrier-grade NAT कम समय में कई असंबंधित, वैध साइनअप को एक ही IP पते के पीछे रख सकता है। अगर आप अपनी जाँच के हिस्से के रूप में प्रति IP साइनअप की संख्या भी ट्रैक कर रहे हैं, तो उस सीमा को इतना उदार रखें कि इसकी गुंजाइश रहे, या इसे अपने आप में एक नियम मानने के बजाय देश और नेटवर्क संकेतों के साथ मिलाकर देखें।
इस तरह की जाँच का मकसद साफ़ तौर पर कम मेहनत वाले दुरुपयोग को पकड़ना है, न कि किसी ऐसे व्यवसाय के लिए असली धोखाधड़ी रोकथाम सिस्टम की जगह लेना जहाँ धोखाधड़ी से होने वाला नुकसान एक गंभीर चिंता है। इसे पहला फ़िल्टर मानें, अंतिम फ़ैसला नहीं।
हर साइनअप प्रयास पर एक लुकअप यानी एक अनुरोध। सामान्य मात्रा में, लगातार साइनअप पाने वाला फ़ॉर्म भी हर कुंजी के साथ शामिल 2,500 प्रतिदिन मुफ़्त अनुरोधों के भीतर आराम से रहता है। X-Quota-Used और X-Quota-Free-Remaining रिस्पॉन्स हेडर यह देखने का आसान तरीका हैं कि साइनअप प्रयासों में अचानक आई तेज़ी उस कोटा का कितना हिस्सा खर्च कर रही है।
IP से मिले कुछ संकेतों से बना एक हल्का स्कोर कुछ न करने से ज़्यादा पकड़ता है, और इसके लिए किसी समर्पित धोखाधड़ी प्लेटफ़ॉर्म का बोझ भी नहीं उठाना पड़ता। IPv4 लुकअप दस्तावेज़ में इस तरह की जाँच के लिए उपलब्ध हर फ़ील्ड की सूची है।