भुगतान कार्ड पर छपा छोटा कोड वह फ़ील्ड है जिस पर लोग कार्ड ज़ोर से पढ़ते समय झिझकते हैं, और वही झिझक पूरा उद्देश्य है। CVV एक अलग रहस्य है जो केवल प्लास्टिक पर रहता है — नंबर में नहीं, समाप्ति तिथि में नहीं, और किसी ऐसी चीज़ में नहीं जिसे कोई चोर रसीद से दोबारा बना सके। इसे इसलिए जोड़ा गया कि कार्ड-नॉट-प्रेज़ेंट भुगतानों को कुछ प्रमाण चाहिए था कि जानकारी भरने वाले व्यक्ति के पास वाकई कार्ड है।
यह लेख बताता है कि कोड क्या है, नेटवर्क के बीच उसकी लंबाई क्यों बदलती है, भुगतान नियम उसे रखने से क्यों मना करते हैं, और जो फ़ॉर्म यह कोड माँगता है उसे बनाते या जाँचते समय किन बातों का ध्यान रखना चाहिए।
सुरक्षा कोड क्या है और कहाँ छपा होता है
अधिकांश नेटवर्कों में कोड कार्ड के पीछे छपे तीन अंक होते हैं, या तो हस्ताक्षर पट्टी के भीतर या ठीक उसके बगल में। American Express कार्ड के आगे, कार्ड नंबर के अंतिम समूह के ऊपर चार अंक लगाता है।
यह मान कार्ड बनते समय जारीकर्ता तैयार करता है। यह कार्ड नंबर से निकाला नहीं जाता, यह चेकसम नहीं है, और कार्ड पर छपी किसी और चीज़ से इसकी गणना नहीं हो सकती। कोड खो जाने पर उसे गणित से वापस नहीं पाया जा सकता; जारीकर्ता को नया कार्ड जारी करना पड़ता है।
दस्तावेज़ीकरण इसे कई नामों से बुलाता है, और उन नामों की संख्याएँ सजावटी नहीं, अर्थपूर्ण हैं। सादा नाम चुंबकीय पट्टी या चिप में भरे डेटा का वर्णन करता है, जबकि दो संख्या वाला रूप वह छपा मान है जिसे ग्राहक पढ़कर बताता है। इसलिए कार्ड-प्रेज़ेंट टर्मिनल की जाँच और चेकआउट पृष्ठ की जाँच दो अलग फ़ील्ड छू रही होती हैं, भले ही नाम एक-दूसरे के बदले इस्तेमाल होते लगें।
| नेटवर्क परिवार | कोड की लंबाई | कहाँ छपा होता है |
|---|---|---|
| Visa, Mastercard, Discover, UnionPay | तीन अंक | कार्ड के पीछे |
| American Express | चार अंक | कार्ड के आगे |
कुछ कार्डों पर कोड तीन अंक और कुछ पर चार क्यों होता है?
यह अंतर हर नेटवर्क की चुनी हुई क्रमांकन योजना से आता है, किसी सुरक्षा-भेद से नहीं। चार अंकों का कोड किसी सार्थक अर्थ में तीन अंकों से मज़बूत नहीं है; दोनों इतने छोटे हैं कि अनुमान लगाना खतरे का मॉडल ही नहीं है। लंबाई केवल नेटवर्क के विनिर्देश का हिस्सा है, ठीक वैसे ही जैसे उसके कार्ड नंबर अलग संख्या में अंक इस्तेमाल करते हैं।
फ़ॉर्म बनाने वाले के लिए यही एक तथ्य इस क्षेत्र के अधिकांश बग पैदा करता है। तीन अक्षरों पर स्थिर किया गया फ़ील्ड American Express का कोड बिना बताए काट देता है, और तीन अंकों पर ज़िद करने वाला सत्यापक वैध कार्ड को भी ठुकरा देता है। व्यावहारिक रास्ता यह है कि पहले उपयोगकर्ता से ब्रांड पूछें, या उसे नंबर से पहचानें, और फ़ील्ड का आकार उसी के अनुसार रखें — साथ में ऐसी ऊपरी सीमा जो बेतुका इनपुट फिर भी ठुकरा दे।
कोड क्या सिद्ध करता है और क्या नहीं?
कार्ड-नॉट-प्रेज़ेंट लेन-देन में व्यापारी कार्ड देख नहीं सकता, इसलिए भुगतान प्रणाली ऐसी चीज़ माँगती है जिसे कार्ड थामे हुए व्यक्ति पढ़ सके। नंबर और समाप्ति तिथि किसी पुराने बिल या लीक हुए डेटाबेस से कॉपी हो सकते थे; छपा हुआ कोड नहीं, क्योंकि वह कहीं और लिखा ही नहीं गया।
इससे यह साधारण धोखाधड़ी के सामने एक मामूली पर असली अड़चन बनता है, और इसीलिए यह फ़ील्ड सजावट नहीं है। नेटवर्क कोड को इस बात का प्रमाण मानते हैं कि लेन-देन ने सत्यापन की ऊँची शर्त पूरी की, और धोखाधड़ी पर विवाद होने पर जो व्यापारी इसे ठीक से लेते हैं उनके साथ व्यवहार उनसे अलग होता है जो नहीं लेते। उस दायित्व-स्थानांतरण की ठीक शर्तें नेटवर्कों की बात हैं; फ़ॉर्म बनाने वाले के लिए व्यावहारिक निष्कर्ष इतना ही है कि यह फ़ील्ड इकट्ठा किया जाना चाहिए, नकली नहीं बनाया जाना।
कोड यह सिद्ध नहीं करता कि कार्ड असली है या खाता ठीक हालत में है। सही आकार में अनुमानित मान किसी भी क्लाइंट-साइड जाँच को तुरंत पार कर जाता है, क्योंकि फ़ॉर्म ऐसे रहस्य को सत्यापित नहीं कर सकता जिसे वह देख ही नहीं सकता। यह प्रश्न केवल जारीकर्ता को भेजा गया अधिकरण अनुरोध ही उत्तर दे सकता है।
कार्ड नियम कोड संग्रह करने से क्यों मना करते हैं?
यही वह नियम है जो इंजीनियरिंग टीमों को सबसे ज़्यादा चौंकाता है। कार्ड उद्योग के डेटा सुरक्षा मानक के तहत सुरक्षा कोड को संवेदनशील प्रमाणीकरण डेटा माना जाता है। इसका उपयोग किसी लेन-देन को अधिकृत करने के लिए हो सकता है, और अधिकरण के बाद इसे रखना नहीं चाहिए — न किसी डेटाबेस स्तंभ में, न लॉग फ़ाइल में, न स्प्रेडशीट में, न किसी ऐसी कतार के संदेश में जिसे कोई वर्कर दस सेकंड बाद खपत करता है।
तर्क सीधा है। संग्रहित कोड संग्रहित भुगतान क्रेडेंशियल है। यदि किसी सेंध से कार्ड नंबर उजागर होते हैं, तो हमलावर को उन्हें ऑनलाइन इस्तेमाल करने के लिए अभी भी कुछ और चाहिए; यदि साथ में कोड भी उजागर हो जाएँ, तो नंबर तुरंत इस्तेमाल योग्य हो जाते हैं।
समीक्षा में ये चूकें शायद ही कभी जानबूझकर लिए गए फैसले जैसी दिखती हैं:
- ऑर्डर तालिका में एक डिबगिंग सत्र के लिए जोड़ा गया और फिर कभी न हटाया गया स्तंभ।
- ऐसा अनुरोध-लॉगिंग मिडलवेयर जो पूरा सबमिट किया गया बॉडी, कोड समेत, ऐसे एग्रीगेटर में दर्ज कर देता है जिसके अभिगम नियंत्रण भुगतान प्रणाली से कमज़ोर हैं।
- ऐसा त्रुटि रिपोर्टर जो हर अपवाद के साथ विफल फ़ॉर्म पेलोड भी जोड़ देता है।
- ऐसी पुनःप्रयास कतार जो मूल शुल्क अनुरोध को जस का तस रखती है ताकि उसे दोबारा चलाया जा सके।
इनमें से हर एक अनुपालन चूक है, और लिखे जाने के समय इनमें से कोई भी चूक जैसी नहीं दिखती।
सुरक्षा कोड का फ़ील्ड बिना गलती भरना
यहाँ अधिकांश कठिनाई सुरक्षा की नहीं, टाइपिंग की है, और मुश्किल मामले इतने अनुमेय हैं कि उनके लिए पहले से डिज़ाइन किया जा सके:
- फ़ील्ड से लंबा कोड। कोई तीन अक्षरों के बॉक्स में चार अंक चिपका देता है। या तो चुपचाप काटें या संदेश दिखाएँ, पर एक ही व्यवहार चुनें और उसे लगातार लागू रखें।
- गैर-संख्यात्मक इनपुट। अक्षर, खाली स्थान, चिपकाए गए हिस्से से आया हाइफ़न। फ़ील्ड को इन्हें ठुकराना चाहिए, पर उपयोगकर्ता ने जो पहले से टाइप किया है उसे मिटाए बिना।
- शुरुआती शून्य। शून्य से शुरू होने वाला कोड वैध है और मान को संख्या मानकर पार्स करने से उसे सामान्यीकृत करके गिराया नहीं जाना चाहिए।
- मास्किंग। टाइप करते समय अंक छिपाना भरोसा देता लगता है, पर जाँचें कि इससे ऑटोफ़िल टूटती नहीं या ब्राउज़र पूरे चेकआउट को लॉग इन स्क्रीन नहीं समझने लगता।
- मोबाइल कीबोर्ड। संख्यात्मक कीपैड इस्तेमाल में तेज़ होता है, जो ऐसे फ़ील्ड पर मायने रखता है जिसे लोग दूसरे हाथ में कार्ड थामे हुए भरते हैं।
डेवलपर के लिए: कोड को लॉग और संग्रह से बाहर रखना
यहाँ इंजीनियरिंग का अनुशासन घटाने में है। संवेदनशील प्रमाणीकरण डेटा को संभालने का सबसे सुरक्षित तरीका यह है कि वह अधिकरण के क्षण के अलावा किसी भी समय किसी सिस्टम में ही न हो।
शुरुआत इस जाँच से करें कि आपकी लॉगिंग परत असल में क्या पकड़ती है। जो फ़्रेमवर्क डिफ़ॉल्ट रूप से अनुरोध बॉडी लॉग करता है वह कोड भी दर्ज करेगा, और लॉग का गंतव्य अक्सर कोई तीसरा पक्ष होता है जिसके अभिगम नियम अलग हैं। यदि कोड आपके सर्वर तक पहुँचता ही नहीं — क्योंकि कोई होस्टेड भुगतान फ़ील्ड उसे सीधे लेता है — तो समस्या ही गायब हो जाती है, और यही सबसे मज़बूत विकल्प है।
जहाँ आप मान संभालते हैं, उसे क्षणभंगुर मानें। उसे ऐसी मॉडल वस्तु में न जोड़ें जो ऑडिट पंक्ति में क्रमबद्ध हो जाती है, उसे पुनःप्रयास पेलोड में शामिल न करें, और अपवाद प्रबंधक को उसे रिपोर्ट से जोड़ने न दें। ऐसा टेस्ट लिखें जो चलने के बाद आपके लॉग आउटपुट को खोजे और कोड जैसा मान मिलने पर विफल हो जाए; वही एक जाँच आकस्मिक संग्रह के अधिकांश मामले पकड़ लेती है।
इसके बाद अपना परीक्षण डेटा देखें। जो कुछ भी फ़ील्ड को अपने आप भरता है, वह काल्पनिक मानों से आना चाहिए, और उनकी समीक्षा किसी भी अन्य भुगतान फ़िक्स्चर जितनी सावधानी से होनी चाहिए। PCI DSS संबंधी टिप्पणियाँ उन व्यापक नियमों को कवर करती हैं कि परीक्षण वातावरण में क्या रह सकता है, और भुगतान फ़ॉर्म जाँच सूची इस फ़ील्ड को उन प्रवाहों के क्रम में रखती है जो लॉन्च से पहले परखे जाने चाहिए।
परीक्षण कार्ड और उनके प्लेसहोल्डर कोड
बनाए गए कार्ड को फ़ील्ड भरने के लिए एक कोड चाहिए, और वह मान उसी तरह प्लेसहोल्डर है जैसे बाकी कार्ड। उसकी लंबाई सही है और अक्षरों का समूह सही है, और वह किसी जारीकर्ता के पास रखे किसी रहस्य से मेल नहीं खाता।
इस साइट का जनरेटर जो कुछ लौटाता है उसका सटीक वर्णन यही है: संरचना में मान्य डेटा जो कभी जारी नहीं हुआ। प्लेसहोल्डर कोड किसी डेमो या स्टेजिंग परीक्षण को पूरा दिखाता है, और वह कहीं भी कुछ अधिकृत नहीं करेगा।
आगे क्या करें
अपने किसी एक फ़ॉर्म की तीन बातें इस क्रम में जाँचें: क्या फ़ील्ड नेटवर्क की कोड लंबाई के अनुसार बदलता है, क्या वह मान किसी लॉग या तालिका में पहुँचता है, और क्या त्रुटि संदेश गलत लंबाई को असमर्थित अक्षर से अलग बताते हैं। फ़ील्ड के साथ जोड़ने के लिए नंबर कार्ड नंबर जनरेटर से लें, और उसके बगल में बैठने वाली तारीख की सीमा-शर्तों के लिए समाप्ति तिथि गाइड देखें।