ब्लॉकलिस्ट प्रसार: एक पुष्ट दुरुपयोग मामले से पूरे नेटवर्क को खत्म करना (HI)

एक विशिष्ट क्षण होता है जहाँ अधिकांश दुरुपयोग कार्यक्रम मूल्य खो देते हैं: वह क्षण जब आप जीत जाते हैं।

आपकी ट्रैफ़िक परत एक खाते को फ़्लैग करती है। एक विश्लेषक जाँच करता है। सबूत ठोस हैं, मामला पुष्ट है, खाते पर प्रतिबंध लगा दिया गया है। और फिर, घंटों बाद, वही ऑपरेटर नए खातों पर वापस आ जाता है, क्योंकि आपके प्रवर्तन ने केवल उपयोगकर्ताओं की तालिका में एक पंक्ति को छुआ था।

एंथ्रोपिक ने फरवरी 2026 की अपनी रिपोर्ट में डिस्टिलेशन अभियानों में ठीक इसी गतिशीलता का वर्णन किया — एक प्रॉक्सी नेटवर्क जिसने "एक साथ 20,000 से अधिक धोखाधड़ी वाले खातों का प्रबंधन किया," उन्हें हटाए जाने पर बदल दिया। हटाना बाधा नहीं था। पुनर्जनन हटाने से सस्ता था।

इसका समाधान यह है कि प्रवर्तन खातों के बजाय पहचानकर्ताओं पर काम करे। Didit का सूचियाँ API एक ऐसे मैकेनिक के इर्द-गिर्द बनाया गया है जो एक ही कॉल में यह काम करता है।

मुख्य निष्कर्ष

• reference_session_id के साथ ब्लॉकलिस्टिंग करने से Didit सत्र से सही मूल्य स्वतः निकाल लेता है — चेहरा, दस्तावेज़, फ़ोन, ईमेल, आईपी या डिवाइस — अंतर्निहित मॉडल को ब्लॉकलिस्टेड चिह्नित करता है, और प्रविष्टि को स्रोत सत्र से लिंक करता है।
• 12 प्रविष्टि प्रकार: face, document, phone, email, ip_address, device_fingerprint, wallet_address, bank_account, user, business, country, key।
• ब्लॉकलिस्ट सिस्टम-निर्मित, प्रति प्रविष्टि प्रकार एक, और अपरिवर्तनीय होते हैं। आप उन्हें बना नहीं सकते, जिससे प्रवर्तन एक समान होता है।
• प्रविष्टियाँ सत्यापन के समय तुरंत प्रभावी होती हैं। एक प्रविष्टि को हटाने से मिलान अनब्लॉक हो जाता है।
• ip_address एक CIDR रेंज स्वीकार करता है, ताकि आप एक एकल पते के बजाय बुनियादी ढांचे को ब्लॉकलिस्ट कर सकें।
• वही 12 प्रकारों में अनुमति सूचियाँ विश्वसनीय डेवलपर्स को हर वृद्धि पथ से बाहर रखती हैं।

दो सूची प्रकार जो मायने रखते हैं

एपीआई में तीन सूची प्रकार हैं, और उनके बीच का अंतर जानबूझकर है।

ब्लॉकलिस्ट सिस्टम-निर्मित होते हैं — प्रति प्रविष्टि प्रकार एक — और अपरिवर्तनीय होते हैं। आप उन्हें बना नहीं सकते, उनका नाम बदल नहीं सकते, या उन्हें हटा नहीं सकते। आप प्रविष्टियाँ जोड़ते और हटाते हैं। यह बाधा एक विशेषता है: इसका मतलब है कि "ब्लॉकलिस्टेड" का आपकी संस्था में ठीक एक ही अर्थ है, और चार प्रतिस्पर्धी चेहरा ब्लॉकलिस्ट के साथ समाप्त होने का कोई तरीका नहीं है जिनकी विभिन्न सेवाएँ असंगत रूप से जाँच करती हैं।

