APAC में कम एन्ट्रॉपी डेटा और क्रेडिट कार्ड का हैशिंग

विषय सूची

क्रिप्टोग्राफी का एक असहज सच: केवल हैशिंग करना वास्तविक सुरक्षा के बराबर नहीं है। आप क्रेडिट कार्ड नंबर का SHA-256 हैश स्टोर कर सकते हैं, पूरी तरह से PCI DSS का अनुपालन कर सकते हैं, और फिर भी प्रभावी रूप से शून्य सुरक्षा पा सकते हैं, क्योंकि जिस मान को आपने हैश किया है उसमें ब्रूट फोर्स का विरोध करने के लिए पर्याप्त एन्ट्रॉपी नहीं है।

इंजीनियरिंग टीमें अक्सर यह मान लेती हैं कि चूंकि हैश फ़ंक्शन एकतरफा (one-way) है, इसलिए डेटा सुरक्षित है। दोष गणितीय फ़ंक्शन में नहीं है; दोष इनपुट स्पेस के बहुत छोटे आकार में है।

वास्तविक संख्याओं में एन्ट्रॉपी की समस्या #

16-अंकीय कार्ड नंबर (PAN) यादृच्छिक नहीं होता:

पहले 4 से 6 अंक जारीकर्ता पहचान संख्या (IIN / बैंक उपसर्ग) होते हैं, जो सार्वजनिक होते हैं।
अंतिम अंक लुह्न एल्गोरिथ्म (Luhn Algorithm) द्वारा गणना किया गया चेकसम होता है।

जब आप PCI DSS के अनुसार कार्ड को मास्क करते हैं (पहले 4-6 और अंतिम 4 अंक दिखाई देते हैं):

4532 AAXX XXXX 1234

केवल 4 IIN अंकों के साथ, अज्ञात भाग केवल 8 अंक (100,000,000 संभावित मान) होता है। लुह्न चेकसम लागू करने के बाद, उनमें से केवल 10 में से 1 मान ही मान्य रहता है। वास्तविक खोज स्थान केवल 10 मिलियन (1 करोड़) मान है।

10 मिलियन हैश का परीक्षण कितनी तेजी से हो सकता है? #

SHA-256 अत्यधिक गति के लिए डिज़ाइन किया गया है:

हार्डवेयर	अनुमानित SHA-256 थ्रूपुट
1× RTX 4090 GPU	~8.5 बिलियन हैश / सेकंड
4× RTX 4090 क्लस्टर	~34 बिलियन हैश / सेकंड
8× RTX 4090 क्लस्टर	~68 बिलियन हैश / सेकंड

एक सामान्य GPU पर 10 मिलियन संभावनाओं का परीक्षण करने में केवल एक सेकंड का एक हज़ारवां हिस्सा (0.001 सेकंड) लगता है।

निष्कर्ष स्पष्ट है: कम-एन्ट्रॉपी फ़ील्ड्स पर, SHA-2 सुरक्षित नहीं है, भले ही वह विनियामक रूप से अनुपालन योग्य हो।

“Compliant” वास्तव में क्या अनुमति देता है #

PCI DSS वास्तव में आपको PAN को SHA-256 से hash करने नहीं कहता। Requirement 3.5 कहती है कि आप PAN को strong cryptography से unreadable बनाएं, जो keyed hashes और encryption को स्पष्ट रूप से बताती है, और नोट करती है कि hashed and salted index स्वीकार्य है जहां salt गोपनीय हो और hash व्यावहारिक रूप से reversible न हो। समस्या यह है कि 10 मिलियन-मूल्य स्पेस का खाली, बिना salted SHA-256 व्यवहार में exhaustion द्वारा reversible है, इसलिए checklist tick पास होने पर भी यह requirement के इरादे को विफल करता है।

Masking (पहले 4-6 और/या अंतिम 4 दिखाना) एक अलग नियंत्रण है: यह operator जो देखता है उसे सुरक्षा देता है, आप जो store करते हैं उसे नहीं। दोनों को आसानी से confuse किया जाता है, और यही confusion है जिससे masked-लेकिन-bare-hashed PAN production में पहुंच जाते हैं।

इस प्रकार के डेटा को सही तरीके से कैसे सुरक्षित करें #

डेटा को स्टोर ही न करें: टोकनाइजेशन (Tokenisation) और HSM का उपयोग करें।
कुंजी-आधारित हैशिंग (HMAC with Pepper): डेटाबेस के बाहर संग्रहीत एक गुप्त कुंजी के साथ HMAC का उपयोग करें।
मेमोरी-हार्ड फ़ंक्शंस का उपयोग करें: Argon2id या scrypt का उपयोग करें जिसमें प्रति-मान यादृच्छिक साल्ट (Salt) शामिल हो।
हर जगह salts और peppers। प्रति-मान यादृच्छिक salt precomputed tables को असंभव बनाता है, और database के बाहर संग्रहीत गुप्त pepper offline cracking को आपके infrastructure तक सीमित कर देता है।

flowchart TD A[PAN संग्रहीत करना है] --> B{इंडेक्सिंग के लिए आवश्यक?} B -- नहीं --> C[टोकनाइजेशन / HSM / वॉल्ट] B -- हाँ --> D{गुप्त कुंजी उपलब्ध?} D -- हाँ --> E[HMAC + Pepper] D -- नहीं --> F[Argon2id / scrypt + Salt] style C stroke:#10B981,stroke-width:2px style E stroke:#10B981,stroke-width:2px style F stroke:#10B981,stroke-width:2px

कार्ड से परे अन्य पहचानकर्ताओं पर भी लागू #

यह राष्ट्रीय पहचान पत्र, फोन नंबर और जन्मतिथि जैसे सभी निश्चित-प्रारूप पहचानकर्ताओं पर समान रूप से लागू होता है।

क्या आप अपनी संवेदनशील पहचानकर्ताओं की सुरक्षा को लेकर चिंतित हैं? तकनीकी समीक्षा के लिए संपर्क करें: ईमेल (hello@puresecurity.com) या LINE (@PureSecurity)।

हमारी API और एप्लिकेशन सुरक्षा समीक्षा आपके क्रिप्टोग्राफ़िक कार्यान्वयन की जांच करती है।