बोर्डिंग पास पोस्ट करने पर खाता गंवाना: QR ढकने पर हमने जो मापा
एक टिकट की पर्ची से कितना निकल सकता है
शुरुआत किसी कल्पना से नहीं, दर्ज हो चुके असली मामले से।
सुरक्षा पत्रकार ब्रायन क्रेब्स ने 2015 में इस पर विश्लेषण लिखा था। कोरी नाम के एक पाठक ने देखा कि उसके मित्र ने बोर्डिंग पास की तस्वीर फेसबुक पर डाली है। उसने स्क्रीनशॉट लिया, बारकोड बड़ा किया और उसे इंटरनेट पर उपलब्ध मुफ्त बारकोड डिकोडर में डाल दिया। कुछ ही सेकंड में उसके पास उस मित्र के फ्रीक्वेंट फ्लायर खाते की जानकारी थी।
इसके बाद जो हुआ वही असली मुद्दा है। कोरी उस खाते की सभी आगामी उड़ानें देख सकता था, टिकट जारी हो चुके यात्रियों की सीटें बदल सकता था और किसी भी आने वाली उड़ान को रद्द कर सकता था। इससे भी बड़ी बात यह कि उजागर हुई जानकारी एयरलाइन की «PIN भूल गए» प्रक्रिया के पहले आधे हिस्से को पार करने के लिए पर्याप्त थी।
मित्र ने तो बस खुशी में एक यात्रा तस्वीर पोस्ट की थी।
एक बात लगभग सब चूक जाते हैं: बारकोड और QR कोड सजावट नहीं, मशीन से पढ़े जाने वाले डेटा के डिब्बे हैं। आपको काले-सफेद खाने दिखते हैं; स्कैनर को बुकिंग संदर्भ, नाम, उड़ान, तारीख और सीट दिखती है। यही अंतर पूरा जोखिम है।
आधा ढकना काम नहीं करता, और मैंने मापा कि कितना नहीं करता
यह वह हिस्सा है जो मैं सबसे ज्यादा लिखना चाहता था, क्योंकि गलत तरीके से ढकना कुछ न करने से ज्यादा खतरनाक है — आप खुद को सुरक्षित मानकर निश्चिंत होकर पोस्ट कर देते हैं।
QR कोड में डिजाइन से ही मजबूत त्रुटि-सुधार क्षमता होती है। विनिर्देश स्कैनर को पूरी सामग्री बहाल करने देता है, भले ही प्रतीक का एक बड़ा हिस्सा क्षतिग्रस्त, गंदा या ढका हो। भौतिक दुनिया में यह गुण बहुत उपयोगी है (मुड़ा टिकट या फैली छपाई भी स्कैन हो जाती है), पर «आधा ढक दूं तो चलेगा» वाली सोच पर लागू होते ही यही कमजोरी बन जाता है।
इसलिए मैंने खुद माप लिया।
सचमुच कितना क्षेत्र ढकना पड़ता है
तरीका दोहराया जा सकता है। मैंने Python की qrcode लाइब्रेरी से एक काल्पनिक वाउचर का QR कोड बनाया — सामग्री एक रिडेम्पशन URL है जिसमें बुकिंग संदर्भ और सत्यापन कोड है — और उसे त्रुटि-सुधार स्तर M (15 %), Q (25 %) और H (30 %) पर तैयार किया। हर एक पर ढकने के चार तरीके, सात क्षेत्र अनुपात में लगाए, फिर OpenCV के QRCodeDetector से डिकोड करने की कोशिश की। मूल URL पूरी तरह बहाल होने पर ही «अब भी पढ़ा जा सकता है» माना गया।
नतीजा मेरी उम्मीद से भी बुरा निकला।
| ढकने का तरीका | विफल होता है (M, 15 %) | विफल होता है (Q, 25 %) | विफल होता है (H, 30 %) |
|---|---|---|---|
| बीच में ठोस ब्लॉक | 15 % क्षेत्र | 20 % क्षेत्र | 25 % क्षेत्र |
| नीचे दाएं कोने में ठोस ब्लॉक | 20 % क्षेत्र | 25 % क्षेत्र | 25 % क्षेत्र |
| आड़ी पट्टी | 10 % क्षेत्र | 20 % क्षेत्र | 20 % क्षेत्र |
| बीच में मोज़ेक | 15 % क्षेत्र | 20 % क्षेत्र | 25 % क्षेत्र |
तालिका ऐसे पढ़ें: वह प्रतिशत वह बिंदु है जहां डिकोडिंग विफल होना शुरू होती है। उससे नीचे सब कुछ पढ़ा जाता रहा।
तीन बातें याद रखने लायक हैं।
पहली, ऊंचे त्रुटि-सुधार वाला टिकट पांचवें हिस्से जितना क्षेत्र ढकने पर भी पढ़ा जाता है। H स्तर पर 20 % ढकने पर बीच का ब्लॉक, कोने का ब्लॉक और मोज़ेक — तीनों ने सामग्री बहाल कर ली। स्क्रीनशॉट पर आपने जो ठीक-ठाक बड़ा चौकोर बनाया था, उसने असल में कुछ भी नहीं रोका।
दूसरी, मोज़ेक का व्यवहार ठोस ब्लॉक जैसा ही रहा — तीनों स्तरों पर विफलता की सीमा बिल्कुल समान। इससे यह धारणा टूट जाती है कि धुंधला करना कम से कम कुछ न करने से बेहतर है। यह ज्यादा सुरक्षित नहीं होता, बस ऐसा लगता है कि आपने कुछ कर दिया।
तीसरी, चारों में सबसे कारगर आड़ी पट्टी निकली। M स्तर पर ऊंचाई के 10 % जितनी एक पट्टी ही काफी थी। कारण यह कि पट्टी प्रतीक की पूरी चौड़ाई काटती है, इसलिए क्षति कई कोडवर्ड ब्लॉकों में बंट जाती है, जबकि एक जगह सिमटा चौकोर ठीक उसी दायरे में बैठ जाता है जहां त्रुटि-सुधार सबसे मजबूत है।
ईमानदारी से कहूं तो तीसरी बात उस निष्कर्ष के उलट है जो मैं लिखने वाला था। यह चेतावनी कि «टिकट पर लकीरें खींचने से वह रद्द नहीं होता» सही है — वह वैधता और पठनीयता की बात करती है। पर अगर सवाल यह हो कि किस तरह की कटाई स्कैनर को बेहतर रोकती है, तो ये आंकड़े कहते हैं कि पट्टी चौकोर से आगे है। ऐसा अंतर मापे बिना पता नहीं चलता।
कहां ढका, यह कितना ढका से ज्यादा मायने रखता है
सबसे उपयोगी नतीजा आखिरी परीक्षण से आया।
QR कोड के तीन कोनों पर बने बड़े चौकोर स्थान-निर्धारण प्रतिरूप (finder pattern) हैं, जिनसे स्कैनर दिशा और सीमाएं तय करता है। मैंने ऊपर बाएं वाला ढक दिया और तीनों त्रुटि-सुधार स्तर डिकोड करने में विफल रहे — जबकि वह हिस्सा पूरी तस्वीर के केवल 2.0 से 3.6 % क्षेत्र में आता है।
दूसरे शब्दों में: सही जगह के 2 % ढकना गलत जगह के 20 % ढकने से बेहतर है।
इस परीक्षण की सीमाएं भी दर्ज कर दूं। मैंने OpenCV का डिकोडर, एक ही सामग्री और QR कोड का एक ही संस्करण इस्तेमाल किया। व्यावसायिक स्कैनर या फोन कैमरे का क्रियान्वयन अलग होता है और वे ज्यादा बहाल कर सकते हैं। इसलिए ऊपर दी सीमाओं को निचली सीमा मानिए, गारंटी नहीं — असल हमलावर का डिकोडर मेरे परीक्षण वातावरण से ज्यादा उदार होने की संभावना है।
व्यवहार में एक ही मानक बचता है: पूरे प्रतीक को अपारदर्शी रंग से, किनारों के बाहर तक ढकिए। एक कोना नहीं, कुछ लकीरें नहीं, मोज़ेक नहीं। अगर उपकरण इसकी इजाजत न दे तो कम से कम तीन में से एक स्थान-निर्धारण कोना पूरा ढकिए।
ठीक से न ढका तो न ढकने के बराबर है।
यात्रा के स्क्रीनशॉट में रिसाव की तीन परतें
यात्रा के दौरान लिए स्क्रीनशॉट तीन परतों में बंटते हैं, जिनके जोखिम की प्रकृति बिलकुल अलग है।
| परत | सामान्य स्रोत | क्या रिसता है | सबसे बुरी स्थिति |
|---|---|---|---|
| पहली: स्कैन होने योग्य प्रमाण | Klook/KKday ई-वाउचर, कार्यक्रम टिकट, बोर्डिंग पास | प्रमाण स्वयं, PNR, फ्रीक्वेंट फ्लायर खाते के सूत्र | टिकट पहले ही इस्तेमाल, खाता कब्जे में |
| दूसरी: पाठ रूप में पहचान | Agoda/Booking.com की पुष्टि, बुकिंग नंबर, कमरा नंबर | नाम, ठहरने की तारीखें, संपत्ति का पता | होटल को नाम लेकर कॉल, सोशल इंजीनियरिंग |
| तीसरी: तस्वीर में अंतर्निहित डेटा | दूसरे उपकरण से स्क्रीन की तस्वीर | EXIF में GPS, खींचने का समय, उपकरण | वर्तमान स्थान या घर का अनुमान |
पहली परत सबसे तात्कालिक है। ई-वाउचर का मूल्य उसी कोड में है; कोई पहले स्कैन कर ले तो पता मौके पर पहुंचकर चलता है। ऐसे दर्ज मामले हैं जिनमें अपराधियों ने ऑनलाइन डाले गए कार्यक्रम टिकट उठाए, उन्हें बदला और खरीदने के इच्छुक लोगों को ठगा — नुकसान सिर्फ पोस्ट करने वाले का नहीं होता।
दूसरी परत देखने में हानिरहित लगती है और असल में सोशल इंजीनियरिंग का ईंधन है। नाम, ठहरने की तारीखें और होटल का नाम मिलकर इतने काफी हैं कि कोई आपके नाम पर रिसेप्शन को फोन करके बुकिंग बदलवा दे, या उलटा होटल बनकर आपको फोन करे और «कार्ड की जानकारी दोबारा पुष्टि» मांगे। पर्यटन के व्यस्त मौसम में ऐसी ठगी बढ़ जाती है।
तीसरी परत सबसे ज्यादा नजरअंदाज होती है। फोन के स्क्रीनशॉट में आमतौर पर GPS नहीं होता, पर किसी दूसरे उपकरण से स्क्रीन की तस्वीर खींचने पर उस तस्वीर में आपके तत्कालीन निर्देशांक जुड़ जाते हैं। कंप्यूटर की स्क्रीन किसी को भेजते समय यह सोच से ज्यादा बार होता है।
साथ यात्रा कर रहे लोगों को जानकारी दिखानी हो तो
यह सबसे व्यावहारिक सवाल है। यात्रा की जानकारी साझा करनी ही पड़ती है — साथी को मिलने का समय, टिकट की सामग्री और ठहरने का पता पता होना चाहिए।
प्राथमिकता का क्रम यह है।
पहला विकल्प प्लेटफॉर्म की अपनी साझा सुविधा है। Klook, KKday, MakeMyTrip और ज्यादातर प्लेटफॉर्म बुकिंग को साथी यात्री के साथ साझा या स्थानांतरित करने की सुविधा देते हैं। आधिकारिक रास्ते से जाने पर प्रमाण की वैधता प्लेटफॉर्म के नियंत्रण में रहती है और इधर-उधर घूमने वाला कोई स्क्रीनशॉट बनता ही नहीं।
दूसरा विकल्प तस्वीर नहीं, पाठ भेजना है। «26/9, सुबह 9 बजे, मुख्य द्वार, टिकट मेरे पास हैं» — इसमें सारी जरूरी जानकारी है और जोखिम शून्य।
तीसरा विकल्प सुरक्षा के साथ तस्वीर साझा करना है। अगर सचमुच स्क्रीन भेजनी पड़े (जैसे जटिल यात्रा तालिका या नक्शे की तस्वीर) तो पहुंच नियंत्रण वाले तरीके से भेजिए, खुली पोस्ट में मत डालिए।
lpic.cc पर अपलोड के समय देखने का पासवर्ड लगाया जा सकता है, जिससे छोटा लिंक आगे भेजे जाने पर भी बिना पासवर्ड नहीं खुलता। पासवर्ड bcrypt से हैश करके रखे जाते हैं, सादे पाठ में तुलना नहीं होती। «सिर्फ इन पांच लोगों को दिखानी है» वाली यात्रा तालिका के लिए यह ग्रुप में डालकर बहने देने से कहीं ज्यादा नियंत्रित है।
सीमाएं भी पहले ही: तस्वीर अधिकतम 8 MB, फाइलें आखिरी बार देखे जाने के 30 दिन तक, अपलोड अपने आप अनुकूलित होते हैं इसलिए मूल फाइल नहीं रखी जाती। और सबसे अहम — पासवर्ड उन्हें रोकता है जिन्हें नहीं देखना चाहिए, पर अधिकार रखने वाले को स्क्रीनशॉट लेकर आगे भेजने से नहीं रोकता। हर साझा तंत्र की यही अधिकतम सीमा है। इसे सर्वशक्तिमान मत मानिए।
आखिरी सुरक्षा पंक्ति वही पुरानी बात है: सचमुच संवेदनशील प्रमाण को शुरुआत में ही तस्वीर की फाइल मत बनने दीजिए।
अक्सर पूछे जाने वाले प्रश्न
प्रश्न 1: मैंने बोर्डिंग पास काफी पहले पोस्ट किया था, अब हटाने से फायदा है?
हटाने से आगे का प्रसार घटता है, पर यह नहीं मान सकते कि किसी ने सहेजा नहीं होगा। दो और काम ज्यादा जरूरी हैं: उस एयरलाइन खाते का पासवर्ड और सुरक्षा प्रश्न तुरंत बदलिए, और आगामी बुकिंग में कोई अनधिकृत बदलाव तो नहीं हुआ, यह जांचिए। क्रेब्स वाले मामले में हमलावर सबसे पहले सीट बदल सकता था और उड़ान रद्द कर सकता था।
प्रश्न 2: मेरा Klook वाउचर किसी और ने स्कैन कर लिया, क्या मैं फिर भी प्रवेश कर पाऊंगा?
टिकट के प्रकार पर निर्भर है। एक बार इस्तेमाल होने वाला वाउचर पहले ही भुनाया जा चुका हो तो मौके पर «इस्तेमाल हो चुका» दिखेगा। ऐसे में तुरंत प्लेटफॉर्म के ग्राहक सहायता से संपर्क कीजिए, हालांकि नतीजे की गारंटी नहीं और व्यस्त मौसम में जवाब धीमा आता है। इसीलिए यहां रोकथाम उपचार से कहीं भरोसेमंद है।
प्रश्न 3: QR कोड पर मोज़ेक लगाना काफी है?
काफी नहीं, और मैंने यह मापा है। तीनों त्रुटि-सुधार स्तरों पर मोज़ेक और ठोस ब्लॉक की विफलता सीमा एक जैसी रही — ऊंचे स्तर वाले टिकट में 25 % क्षेत्र ढकने पर ही स्कैन बंद हुआ। पूरे कोड क्षेत्र पर अपारदर्शी ठोस रंग लगाइए, या उससे बेहतर, तस्वीर लेते समय ही किसी वस्तु से ढक दीजिए।
प्रश्न 4: पुष्टि में सिर्फ बुकिंग नंबर और नाम है, तब भी जोखिम है?
है। नाम और बुकिंग नंबर कुछ प्लेटफॉर्म पर बुकिंग की स्थिति देखने के लिए पर्याप्त हैं, और ठहरने की तारीखें जुड़ते ही सोशल इंजीनियरिंग का पूरा सामान तैयार हो जाता है। असली मामलों में बार-बार दिखने वाला ढर्रा यही है: हमलावर को आपका पासवर्ड चाहिए ही नहीं, बस इतने टुकड़े चाहिए कि सहायता कर्मी को यकीन दिला सके।
प्रश्न 5: और यात्रा की तस्वीरें खुद?
जोखिम की प्रकृति अलग है। तस्वीरों में मुख्य मुद्दा EXIF के GPS निर्देशांक हैं। ज्यादातर सोशल प्लेटफॉर्म अपलोड के समय EXIF हटा देते हैं, पर क्लाउड ड्राइव या «मूल फाइल भेजें» वाले रास्ते में यह पूरा बचा रहता है। कौन सी सेवा क्या करती है, यह 8 सेवाओं की फील्ड-दर-फील्ड EXIF जांच रिपोर्ट में है।