अनुमति सूचियाँ आप स्वयं बना सकते हैं। ज्ञात-अच्छे डिवाइस, पता रेंज, व्यावसायिक संस्थाएँ और उपयोगकर्ता यहाँ जाते हैं।

कस्टम सूचियाँ बाकी सब के लिए हैं — आपकी अपनी वर्गीकरण, निगरानी समूह, समीक्षा समूह।

# चेहरा ब्लॉकलिस्ट ढूँढें
curl -X GET 'https://verification.didit.me/v3/lists/?list_type=blocklist&entry_type=face' \
  -H 'x-api-key: YOUR_API_KEY'

वह मैकेनिक जो मायने रखता है

कुछ ब्लॉकलिस्ट करने का सामान्य तरीका यहाँ दिया गया है, और यह लगभग हर वास्तविक स्थिति में गलत तरीका है:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "value": "203.0.113.44" }'

वह एक पते को ब्लॉकलिस्ट करता है। इस बीच जिस सत्र की आप जाँच कर रहे थे उसमें एक चेहरा, एक दस्तावेज़ संख्या, एक फ़ोन, एक ईमेल और एक डिवाइस फ़िंगरप्रिंट भी था — उनमें से हर एक एक पहचानकर्ता है जिसे ऑपरेटर को वापस आने से पहले बदलना होगा।

बेहतर कॉल:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "reference_session_id": "a7f3...c19" }'

reference_session_id पास करें और Didit उस सूची के प्रविष्टि प्रकार के लिए सही मान स्वतः निकाल लेता है सत्र से, अंतर्निहित मॉडल को ब्लॉकलिस्टेड के रूप में चिह्नित करता है, और प्रविष्टि को सत्र से लिंक करता है ताकि कंसोल आपको दिखा सके कि यह कहाँ से आया है।

इससे तीन बातें निकलती हैं, और तीनों ही परिचालन रूप से मायने रखती हैं:

कोई मैन्युअल निष्कर्षण नहीं। आपका विश्लेषक स्क्रीन से डिवाइस फ़िंगरप्रिंट नहीं पढ़ता और उसे दोबारा टाइप नहीं करता। प्रवर्तन डेटा में प्रतिलेखन त्रुटियाँ मौन विफलताएँ होती हैं — प्रतिबंध बस सक्रिय नहीं होता, और कोई भी पता नहीं लगाता।

उत्पत्ति संरक्षित है। प्रत्येक प्रविष्टि उस सत्र से जुड़ी होती है जिसने इसे उचित ठहराया था। जब कोई चार महीने बाद पूछता है कि यह डिवाइस क्यों अवरुद्ध है, तो जवाब एक क्लिक है, कोई पुरातत्व परियोजना नहीं।

प्रवर्तन दोहराने योग्य है। प्रत्येक प्रविष्टि-प्रकार ब्लॉकलिस्ट के विरुद्ध वही कॉल सत्र की पूरी पहचानकर्ता सतह को कवर करती है।

यदि किसी सत्र में एक ही प्रकार की कई घटनाएँ हैं, तो अस्पष्टता दूर करने के लिए reference_session_id के साथ value पास करें।

आप सत्यापन सत्र के बाहर से भी प्रवर्तन कर सकते हैं। reference_object_uuid के साथ metadata.reference_type — transaction, vendor_user या vendor_business — एक लेनदेन या एक विक्रेता उपयोगकर्ता या व्यवसाय से ब्लॉकलिस्ट करता है, और स्रोत से वही लिंक रखता है।

12 प्रविष्टि प्रकार

प्रविष्टि प्रकार	ब्लॉक	नोट्स
face	व्यक्ति	सीधे फेस-अपलोड के माध्यम से भी लोड किया जा सकता है
document	क्रेडेंशियल
phone	नंबर	E.164 में स्वतः सामान्यीकृत
email	पता
ip_address	पता या रेंज	CIDR स्वीकार करता है, उदा. 10.0.0.0/8
device_fingerprint	मशीन	न्यूनतम 8 अल्फ़ान्यूमेरिक वर्ण
wallet_address	ऑन-चेन पता
bank_account	खाता
user	उपयोगकर्ता रिकॉर्ड
business	संस्था
country	अधिकार क्षेत्र
key	एक कस्टम कुंजी

