मेरा बैंक लगातार anti-phishing शिक्षा को कमजोर कर रहा है
(moritz-mander.de)- बैंक ने फिशिंग ईमेल जैसे दिखने वाले अविश्वसनीय इवेंट प्रमोशनल ईमेल भेजे
- ईमेल के भीतर के लिंक और साइट डोमेन बैंक से असंबंधित लगते हैं, और व्यक्तिगत जानकारी भरने की मांग के कारण फिशिंग है या नहीं यह तय करना मुश्किल हो जाता है
- वास्तविकता की पुष्टि होने के बाद भी यह आधिकारिक इवेंट निकला, जिससे भ्रम और अविश्वास बढ़ा
- यह व्यवहार anti-phishing शिक्षा के उद्देश्य को नुकसान पहुंचाता है और बैंक के लिए कानूनी जिम्मेदारी का जोखिम बढ़ाता है
- समस्या के समाधान के लिए विश्वसनीय डोमेन के उपयोग और ऐप के भीतर कार्यान्वयन की आवश्यकता पर जोर दिया गया
प्रस्तावना
मैंने ऐसी स्थिति का प्रत्यक्ष अनुभव किया जिसमें मेरा बैंक खुद anti-phishing शिक्षा को कमजोर कर रहा था। बैंक द्वारा भेजा गया इवेंट-संबंधी ईमेल इतना संदिग्ध था कि उसे फिशिंग स्कैम से लगभग अलग करना मुश्किल था। यह आधिकारिक बैंक डोमेन के बजाय किसी और जगह पर व्यक्तिगत जानकारी भरने को कहता है, और इससे देश-विदेश के बैंकों व सार्वजनिक संस्थानों की सुरक्षा स्थिति तथा सुरक्षा-शिक्षा की वास्तविक समस्याएँ सामने आती हैं।
भाग 1: संदिग्ध ईमेल का आगमन
- बैंक से “Wero-Win-Wochen(प्राइज इवेंट)” से संबंधित ईमेल प्राप्त हुआ
- ईमेल नोटिस में अधिकतम प्रति सप्ताह 7,000 यूरो जीतने की जानकारी के साथ इवेंट में भाग लेने के लिए प्रेरित किया गया
- ईमेल में Sparkasse (जर्मनी का क्षेत्रीय बैंकिंग संगठन) और Wero (नया यूरोपीय डिजिटल पेमेंट सिस्टम) का उल्लेख था
- ईमेल के अंदर का लिंक “gewinnen-mit-wero.de” था, जो बैंक के आधिकारिक डोमेन से अलग है
- सामग्री और लिखने का अंदाज सामान्य फिशिंग मेल जैसा था; केवल ईमेल पता ही Sparkasse का आधिकारिक पता था
- यह पता लगाने के लिए कि इवेंट असली है या नहीं, बैंक की आधिकारिक साइट पर जाकर जांच करनी पड़ी
Sparkasse (Shupakase) क्या है?
- यह क्षेत्र-आधारित savings bank है, जिसे हर क्षेत्र में स्वतंत्र रूप से संचालित किया जाता है
- यह यूरोप के सबसे बड़े financial service groups में से एक है
Wero क्या है?
- यह European Payments Initiative (EPI) द्वारा बनाया गया नया digital payment system है
- इसे स्थानीय payment systems को एकीकृत करने के उद्देश्य से विकसित किया गया है (शुरुआत में P2P payments पर केंद्रित)
- यह PayPal जैसा है, लेकिन इसकी संरचना अलग-अलग बैंकों में वितरित है
भाग 2: स्थिति और बिगड़ती है – संदिग्ध वेबसाइट
- ईमेल के लिंक पर क्लिक करने पर खुलने वाली इवेंट पार्टिसिपेशन साइट का डिजाइन और ढांचा फिशिंग साइट से बहुत मिलता-जुलता है
- Sparkasse शाखा का कोई उल्लेख नहीं है और न ही अलग-अलग बैंकों का कोई विभाजन दिखता है (हर बैंक की स्वतंत्रता को नजरअंदाज किया गया)
- डोमेन खुद आधिकारिक बैंक डोमेन से असंबंधित है और ऐसा सामान्य नाम इस्तेमाल करता है जिसे कोई भी रजिस्टर कर सकता है
- SSL certificate भी मुफ्त Let’s Encrypt का इस्तेमाल करता है, जिससे भरोसा और कम होता है
- इवेंट के संदर्भ या आधार की पर्याप्त व्याख्या नहीं है; केवल “पैसा पाने का मौका” ही प्रमुखता से दिखाया गया है
- भाग लेने के लिए नाम, जन्मतिथि, IBAN, ईमेल पता जैसी व्यक्तिगत/वित्तीय जानकारी भरने की मांग की जाती है
- आम तौर पर आधुनिक digital finance इवेंट्स को सिर्फ ऐप के भीतर भागीदारी के लिए डिजाइन किया जाता है, लेकिन यह उससे अलग है
इससे वित्तीय संस्था खुद उपयोगकर्ताओं की सुरक्षा-शिक्षा को अर्थहीन बनाने जैसा परिणाम पैदा करती है
सुरक्षा-शिक्षा की प्रभावशीलता घटने की समस्या
- जब असली बैंक भी फिशिंग मेल/साइट जैसी शैली अपनाते हैं, तो उपयोगकर्ता फिशिंग पहचान-प्रशिक्षण पर ही भरोसा खोने लगते हैं
- “यह spam जैसा दिखता है, लेकिन शायद वास्तव में वैध भी हो सकता है” जैसी सोच फैलती है
- पहले भी इस बैंक ने संदिग्ध वाक्यांशों और डोमेन वाले आधिकारिक SMS भेजे थे (उदाहरण: paperless.io लिंक गाइड)
- support center भी यह नहीं समझ पाया कि यह spam जैसा क्यों दिख सकता है
भाग 3: समाधान क्या है?
- सबसे सुरक्षित तरीका यह है कि इवेंट में भाग लेने की प्रक्रिया सीधे ऐप के भीतर लागू की जाए
- यदि यह संभव न हो, तो भरोसा बनाए रखने के लिए आधिकारिक डोमेन (जैसे sparkasse.de) या प्रत्येक शाखा के subdomain का उपयोग किया जाना चाहिए
- जर्मन सरकार ने भी इसी तरह की घटना के बाद gov.de digital brand policy लागू कर service trust को मजबूत किया था
भाग 4: लापरवाही से कानूनी समस्या बनने की संभावना
- हाल में फिशिंग पीड़ितों के लिए बैंक मुआवजे से जुड़े अदालत के फैसलों में वृद्धि हो रही है
- अदालतें व्यक्तिगत जानकारी के लीक होने में “लापरवाही” का आकलन करते समय, यदि उपयोगकर्ता की गलती न हो, तो बैंक की जिम्मेदारी मानती हैं
- अगर इसी तरह की ईमेल/साइट संरचना का इस्तेमाल करके फिशिंग हमला किया जाए, तो बैंक के लिए यह साबित करना कठिन होगा कि पीड़ित पर्याप्त सावधान नहीं था
- वास्तविक बैंक के आधिकारिक ईमेल/साइट और फिशिंग के बीच समानता बहुत अधिक होने से कानूनी जोखिम बढ़ जाता है
निष्कर्ष
- तकनीकी सुरक्षा भले आगे बढ़ रही हो, लेकिन user experience security (USABLE SECURITY) में अब भी खामियाँ बनी हुई हैं
- ऐसे मामले anti-phishing शिक्षा की विश्वसनीयता को नुकसान पहुंचाते हैं और बैंक की कानूनी जिम्मेदारी तथा पूरे वित्तीय क्षेत्र पर नकारात्मक असर डालते हैं
- यह समस्या व्यक्तिगत feedback से हल होने वाली नहीं, बल्कि संरचनात्मक सिस्टम समस्या है
- यह मुद्दा यूरोप के सबसे बड़े financial groups में से एक में भी हो रहा है, इसलिए इसे और गंभीरता से देखने की जरूरत है
- अंत में यही सीख मिलती है: “सुरक्षा-शिक्षा को कमजोर मत कीजिए। बल्कि इस पर थोड़ा ध्यान दीजिए।”
2 टिप्पणियां
लगता है deja vu सिर्फ़ मेरा भ्रम नहीं है 🤣
Hacker News राय
मेरा बैंक एक fraud detection system इस्तेमाल करता है जो मेरे अकाउंट में संदिग्ध गतिविधि दिखने पर मुझे कॉल करता है, और फिर मुझसे कहता है कि मैं किसी खास नंबर पर वापस कॉल करूं। समस्या यह है कि हर बार अलग callback नंबर दिया जाता है। अगर उस नंबर को ऑनलाइन खोजो तो सिर्फ एक ही नतीजा मिलता है, और वह fraud detection system के आधिकारिक वेबपेज पर यह कहता है कि किसी भी फोन कॉल पर भरोसा मत करो। यह सलाह सही है, लेकिन विडंबना यह है कि इसका मतलब उनकी अपनी वैध कॉल को भी अनदेखा करना है।
मेरे कार्ड पर fraud detection system सिर्फ एक बार ट्रिगर हुआ था। तब मुझे बैंक से एक टेक्स्ट मिला: “संदिग्ध उपयोग के कारण आपका कार्ड ब्लॉक कर दिया गया है, कृपया इस नंबर पर कॉल करें।” वह नंबर भी एक random, unlisted नंबर था। मैंने उसे सिर्फ इसलिए नज़रअंदाज़ नहीं किया क्योंकि ठीक उससे पहले मैंने एक नई वेबसाइट पर भुगतान किया था। इसलिए मैंने अपने स्थानीय बैंक शाखा में सीधे फोन करके पुष्टि की कि मामला सच है या नहीं, और उन्होंने बताया कि यह वास्तव में सही था। इस प्रक्रिया पर मैं लगभग भड़क ही गया था।
लगता है बैंक के पूरे user experience (UX) flow का ध्यान रखने वाला कोई नहीं है। मेरा बैंक भी इसी तरह अजीब चलता है। उदाहरण के लिए, जब भी मैं अपनी पत्नी को पैसे ट्रांसफर करता हूं, हर बार fraud prevention के लिए कई सवाल पूछे जाते हैं। लेकिन सवालों के जवाब देने के बाद फिर एक संदेश आता है कि “क्योंकि आप अक्सर ट्रांसफर करते हैं, हम 2FA code या अतिरिक्त verification नहीं मांगेंगे।” ऐसा अतार्किक UX शायद इसलिए है क्योंकि पूरे flow का मालिक कोई एक व्यक्ति या टीम नहीं है।
बैंक अपने ही बनाए नियमों का पालन नहीं करता। एक बार बैंक ने मुझे उस insurance change के बारे में कॉल किया, जिसे मैंने एक महीने पहले अनुरोध किया था, और मुझसे security dongle से पहचान सत्यापित करने को कहा। ऐसे में अगर लोग scam का शिकार हो जाएं तो हैरानी की बात नहीं।
जिस बैंक में मैं काम करता हूं, वह यह जांचने के लिए टेक्स्ट भेजता है कि “क्या आपने $x की राशि का चेक जारी किया था?” समस्या यह है कि सबसे आम check fraud में, जिसे “check washing” कहते हैं, चेक की राशि वही रहती है और सिर्फ payee बदल दिया जाता है। ऐसे में राशि तो वैध लगती है, लेकिन वास्तव में भुगतान किसे हुआ, यह जांचा ही नहीं जाता।
अगर सामान्य बैंक helpline नंबर पर संपर्क करो, काफी देर इंतजार के बाद किसी representative से बात भी हो जाए, तब भी वे कहते हैं कि असली नंबर होने के बावजूद वे उस नंबर को मान्यता नहीं देते। और भी बुरा तब होता है जब वह ऐसा बैंक हो जिसका मैं ग्राहक ही नहीं हूं। वेबसाइट पर दिए नंबर पर कॉल करो तो सीधा IVR में फंस जाते हो, और अकाउंट नंबर न हो तो आगे बढ़ ही नहीं सकते। ऐसे में किसी इंसान से सीधे बात करने के लिए कोई दूसरा संपर्क नंबर ढूंढना पड़ता है।
मेरे बैंक (USAA) ने पहले कुछ सुझावों पर सचमुच अमल भी किया है। लेकिन हाल ही में मुझे मेरे unique email address पर एक सामान्य-सा दिखने वाला ईमेल मिला, जिसका domain सामान्य से अलग था। चूंकि मैंने उससे ठीक पहले कुछ प्रोसेस किया था, इसलिए यह और संदिग्ध लगा। मैंने तुरंत बैंक को कॉल किया और fraud department के कर्मचारी से कहा कि या तो internal system compromise हुआ है, या फिर वे ग्राहकों को phishing के प्रति सहज बना रहे हैं, और इस पर एक ticket बनाई जाए। प्रतिनिधि ने कहा कि वह domain USAA का नहीं है और वे सिर्फ usaa.com का ही उपयोग करते हैं, और बिना ज्यादा कुछ कहे मेरा अकाउंट लॉक कर दिया। बाद में मुझे फिर फोन करके अकाउंट खुलवाना पड़ा, और कहा गया कि ticket बना दी गई है। अब देखना होगा कि आगे क्या होता है।
बैंकिंग UX और उससे जुड़ी tech व marketing practices बहुत खराब हैं। मैंने जिन भी भारतीय बैंकों के login form इस्तेमाल किए हैं, वे सब:
15 characters से ज़्यादा नहीं! मेरा बैंक तो password के लिए ठीक 6 अंकों की मांग करता है। अक्षर नहीं, सिर्फ अंक। password manager भी नहीं चल सकता, copy/paste भी नहीं कर सकते। नंबर के बॉक्स माउस से क्लिक करने ही पड़ते हैं। “security” के प्रति इस जुनून में 2FA भी पहले physical token से app पर, और आखिर में SMS पर पहुंच गया। और यह कोई छोटा स्थानीय बैंक नहीं, बल्कि फ्रांस का सबसे बड़ा बैंक है।
कुछ हफ्ते पहले Reddit पर एक screenshot वायरल हुआ था जिसमें एक भारतीय सरकारी बैंक का app सिर्फ इसलिए ब्लॉक हो जाता है क्योंकि यूज़र ने Firefox install किया हुआ है। बैंक और सरकारी साइटें यूज़रों के प्रति बेहद असहज हैं। पहले मुझे लगता था कि यह तरीका कम tech-savvy users की रक्षा के लिए है, लेकिन अब लगता है कि यह बस सुरक्षित और सुविधाजनक framework अपनाने की आलस भरी सफाई है।
कुछ भारतीय सरकारी बैंक apps तो camera, पूरा filesystem जैसी गैर-ज़रूरी permissions दिए बिना चलती ही नहीं हैं। हालांकि मेरे बैंक से मुझे OP जैसी spam चीजें कभी नहीं मिलीं। लेकिन आम धारणा यह है कि निचले स्तर के कर्मचारी नियमित रूप से अकाउंट जानकारी scammers को लीक करते हैं।
मेरा बैंक हर 180 दिन में password बदलने को मजबूर करता है, password सिर्फ 6 से 11 characters का हो सकता है, और usable characters भी सीमित हैं। इसलिए login करने जाओ तो फिर password बदलने का संदेश आ जाता है। Firefox का auto-generated password बैंक के नियमों में फिट नहीं बैठता, तो अंत में मुझे terminal में खुद नियमों के हिसाब से random password बनाना पड़ता है।
मुझे समझ नहीं आता कि client-side पर password hash इस्तेमाल करना समस्या क्यों है।
घर खरीदने-बेचने के दौरान यह समस्या और भी खराब हो जाती है। अलग-अलग sub-organizations अलग-अलग domain इस्तेमाल करती हैं, जिससे सब कुछ बहुत उलझा हुआ हो जाता है। मुझे medical device recall के मामले में भी संदिग्ध domain पर भरोसा करना पड़ा था। इसका आसान समाधान यह है कि होमपेज पर trusted partner domains की सूची डाल दी जाए। मेरा निजी सुरक्षा प्रोटोकॉल यह है कि मैं .gov साइट पर जाकर वित्तीय संस्था की संपर्क जानकारी ढूंढता हूं, फिर उस domain पर जाकर customer service नंबर देखता हूं, और फोन करके पूछता हूं कि वास्तव में कौन-से domain भरोसेमंद हैं। customer service वाले अक्सर मुझे अजीब समझते थे। एक बार तो एक representative ने कहा, “अगर LinkedIn पर दिखे कि वह व्यक्ति <Bank Name> में काम करता है, तो आप जान सकते हैं कि वह असली है।”
जब किसी ने कहा कि “अगर LinkedIn पर <Bank Name> उसका workplace दिख रहा है तो भरोसा किया जा सकता है,” तो मैंने जवाब दिया, “मुझे 2 मिनट दीजिए, मैं भी अपनी profile पर यही लिख सकता हूं। तब क्या आप मुझे भी अपनी निजी जानकारी दे देंगे?”
घर खरीदते समय मेरा अनुभव बिल्कुल जटिल नहीं था। मैंने mortgage broker के जरिए काम किया और शुरू से अंत तक सिर्फ एक ही व्यक्ति से डील की।
जिन लोगों के पास decision-making power होती है, वे अक्सर इन जोखिमों को तब तक नहीं समझते जब तक खुद या उनके आसपास कोई fraud या कानूनी समस्या का शिकार न हो जाए। अमेरिका में भी 2012 से पहले बहुत-सी कंपनियां ऐसे ही लोगों द्वारा चलाई जाती थीं, लेकिन whitehat/blackhat hacking तेजी से फैलने के कारण इन समस्याओं का समाधान तुलनात्मक रूप से जल्दी हुआ।
मैं पहले एक ऐसी financial company में काम करता था जहां information security culture बहुत मजबूत था। जब उस कंपनी का अधिग्रहण हुआ, तो मुख्य कंपनी के अधिकारियों के नाम से लगातार बाहरी vendors से तरह-तरह के request emails आने लगे। लेकिन हमारी पुरानी security policy के तहत ऐसे emails पर कार्रवाई करना मना था। इसलिए Slack पर सबने मिलकर तय किया कि यह असली ईमेल हो सकता है, फिर भी policy के मुताबिक इसे phishing के रूप में रिपोर्ट करेंगे। नतीजा भले ही बिना बुरी मंशा का non-compliance था, लेकिन सच कहूं तो यही best practice थी। बाद में मुख्य कंपनी के executives ने पहले से एक ईमेल भेजना शुरू किया: “ऐसे ईमेल आएंगे, इस तरह प्रतिक्रिया दें।” तब हम फिर आपस में पूछने लगे, “ठीक है, लेकिन यह advance notice वाला ईमेल असली है, यह कैसे मानें?” आखिरकार सब थक गए और मुख्य कंपनी की ढीली security practices को स्वीकार कर लिया।
मुझे लगता है कि ऐसे संगठनों में एक सामाजिक संरचना होती है जहां सही फैसले लेने में सक्षम लोग वास्तव में decision-making positions तक पहुंच ही नहीं पाते। अच्छी policies बनाने के लिए जगह-जगह “नहीं” कहना पड़ता है, और उसी प्रक्रिया में power रखने वालों को नाराज़ न करना सबसे मुश्किल काम होता है।
कागज़ों पर CISO, EVP, SVP, security director जैसे बड़े पद भरे पड़े होते हैं, फिर भी ऐसे बेतुके फैसले क्यों लिए जाते हैं, यह मेरी समझ से बाहर है। ऐसे समय में अक्षमता और दुर्भावना के बीच फर्क करना मुश्किल हो जाता है। इसे “भोलेपन” का नाम देना दरअसल ग्राहकों की अनदेखी को माफ़ करना जैसा लगता है। security पर खर्च करना महंगा है, और उस पर ध्यान न देना भी नुकसानदेह है, लेकिन कम-से-कम अभी तक users खोने का नुकसान, चीजों को सही और सुरक्षित बनाने की लागत से कम है—शायद इसलिए यह चलता रहता है। अंततः यह सबके लिए दुखद स्थिति है।
बैंक अक्सर मुझे random marketing calls करता है। अपने ऑफर समझाने से पहले वे मुझसे मेरी जन्मतिथि और मेरी मां का नाम पूछते हैं। जब मैं पलटकर कहता हूं, “पहले यह साबित करो कि तुम सच में बैंक हो,” तो वे हमेशा असहज हो जाते हैं।
जब कोई अनजान कॉल मुझसे निजी जानकारी verify करने को कहती है, तो मैं हमेशा जवाब देता हूं: “मुझे नहीं पता आप कौन हैं, इसलिए मैं निजी जानकारी नहीं दे सकता।” आधे लोग वहीं कॉल काट देते हैं, बाकी सीधे sales pitch शुरू कर देते हैं।
healthcare में भी मुझे यही अक्सर झेलना पड़ता है। specialist के office से कॉल आते ही वे मेरी जन्मतिथि पूछते हैं, और जब मैं मना करता हूं तो उन्हें बहुत आश्चर्य होता है। मेरा भी यही मानना है कि अगर कॉल उन्होंने की है, तो पहले उन्हें अपनी पहचान साबित करनी चाहिए।
मेरा बैंक आखिरकार यह बात समझ गया, और अब उन्होंने app में ऐसा सिस्टम शुरू किया है जिससे यह verify किया जा सकता है कि संबंधित representative सच में बिक्री कॉल कर रहा है और वह कौन-सा कर्मचारी है।
“तो subdomain registration ही समाधान है” वाला विचार शायद इसलिए आया क्योंकि IT department में कोई जानता है कि subdomain जैसी चीज़ों का एक्सेस देना खतरनाक हो सकता है, और इसलिए मना कर देता है। फिर कंपनी के दूसरे विभाग, जैसे marketing, अपना अलग domain register करके इस रोक को bypass कर लेते हैं। मुझे जानना है कि Google जैसी कंपनियां इसे कैसे संभालती हैं। google.com के subdomain का compromise होना तो सबसे आकर्षक targets में से होगा, फिर भी Google खुद काफी subdomains इस्तेमाल करता है। उदाहरण के लिए यह gist लिंक देख सकते हैं।
अक्सर मामला IT department तक पहुंचता ही नहीं। marketing, organizational structure में IT से अलग होता है और IT को involve करना पसंद नहीं करता। IT धीमे और अक्षम ticket systems चलाता है और अक्सर अनावश्यक राय भी देता है, इसलिए marketing वाले उससे बचते हैं। नतीजतन marketing promotions SaaS services या बाहरी vendors को सौंप दिए जाते हैं, जिनका corporate IT से कोई खास संबंध नहीं होता। marketing manager को यह भी नहीं पता होता कि subdomain क्या है; वे बस Google search या लिंक पर क्लिक करके काम करते हैं। URL text तो वैसे भी कोई नहीं पढ़ता, इसलिए subdomain क्यों महत्वपूर्ण है, इसकी समझ ही नहीं बनती। अगर असल users के internet usage patterns देखें, तो पारंपरिक anti-phishing education लगभग बेकार है। “domain ध्यान से पढ़ो” की जगह “Google search करो और ऊपर का result क्लिक करो” शायद ज़्यादा यथार्थवादी anti-phishing सलाह है।
Google भी इस मामले में कम परेशान करने वाला नहीं है। उसकी notification emails ऐसे format में आती हैं कि उन्हें phishing समझ लेना आसान है, और वे google.com के अलावा goo.gl, foobar.google जैसे कई अजीब domains भी इस्तेमाल करते हैं। वह दौर अब खत्म हो चुका है जब लोग ऐसी चीज़ों पर सीधा भरोसा कर लेते थे।
मुझे लगता है कि बिंदु 4 सबसे महत्वपूर्ण है। अगर बैंक अपने ग्राहकों को ऐसे ईमेल भेजते हैं जो phishing जैसे दिखते हैं, तो इसे गंभीर लापरवाही मानते हुए उन पर कानूनी जिम्मेदारी होनी चाहिए।
यह Conway’s law का एकदम वास्तविक उदाहरण है। marketing department का अपना IT है और वह core website संभालने वाले IT से अलग है। इसलिए वे एक ही web domain पर साथ मिलकर development नहीं कर सकते, और परिणामस्वरूप अलग साइट, अलग अनुभव के साथ launch करते हैं।
मेरे एक दोस्त की कंपनी में CISO ने पूरे संगठन के कर्मचारियों के लिए security newsletter भेजा, लेकिन वह ईमेल internal domain से नहीं, एक external domain से आया, और links भी कंपनी की अपनी site की जगह किसी external hosting platform पर थे। इसलिए वे हमेशा phishing mail जैसे लगते थे। खासकर जब उनमें prize giveaway होता था, तब तो वे और भी नकली लगते थे, क्योंकि कंपनी की प्रतिष्ठा के हिसाब से इतने उदार इनाम असंभव लगते थे।