2FA SMS: प्रतिष्ठा से भी बदतर सुरक्षा तरीका

 (ccc.de)
2 पॉइंट द्वारा GN⁺ 2024-07-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • CCC, IdentifyMobile के exposure के जरिए one-time password SMS को real time में देख सका; यह 200 से अधिक कंपनियों के 19.8 करोड़ से ज्यादा SMS leak होने का मामला था
  • 2FA-SMS सिर्फ password चोरी हो जाने की स्थिति को रोकने वाला सहायक उपाय है, लेकिन असली security काफी हद तक SMS sending provider के management level पर भी निर्भर करती है
  • IdentifyMobile ने authentication codes, recipient phone numbers, sender names और कुछ account information internet पर expose कर दी थी, और सिर्फ idmdatastore नाम के subdomain का अनुमान लगाकर access संभव था
  • Google, Amazon, Facebook, Microsoft, Telegram, Airbnb, FedEx, DHL आदि प्रभावित दायरे में थे, और केवल real-time feed के जरिए WhatsApp number takeover या financial transactions तथा service login attempts संभव थे
  • SMS 2FA सिर्फ password इस्तेमाल करने से बेहतर है, लेकिन app-based one-time passwords या hardware tokens जैसी विधियां, जो mobile network और SMS operators पर कम निर्भर करती हैं, ज्यादा सुरक्षित हैं

IdentifyMobile exposure से सामने आई 2FA-SMS की कमजोरी

  • 2FA-SMS में user से उसके द्वारा जाने जाने वाले password और phone number access साबित करने वाले SMS code दोनों की जरूरत होती है
    • इसका इस्तेमाल password ही leak होने पर account takeover रोकने के लिए अतिरिक्त layer के रूप में किया जाता है
    • SMS में WhatsApp authentication code या bank transfer के लिए TAN जैसे code हो सकते हैं, जो थोड़े समय के लिए ही valid होते हैं
  • SMS-based authentication पहले से ही कई attack paths के सामने exposed है
  • इस मामले में, attacker को communication network या users को सीधे target किए बिना भी SMS sending provider authentication chain की कमजोरी बन सकता है
    • IdentifyMobile कई कंपनियों और services के लिए bulk SMS भेजने वाला provider है
    • इस provider के पास SMS body तक access था, और body में authentication codes शामिल थे
    • CCC केवल idmdatastore नाम के subdomain का अनुमान लगाकर real-time data तक पहुंच सका

Exposure का दायरा और वास्तविक जोखिम

  • Exposed data में SMS body के अलावा recipient phone numbers, sender names और कुछ मामलों में अन्य account information भी शामिल थी
  • प्रभावित कंपनियां 200 से अधिक हैं, जिनमें वे मामले शामिल हैं जहां authentication security सीधे या अन्य service providers के जरिए IdentifyMobile को सौंपी गई थी
    • Google, Amazon, Facebook, Microsoft
    • Telegram, Airbnb, FedEx, DHL
    • कुल 19.8 करोड़ से अधिक SMS leak हुए
  • केवल real-time feed से भी कई दुरुपयोग scenarios संभव थे
    • WhatsApp number takeover
    • password पता होने पर, phone तक access किए बिना financial transactions करना
    • password पता होने पर, कई services में login करना
  • वास्तविक दुरुपयोग के लिए आम तौर पर password अभी भी जरूरी था, लेकिन data में 1-click login links भी शामिल थे
    • कुछ बड़े victim companies के मामले में, IdentifyMobile द्वारा protected scope individual services तक सीमित था
    • IdentifyMobile की लापरवाही ने companies और customers को काफी जोखिम में डाल दिया
    • CCC ने data store नहीं किया, लेकिन किसी और ने access किया हो, इसकी संभावना से इंकार नहीं किया जा सकता

SMS के बजाय चुने जा सकने वाले authentication methods

  • उपलब्ध होने पर SMS के बजाय app में generate होने वाले one-time passwords या hardware tokens का इस्तेमाल करना ज्यादा सुरक्षित है
    • ये methods mobile network पर निर्भर नहीं करते
    • ये IdentifyMobile जैसे SMS sending providers पर भी निर्भर नहीं करते
    • फिर भी, second-factor authentication सिर्फ एक password इस्तेमाल करने से बेहतर है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-07-12