इस समस्या के लिए दो पर ध्यान देना महत्वपूर्ण है।

ip_address एक CIDR रेंज स्वीकार करता है। 203.0.113.0/24 को ब्लॉकलिस्ट करने से बुनियादी ढाँचा ब्लॉक होता है, न कि एक पता। जब एक फ़ार्मिंग ऑपरेशन किराए के सबनेट पर चलता है, तो यह प्रवर्तन के बीच का अंतर है जो स्केल करता है और प्रवर्तन जो व्हैक-ए-मोल खेलता है। इसका सावधानी से उपयोग करें — एक रेंज वास्तविक उपयोगकर्ताओं को भी कवर करती है, और बहुत व्यापक रेंज से आप चुपचाप किसी देश के मोबाइल कैरियर पर प्रतिबंध लगा सकते हैं।

face सीधे अपलोड का समर्थन करता है। जब आपके पास एक छवि हो लेकिन कोई सत्र न हो, तो उसे सीधे लोड करें:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/face-upload/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "image": "<base64-encoded image>" }'

Didit बायोमेट्रिक निकालता है। तब से, वह चेहरा हर सत्यापन पर स्क्रीनिंग किया जाता है।

एक प्रविष्टि के आने के बाद क्या होता है

सिस्टम ब्लॉकलिस्ट में जोड़ने से भविष्य के मिलान सत्यापन के समय तुरंत अवरुद्ध हो जाते हैं। कोई प्रसार विलंब और कोई बैच कार्य नहीं होता है।

अगले सत्यापन पर, प्रवर्तन चेतावनियों के रूप में सामने आता है:

• FACE_IN_BLOCKLIST — निश्चित मिलान, सत्यापन अस्वीकृत। POSSIBLE_FACE_IN_BLOCKLIST हार्ड थ्रेशोल्ड से नीचे एक सीमा रेखा मिलान है और इसे समीक्षा के लिए निर्देशित किया जाना चाहिए, अस्वीकृत नहीं।
• IP_ADDRESS_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_BLOCKLIST — नेटवर्क और डिवाइस हिट।

फेस सर्च में, एक ब्लॉकलिस्ट मिलान एकमात्र ऐसी चीज है जो status को "Declined" पर सेट करती है। प्रतिक्रिया में प्रत्येक मिलान में is_blocklisted भी होता है, इसलिए एक जांच आपको तुरंत दिखाती है कि किसी क्लस्टर के कौन से हिस्से पहले से ही प्रवर्तन के अधीन हैं और कौन से अभी भी सक्रिय हैं।

हटाना सममित है: एक प्रविष्टि को हटाने से मिलान करने वाली इकाई अनब्लॉक हो जाती है। प्रवर्तन डिज़ाइन द्वारा प्रतिवर्ती है, जो मायने रखता है क्योंकि बहुत व्यापक प्रवर्तन एक वास्तविक जोखिम है और आपको वापस आने के लिए एक स्वच्छ मार्ग की आवश्यकता है।

curl -X DELETE 'https://verification.didit.me/v3/lists/{list_uuid}/entries/{entry_uuid}/' \
  -H 'x-api-key: YOUR_API_KEY'

अनुमति सूचियाँ: उन डेवलपर्स की सुरक्षा करना जिन्हें आप चाहते हैं

प्रवर्तन जो केवल बढ़ता है, अंततः उत्पाद का गला घोंट देता है। वही 12 प्रविष्टि प्रकार अनुमति सूचियों का समर्थन करते हैं, और वे दबाव वाल्व हैं।

एक डिज़ाइन पार्टनर के कार्यालय आईपी रेंज को अनुमति दें। एक एंटरप्राइज़ ग्राहक की इंजीनियरिंग टीम के उपकरणों को अनुमति दें। एक सत्यापित व्यावसायिक इकाई को अनुमति दें ताकि उसके उपयोगकर्ता कभी भी वृद्धि पथ पर न आएं। IP_ADDRESS_IN_ALLOWLIST और DEVICE_FINGERPRINT_IN_ALLOWLIST तब सक्रिय होते हैं जब कोई मिलान होता है, ताकि आप पुष्टि कर सकें कि छूट लागू हुई है, यह मानकर नहीं कि ऐसा हुआ है।

यह वह तंत्र है जो आक्रामक प्रवर्तन को जीवित रहने योग्य बनाता है। आप अज्ञात बुनियादी ढांचे पर एक सख्त नीति का खर्च उठा सकते हैं क्योंकि आपकी ज्ञात-अच्छी आबादी स्पष्ट रूप से अलग की गई है।

संभालने लायक त्रुटियाँ

• 400 — मान प्रविष्टि प्रकार के सत्यापनकर्ता में विफल रहा, ऑपरेशन के लिए list_type गलत है (उदाहरण के लिए, एक गैर-चेहरा सूची के विरुद्ध एक फेस-अपलोड), या reference_session_id में अनुरोधित प्रकार का कोई डेटा नहीं है। वह अंतिम मामला सामान्य और सौम्य है: हर सत्र हर पहचानकर्ता को कैप्चर नहीं करता है।
• 403 — {"detail": "आपको यह कार्रवाई करने की अनुमति नहीं है।"}

ध्यान दें कि "सत्र में उस प्रकार का कोई डेटा नहीं है" से 400 अपेक्षित है जब आप सभी प्रविष्टि-प्रकार ब्लॉकलिस्टों में एक सत्र को लूप करते हैं। इसे विफलता के बजाय एक छोड़ के रूप में संभालें।

एक कार्यशील प्रवर्तन प्रवाह

एक विश्लेषक ने खाता acct_8842 पर दुरुपयोग की पुष्टि की है।

1. पहले क्लस्टर को हल करें। सत्र के चेहरे पर फेस सर्च बारह खाते लौटाता है; डिवाइस और आईपी सहसंबंध एक दर्जन और खींचता है। समाधान से पहले प्रवर्तन एक खाते पर प्रतिबंध लगाता है और ऑपरेटर को चेतावनी देता है।
2. पुष्ट सत्र से ब्लॉकलिस्ट करें — चेहरा, डिवाइस, आईपी, ईमेल, फोन और दस्तावेज़ ब्लॉकलिस्ट के विरुद्ध reference_session_id। छह कॉल, कोई मैन्युअल निष्कर्षण नहीं, पूर्ण उत्पत्ति।
3. रेंज पर विचार करें। यदि नेटवर्क साक्ष्य किराए के बुनियादी ढांचे की ओर इशारा करता है, तो एक CIDR प्रविष्टि सबनेट को कवर करती है। पहले जाँचें कि वहाँ और क्या रहता है।
4. अपने स्वयं की नीति के अनुसार क्लस्टर पर कार्य करें — जिन खातों की आपने पहले ही पहचान कर ली है, वे स्वयं को अन-बैन नहीं करते हैं।
5. प्रवर्तन को सत्यापित करें। फेस सर्च को फिर से चलाएँ। मिलान में अब is_blocklisted: true होना चाहिए।
6. पुनर्जनन प्रयास की प्रतीक्षा करें। उस चेहरे, डिवाइस या सबनेट पर बनाया गया अगला खाता सत्यापन में अस्वीकृत हो जाता है बजाय इसके कि तीन सप्ताह बाद आपके ट्रैफ़िक में दिखाई दे।

चरण 6 ही पूरा मुद्दा है। ऑपरेटर के वापस आने की लागत अब "एक नया ईमेल पता बनाना" नहीं है। यह "नया हार्डवेयर, नया नेटवर्क और एक नया व्यक्ति प्राप्त करना" है।

उपयोग के मामले

एआई एपीआई प्लेटफ़ॉर्म एक पुष्ट डिस्टिलेशन या दुरुपयोग मामले को ऑपरेटर द्वारा छुए गए प्रत्येक पहचानकर्ता में प्रवर्तन में परिवर्तित कर रहे हैं।