Hacker News की राय

  • हाल ही में एक परिचित Google Ads phishing का शिकार हो गया। हमलावर ने “BANKNAME login” जैसे search terms पर ads खरीदे, बैंक के login page की बहुत बारीकी से copy बनाई, और पीछे से relay attack चला रहा था
    जब उन्होंने phone app का 2-step authentication code डाला, तो screen ने उसे reject करके नया code मांगा, लेकिन असल में दूसरा code नया “pay anyone” payee जोड़ने का approval code था, और उसी से पैसा निकल गया
    मुझे लगता था कि SMS 2-step authentication protocol के स्तर पर कमजोर है, लेकिन इस मामले में नया payee जोड़ते समय login से अलग message भेजने वाला बैंक का SMS तरीका शायद बेहतर होता
    आदर्श रूप से, सिर्फ token बनाने वाला app नहीं होना चाहिए, बल्कि transaction type के हिसाब से token बनने चाहिए—जैसे login के लिए token और payee जोड़ने के लिए token—और वे एक-दूसरे की जगह इस्तेमाल न हो सकें। जानना चाहूंगा कि क्या किसी ने ऐसा स्तर का 2-step authentication देने वाला बैंक देखा है
    शायद passkey local hardware के साथ physical connection स्थापित करती है, इसलिए इस तरह की समस्या को बेमानी बना सकती है। वैसे, पीड़ित को आखिर में पैसा वापस मिल गया

    • Ads सिर्फ bandwidth और compute resources खाने वाली परेशान करने वाली psychological terror नहीं हैं; वे web पर fraud और malware फैलाने का नंबर-1 रास्ता भी हैं
      अपनी security posture बेहतर करनी हो तो ad blocker install करना सबसे अच्छे तरीकों में से एक है। जो दोस्त या परिवार के लोग tech-savvy नहीं हैं, उनके लिए uBlock Origin set up करने की मैं strongly recommend करता हूं
    • HSBC में सचमुच ऐसा feature है। हर देश के app में website login, transaction confirmation (जैसे किसी payee को पैसा भेजना), और re-authentication (जैसे phone number जैसी personal information बदलना) के लिए अलग-अलग security codes generate किए जा सकते हैं
      Australia app की screen यहां देखी जा सकती है, और US व UK apps भी मिलते-जुलते हैं: https://www.hsbc.com.au/content/dam/hsbc/au/images/ways-to-b...
      HSBC यह कई सालों से दे रहा है, लेकिन समझ नहीं आता कि यह अभी तक standard क्यों नहीं है या दूसरे US banks ने इसे क्यों नहीं अपनाया
    • जिज्ञासा में मैंने एक बार Google ad खरीदा था—मुफ्त credits मिले थे इसलिए बस try किया—फिर भी ad approval से पहले बेहूदा conditions और guidelines को बहुत ज्यादा navigate करना पड़ा
      फिर समझ नहीं आता कि आम ads पर इतनी सख्ती रखते हुए भी, बैंक का impersonation करने और उस बैंक को search करने वाले लोगों को target करने वाले phishing pages को ads क्यों बेच देते हैं
    • परिवार और परिचितों को यह बताने लायक है कि FBI भी ठीक ऐसी scams से बचने के लिए search engine में ad-blocking extension इस्तेमाल करने की सलाह देता है [0]
      “Internet search करते समय ad-blocking extension का उपयोग करें। अधिकांश internet browsers extensions जोड़ने की अनुमति देते हैं, जिनमें ad-blocking extensions भी शामिल हैं। ऐसे ad blockers को browser के अंदर on और off किया जा सकता है, ताकि किसी खास website के ads allow करते हुए दूसरी जगह के ads block किए जा सकें।”
      [0] https://www.ic3.gov/Media/Y2022/PSA221221
    • यहां से मिलने वाला एक और सबक यह है कि बैंक का URL bookmark कर लें या याद रखें, और यह भरोसा न करें कि search engine आपको बैंक तक सही जगह ले जाएगा

  • मैं काफी समय से शक करता आया हूं कि जो companies SMS 2-step authentication अनिवार्य करती हैं, वे security को लेकर serious नहीं हैं; वे बस phone number चाहती हैं और security theater के तौर पर 2-step authentication दिखाकर number ले लेती हैं

    • वह बात भी निश्चित रूप से है। Phone number नए social security number जैसा हो गया है: लगभग कभी नहीं बदलता और कई services में user को जोड़ने वाला unique identifier बन गया है
      ऊपर से यह ऐसा identifier भी है जिसे आप मिलने वाले लोगों को सीधे दे देते हैं, इसलिए इसे खराब system कहा जा सकता है
    • अगर किसी service में free accounts हैं, तो phone number मांगना fraud prevention या multiple-account abuse रोकने में मदद करता है
      ban से बचने के लिए नए accounts बनाने से रोकता है, और कई accounts में दिखने वाले bad behavior को जोड़ना आसान हो जाता है
    • ज्यादातर companies असल में spam prevention के लिए phone number चाहती हैं
      मुझे लगता है कि spammers ने internet के पतन में जितना योगदान दिया है, उसे कम आंका जाता है
    • SMS 2-step authentication अनिवार्य करने की वजह यह है कि यह मान लेने की तुलना में कि user ने 2-step authentication app install किया है और उस tool को manage करना जानता है, यह मान लेना कि उसके पास phone number है, कहीं ज्यादा कम friction वाला है
      Support करना भी आसान है
    • या यह भी हो सकता है कि पहले email से 2-step authentication किया जाता था, फिर auditor ने कहा “वह 2-step authentication नहीं है”, और तब पता चला कि notification middleware email के साथ-साथ SMS भी support करता है

  • NIST काफी पहले से साफ तौर पर SMS 2-step authentication इस्तेमाल न करने को कहता आया है
    NIST SP 800-63B §5.1.3.3
    https://pages.nist.gov/800-63-3/sp800-63b.html#pstnOOB

    • NIST का नजरिया और हित हमेशा service provider को customer/user experience में जिन चीजों की चिंता करनी पड़ती है, उनसे मेल नहीं खाते
      Customer: “2-step authentication app से आपका क्या मतलब है? Code मेरे phone पर नहीं आता था?”
      Support: “हां, लेकिन अब हम SMS 2-step authentication support नहीं करते।”
      Customer: “लेकिन जब code मेरे phone पर आता था, तब कोई problem नहीं थी।”
      Support: “जी, लेकिन NIST SMS 2-step authentication इस्तेमाल न करने की सलाह देता है।”
      Customer: “NIST क्या है? यह बहुत frustrating है। मुझे अपने account में जाना है।”

  • दुर्भाग्य से लगभग सभी banks SMS इस्तेमाल करवाते हैं। क्योंकि banking apps rooted phones पर चलने से इनकार कर देते हैं। क्या शानदार security achievement है

    • फिर भी इसका मतलब है कि विकल्प मौजूद है
      मेरे देश में लगभग सभी banks SMS विकल्प के बिना app-based 2-step authentication अनिवार्य करते हैं
      अगर अलग phone खरीदकर साथ नहीं रखना चाहते, तो बस वही एक bank इस्तेमाल करना पड़ता है जो इसकी मांग नहीं करता
    • वह security के लिहाज से फायदा ही है
      Rooted phone में दूसरे apps के लिए banking information झांकने और चोरी करने की संभावना खुल जाती है
      compromised phone पर banking app का न चलना काफी reasonable लगता है
    • विवादास्पद है, लेकिन rooted phone मूल रूप से कम सुरक्षित होते हैं
      हालांकि GrapheneOS इसमें शामिल नहीं है, क्योंकि GrapheneOS के official builds में root privileges नहीं होते

  • लेख सुरक्षा के लिहाज से अलग मायने रखने वाली दो समस्याओं को मिला रहा है
    1-click login लिंक चिंता की बात हैं, और सिर्फ SMS access के जरिए WhatsApp जैसी सेवाओं पर कब्ज़ा किया जा सकता है
    लेकिन 2-step authentication codes अपेक्षाकृत कम चिंता की बात हैं। वे दूसरा factor हैं, इसलिए attacker को password भी चाहिए होता है
    ऐसे मामले में SMS के इस्तेमाल और interception के जोखिम को मैं कहीं कम चिंताजनक मानता हूं

    • हर बार जब SMS message database leak होता है, तब तकरीबन account credentials के 1000 databases leak हो चुके होते हैं

  • UK में अब लगभग सभी online banking transactions SMS से verify होते दिखते हैं। देखने में यह कानूनी requirement जैसा लगता है, और इसने पुराने bank card + card reader + PIN verification system की जगह ले ली है
    पुराना तरीका न सिर्फ ज्यादा सुरक्षित था, बल्कि signal पकड़ रहे, सही से काम कर रहे mobile phone पर निर्भर भी नहीं था
    उम्मीद है कि किसी दिन माना जाएगा कि यह भयानक गलती थी और इसे ठीक किया जाएगा, लेकिन बहुत उम्मीद नहीं है

    • कौन-सा bank है, जानना चाहूंगा। मैं Lloyds इस्तेमाल करता हूं और transactions SMS से नहीं, app से verify होते हैं
    • पहला वाक्य बिल्कुल सच नहीं है। SMS विकल्पों में से एक है, लेकिन कई banks app-based 2-step authentication support करते हैं
      मैं मानता हूं कि offline में card reader उपयोगी था। लेकिन मैं उस device को याद रखकर साथ ले जाना लगभग कभी नहीं कर पाया, इसलिए travel के दौरान अक्सर अटक जाता था

  • Sweden ने बहुत पहले BankID से यह समस्या हल कर ली थी
    https://en.wikipedia.org/wiki/BankID
    public institutions और private institutions थोड़ा-सा सहयोग करें तो क्या हासिल हो सकता है, यह हैरान करने वाला है। government services और ज्यादातर banks में login और 2-step authentication का यही एक तरीका है, और यह अच्छी तरह काम करता है
    यकीन करना मुश्किल है कि हर देश में ऐसा system नहीं है, और उससे भी आगे, पूरे EU में ऐसा system नहीं है

    • EU इसके लिए Digital Wallet ला रहा है। उम्मीद है कि यह Finland वाले BankID से इस्तेमाल में बेहतर होगा, और banks या दूसरे private rent-seeking institutions पर कम निर्भर हो तो और अच्छा होगा
      फिर भी मैं अपनी उम्मीदें बहुत ज्यादा नहीं रख रहा हूं
      https://ec.europa.eu/digital-building-blocks/sites/display/E...
    • wiki के description के हिसाब से, मैं सोच रहा हूं कि क्या यह सच में Linux support नहीं करता। शायद card form को विकल्प के तौर पर इस्तेमाल किया जा सकता है

  • S3 bucket में messages शायद हर 5 मिनट में refresh होते थे: https://www.zeit.de/digital/datenschutz/2024-07/it-sicherhei...
    हालांकि CCC का इसे सिर्फ 2FA-SMS की समस्या बताना गलत था। प्रभावित केवल Twilio Verify (2-step authentication API) नहीं था, बल्कि इस provider के जरिए भेजे गए सभी SMS थे

    • Twilio Verify से जुड़ा आधार कहां से आया, यह जानना चाहूंगा। कहीं भी इसका जिक्र नहीं है

  • यह SMS की अपनी समस्या से ज्यादा, sensitive data storage को ठीक से protect न करने वाली vendor security की समस्या लगती है

    • OTP और hardware tokens के मामले में rotating secrets को ऐसे data storage में लिखने की जरूरत नहीं होती जिसे संभावित रूप से public read access मिल सकता हो, इसलिए यह SMS की समस्या भी है
      ऐसा खास attack path उन technologies में होता ही नहीं

  • जिन कई financial institutions में मैं काम करता हूं, वे SMS 2-step authentication मांगते हैं और HOTP/TOTP का विकल्प नहीं देते। पागल कर देने वाला है