परीक्षण और क्रेडिट दुरुपयोग जहाँ एक ही डिवाइस और चेहरा एक नए मुफ्त आवंटन के लिए वापस आते रहते हैं।

बाज़ार हटाए गए विक्रेताओं को एक नए व्यवसाय के तहत फिर से पंजीकरण करने से रोक रहे हैं।

आईगेमिंग स्व-बहिष्कार को लागू कर रहा है, जहाँ एक वापस आने वाला बहिष्कृत खिलाड़ी एक नियामक विफलता है और चेहरा-स्तर प्रवर्तन एकमात्र विश्वसनीय नियंत्रण है।

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

क्या मैं अपनी खुद की ब्लॉकलिस्ट बना सकता हूँ?

नहीं। ब्लॉकलिस्ट सिस्टम-निर्मित, प्रति प्रविष्टि प्रकार एक, और अपरिवर्तनीय होते हैं — आप प्रविष्टियाँ जोड़ते और हटाते हैं। आप अनुमति सूचियाँ और कस्टम सूचियाँ स्वतंत्र रूप से बना सकते हैं। यह बाधा "ब्लॉकलिस्टेड" का अर्थ हर जगह एक ही रखती है।

एक प्रविष्टि को प्रभावी होने में कितना समय लगता है?

तुरंत, अगले सत्यापन पर।

क्या होगा अगर मैं गलती से कुछ ब्लॉकलिस्ट कर देता हूँ?

प्रविष्टि को हटा दें और इकाई अनब्लॉक हो जाएगी। यही कारण है कि उत्पत्ति मायने रखती है — सत्र से बनाई गई प्रत्येक प्रविष्टि उससे जुड़ी होती है, ताकि आप हटाने से पहले यह ऑडिट कर सकें कि एक प्रविष्टि किस लिए थी।

क्या एक आईपी रेंज को ब्लॉकलिस्ट करने से उस रेंज के वैध उपयोगकर्ता प्रभावित होते हैं?

हाँ, और यही जोखिम है। एक CIDR प्रविष्टि उसके अंदर सब कुछ ब्लॉक करती है। जब साक्ष्य समर्पित बुनियादी ढांचे की ओर इशारा करता है तो रेंज का उपयोग करें, अन्यथा एकल पते का उपयोग करें, और पहले ज्ञात-अच्छी रेंज को अनुमति दें।

क्या मैं किसी ऐसी चीज़ से ब्लॉकलिस्ट कर सकता हूँ जो सत्यापन सत्र नहीं है?

हाँ। reference_object_uuid प्लस metadata.reference_type (transaction, vendor_user या vendor_business) लेनदेन और विक्रेता उपयोगकर्ताओं या व्यवसायों को कवर करता है।

क्या यह मॉडल निष्कर्षण को रोकता है?

नहीं। यह एक विशिष्ट ज्ञात अभिनेता को उन पहचानकर्ताओं के माध्यम से फिर से प्रवेश करने से रोकता है जिनके विरुद्ध आपने प्रवर्तन किया है, और यह पुनर्जनन की लागत बढ़ाता है। निष्कर्षण का पता लगाना पहली जगह में आपके ट्रैफ़िक परत का काम है, और निष्कर्षण से क्या प्राप्त होता है उसे सीमित करना आपकी मॉडल परत का काम है। यह तीन-परत रक्षा का प्रवर्तन हथियार है, न कि अन्य दो का प्रतिस्थापन।

शुरू करने के लिए तैयार हैं?

सूचियाँ API हर Didit खाते पर उपलब्ध है।

• दस्तावेज़ पढ़ें — सूचियाँ API अवलोकन और आईपी और डिवाइस चेतावनी सूची।
• उत्पाद देखें — उपयोगकर्ता सत्यापन।
• मूल्य निर्धारण की जाँच करें — सार्वजनिक रूप से सूचीबद्ध, प्रति-सफलता भुगतान, कोई न्यूनतम नहीं।
• मुफ्त में शुरू करें — business.didit.me, 500 केवाईसी सत्यापन प्रति माह बिना किसी लागत के।